如何落地业务建模：从 DDD 到 8X Flow
这篇文章整理自极客时间专栏《如何落地业务建模》。它不是逐篇摘要，而是把整门课重组为一条可学习、可复盘、可用于实践判断的主线：业务建模首先是定义问题的方法，其次才是设计解决方案的方法。
如果只把业务建模理解成画类图、拆服务、套 DDD 战术模式，很容易在一开始就走偏。真正困难的地方不是“怎么把系统写出来”，而是“怎么把业务问题定义到所有人都能接受，并且能映射到软件实现”。这也是专栏反复强调的核心：技术方案本身不值钱，定义问题的方式才决定了方案复杂度。
一句话主线
业务建模的演进可以分成两段。
前云时代，DDD 试图用领域模型连接业务、语言和代码。它的核心不是某种代码风格，而是“模型与实现关联、统一语言与模型关联、持续提炼知识”的协作循环。
云时代，系统架构的首要约束从“如何组织模型和代码”变成了“如何用弹性控制成本”。这时仅靠传统对象模型不够了，因为对象模型天然更关注一致性边界，而云原生系统还需要表达弹性边界、异步交互和业务一致性。8X Flow 的价值就在这里：它用合同、权责履约、凭证和角色化变化点，把业务本来就存在的异步结构和服务边界显式建出来。
1. 业务建模先定义问题，不是先寻找模式
很多架构争论之所以无效，是因为大家讨论的是解决方案，而不是问题。比如“要不要上微服务”“要不要建中台”“要不要 DDD”，这些问题如果脱离业务目标，答案往往只剩立场。
专栏给出的判断方式更朴素：从业务角度重新定义问题，通常会得到更简单的解决方案。业务建模的第一价值，是把“我们到底在解决什么业务问题”讲清楚，而不是把代码画得更漂亮。
这带来两个实践难点：
第一，要让业务方和技术方都接受同一个问题定义。业务建模不是把业务方讲过的话记下来，也不是把需求文档翻译成类名，而是在沟通中提炼业务概念、规则、约束和变化点。技术方必须能影响业务定义，业务方也必须能影响模型和实现。
第二，要在特定架构约束下实现模型。单体、多层、微服务、云原生、中台、SaaS，这些架构风格不是纯技术选择，它们会改变模型落地方式。一个在单体里合理的聚合边界，到了云平台上可能因为弹性诉求不同而需要拆分；一个在同步调用里简单的业务流程，到了异步服务生态中会暴露出中间态和补偿问题。
所以，业务建模要同时回答两个问题：业务上什么是正确的问题定义，技术上什么结构能支撑这个定义持续演化。
2. DDD 的核心不是“写得像 DDD”，而是两关联一循环
领域驱动设计最容易被误解为一种编码风格：实体、值对象、聚合、仓储、领域服务。如果只停在这一步，DDD 就会退化成命名规范和目录结构。
专栏把 DDD 的核心压缩成“知识消化”的两关联一循环。
| 元素 | 含义 | 作用 |
|---|---|---|
| 模型与实现关联 | 模型结构能直接映射到代码结构 | 修改模型就是修改代码，修改代码也意味着修改模型 |
| 统一语言与模型关联 | 业务讨论使用模型中的概念 | 需求讨论能反向暴露模型缺失和概念错误 |
| 提炼知识循环 | 讨论需求、发现问题、精炼模型、验证语言 | 让模型在反馈中持续变好 |
这解释了为什么 DDD 特别强调“模型与软件实现关联”。如果模型只是分析阶段的沟通图，代码又按另一套设计模型实现，那么模型和实现就会分裂。业务方讨论的是一套语言，研发维护的是另一套结构，所谓统一语言就无法发生。
极客时间订阅的例子很典型。贫血模型会把用户、订阅、订阅总价等逻辑拆散到 DAO 或服务函数里。代码看似简单，但“用户订阅的专栏”这个业务概念没有在模型中成为一个整体。充血模型则把订阅作为用户聚合的一部分，让“用户拥有订阅、订阅总价属于这个整体”在代码结构中表达出来。这样一来，理解模型就能理解代码，讨论业务变化也能定位实现变化。
这里的关键不是“所有逻辑都必须塞进实体”，而是概念、行为和实现不能脱节。只要模型和实现关联起来，DDD 的底座就成立；要更进一步，才需要看统一语言和提炼知识循环有没有真正运转。
3. 统一语言不是术语表，而是业务和代码共同演化的机制
统一语言常被误解成“大家统一一下叫法”。但专栏强调，DDD 里的统一语言不是普通共同语言，而是基于领域模型的共同语言。
这点很重要。术语表只能减少沟通歧义，却不能推动模型演进。真正的统一语言要求：业务方用模型里的概念表达需求，技术方通过模型和代码反馈业务概念是否成立。当代码被重构，模型发生变化，统一语言也要跟着变化。
比如“用户可以订阅多个专栏”看似只是需求描述，但如果模型中有 User、Subscription 和它们之间的聚合关系，那么这句话就同时指向业务规则和实现结构。后来如果发现“企业版员工可免费阅读专栏”不是普通订阅，而是另一套运营模式，那么统一语言就不能只新增一个字段，而要追问：这是订阅合同的变化，还是另一个业务上下文？
统一语言的价值，就是让技术方有权定义业务，也让业务方有权影响实现。技术方不能躲在“我只是实现需求”后面，因为代码重构会改变业务概念；业务方也不能停留在“我只讲流程”上，因为需求变化会影响模型和代码。
4. 前云时代的三个现实障碍：性能、上下文过载、分层依赖
DDD 的原始对象模型在真实系统里会碰到很多阻力。专栏把这些阻力归纳成三类，并给出对应的建模补丁。
第一类是性能和模型的冲突。典型问题是对象聚合和数据库查询不匹配。比如用户拥有大量订阅，如果直接在 User 里加载所有 Subscription，会遇到 N+1 或一次性加载过多数据的问题；如果把查询和统计逻辑放到 SubscriptionRepository，又会泄露聚合逻辑。解决方式是把“关联关系”本身建模成对象，例如 MySubscriptions，让它既表达业务上的“我的订阅”，又封装分页、统计、计数等实现细节。
第二类是上下文过载。一个实体在多个业务上下文中承担不同职责时，很容易变成巨大对象。比如同一个用户，在购买上下文里是买家，在内容上下文里是读者，在运营上下文里可能是推广者。把所有行为都塞进 User，会制造大类和认知混乱。角色对象和上下文对象的思路，是让实体在不同上下文中扮演不同角色，把行为放回对应语境。
第三类是分层架构的依赖问题。传统分层容易把基础设施放在领域层下面，但真实业务逻辑又需要调用支付、邮件、网银、短信等能力。专栏提出“能力供应商”思路：不要把基础设施当成纯技术层，而是把它拟人化为业务能力提供者。例如网银转账可以抽象成“出纳”，邮件通知可以抽象成“客服”。这样领域逻辑依赖的是业务能力，而不是随机抽象出来的技术接口。
这些补丁背后的共同原则是：不要为了维护某种架构洁癖牺牲模型表达，也不要因为技术限制让模型退化。正确做法是把技术约束转译成业务上可理解的概念。
5. 建模方法的演进：从对象，到事件，到凭证
为了让模型能成为统一语言，模型必须足够业务友好。传统对象模型对研发人员友好，但业务方很难直接从类图里看到业务过程。因此专栏依次介绍了几种把业务维度展开的方法。
角色-目标-实体法从参与者出发：谁在系统中扮演角色，他们想达成什么目标，目标中涉及哪些实体。这种方法适合共创，能帮助业务方参与建模，但它的缺点是对复杂业务流程的分析力不足。
事件建模法把事件看作行为留下的印记。通过“发生了什么变化”来倒推命令、行动者、策略、聚合和读模型。事件风暴就是典型实践：先发散找事件，再根据事件追溯触发事件的命令和角色。它比直接画对象更容易形成统一语言，因为事件往往接近业务方的叙述方式。
四色建模法进一步把事件流的获取从头脑风暴变成强分析。它从企业运营中的现金收入、现金支出、KPI 对比出发，寻找凭证并追溯前后关系。它使用四类对象原型：时标对象表示事件，角色对象表示参与者角色，描述对象表示规格和说明，参与对象表示人、地点、物。
四色法的关键洞察是：业务不是随意发生的，业务活动需要留下凭证。收钱意味着承担义务，要有履约证据；付钱意味着拥有权利，要检查对方是否履约；没有现金往来的管理活动，也常通过目标和实际结果对比形成约束。这样一来，建模就不再只依赖访谈中的故事，而可以沿着凭证链追溯业务脊梁。
6. RESTful API：把模型暴露成业务能力
当模型稳定到一定程度，就要考虑如何把模型暴露给外部消费者。专栏用 RESTful API 讲了一个重要观点：API 不只是技术接口，而是模型对外呈现的业务能力。
资源设计应该从模型出发，而不是从数据库表或后端函数出发。聚合关系、领域概念、集合资源、分页、异步任务，都应该被设计成消费者能理解的资源。比如 /users/{uid}/subscriptions 不只是一个 URL，它表达的是用户和订阅之间的模型关系。
RESTful API 还有一个容易被低估的价值：分布式超媒体。服务之间的关系可以通过链接表达，客户端根据链接逐步发现下一步能力。这样企业内部服务生态更像 Web，而不是一堆需要手写集成说明的 RPC 函数。
这也是为什么 URI 的稳定性很重要。如果 /users/{uid}/subscriptions 来自模型，那么内部到底是单体查询、服务编排、惰性求值，还是异步任务，都可以隐藏在资源背后。消费者依赖的是业务关系，不是内部编排细节。
7. 云时代改变了业务建模的首要约束
前云时代的建模重点，是如何在单体或多层架构中维护模型与实现的一致。云时代的新约束，是弹性。
弹性不是“机器多一点”这么简单，而是根据流量变化动态调整基础设施。云平台真正擅长的是水平扩展：复制镜像生成更多实例，流量低时再移除实例。能否利用云平台，本质上取决于系统能否按不同容量诉求拆分弹性边界。
这带来一个反直觉结论：微服务不是越小越好，也不是只按业务上下文拆分。微服务可以理解为“以业务上下文作为弹性边界的云原生架构模式”，但真正的拆分判断应该是：把这个上下文放进独立弹性边界，是否能更好地利用弹性控制成本？
如果两个上下文流量和变更节奏始终一致，拆开可能只会增加运维和协作成本。如果两个上下文弹性诉求明显不同，就应该拆。比如电商系统中的产品目录和支付，在大促前后的流量峰值不同，分开扩容才有意义。
这就是弹性优先原则：在云平台上，弹性是第一优先级。它不是架构信仰，而是成本和收益判断。
8. 弹性依赖、弹性耦合，以及为什么业务天然偏异步
拆出弹性边界还不够，因为边界之间会传递流量。上游流量暴涨，下游也会承压。这种流量传递叫弹性依赖。
云平台擅长处理依赖吞吐量的弹性依赖，却不擅长处理依赖响应时间的弹性耦合。原因很直接：水平扩展通常能提高单位时间处理请求的数量，但不一定能缩短单个请求的响应时间。
同步调用会把下游响应时间纳入上游响应时间。订单服务同步等待支付服务，订单服务的资源也被支付服务拖住。支付慢，订单也慢；支付扩容跟不上，订单也会积压。这就是弹性耦合。
异步调用则把“等你返回”改成“我发出请求，你在规定时间内处理完并给我结果”。这时关注点从响应时间变成吞吐量，云平台就更容易通过扩容解决问题。
这也解释了专栏里一句很重要的话：业务天生是异步的，同步是简化。现实世界里的权利主张和义务履约本来就不是瞬间完成的。买家下单后要求支付，卖家发货，承运方配送，买家确认收货，每一步都有请求、确认、等待、失败和补救。过去我们在软件里把它写成同步流程，是为了实现简单；到了云时代，这种简化会反过来制造弹性耦合和一致性问题。
9. 区分领域逻辑和业务逻辑：这是 8X Flow 的入口
8X Flow 开始前，专栏先做了一个重要区分：领域和业务不是一回事。
领域逻辑是与运营无关的问题域逻辑。比如内容管理系统里的专栏、文章、评论；搜索引擎里的分词、索引、爬虫；推荐系统里的特征和相似度。它关注的是问题本身，通常具有领域特定、运营中立的特征。
业务逻辑是与运营相关的逻辑。它关注如何赚钱或省钱，复杂度来自定价、分成、返现、合同、履约、绩效、成本控制等运营实践。它通常具有运营特定、领域中立的特征。
极客时间专栏的例子很清楚。发布文章、阅读内容、评论互动，更接近领域系统或内容管理系统。定价、订阅、返现、作者分成、企业版收费，则属于业务运营系统。同样的订阅分成模式，换成网剧或其他内容产品也可能成立；同样的内容管理能力，放到不同运营模式下也可以复用。
这一区分很关键，因为它影响建模方法。领域逻辑未必适合对象模型，有时算法模型、特征模型、决策树更合适。业务逻辑则非常适合从合同、权责和凭证入手，因为企业活动最终都要落在合同、履约、财务和审计上。
10. 8X Flow：用合同和履约理解业务
8X Flow 的核心逻辑是合同履约。它的基本判断是：在业务逻辑中，权责履约是最小的业务交互，合同是最小的业务上下文。
合同不一定是正式纸质合同，也包括具有法律效力的口头约定。网上购物时，订单就是采购合同：商家有义务发货，顾客有义务付款；商家有收款权利，顾客有收货权利。违约场景也属于合同上下文：未付款订单关闭、预订违约扣款、延迟发货补偿等，都不是异常代码，而是权责项。
8X Flow 建模时通常按这个流程走：
- 找合同上下文，明确合同参与方。
- 找主要履约项，识别权利方、义务方、履约请求和履约确认。
- 为履约请求和履约确认寻找凭证。
- 寻找违约情况，把违约责任继续建模为新的履约项。
- 重复追溯，直到进入法律裁定等系统外边界。
- 把参与方和标的物划入领域边界或其他合同上下文。
以极客时间订阅为例，读者和极客时间之间存在专栏订阅合同。主要履约项至少包括：读者支付订阅费用，极客时间提供付费内容访问。支付有请求、有确认、有凭证；内容访问也可以被看作权利和义务的履约。
如果读者未在规定时间内支付，合同可以自动作废；如果专栏断更或下架，可能触发退款、补偿或重新上架后免费阅读等新的履约项。注意，这些不是“异常分支”，而是合同里本来就应该表达的业务规则。
8X Flow 的强大之处在于，它把异步、中间态和补偿从技术问题还原成业务问题。履约请求到履约确认之间天然存在等待期；未确认、确认失败、超时，都会触发业务上有意义的后续动作。
11. 凭证角色化：从业务结构中发现变化点
8X Flow 不只是帮助画出合同，还能帮助发现业务系统的变化点。
继续看专栏订阅支付。如果我们把支付确认直接建模在订阅合同内，这更像线下现金交易：读者和极客时间面对面收款开票。但真实数字化交易会引入微信、支付宝、预付费账户、企业支付等第三方或其他合同上下文。
如果订阅合同直接依赖每一种支付合同，核心业务逻辑就会不断依赖支撑逻辑。每新增一个支付方式，订阅合同都要感知它。这是坏味道。
解决方式是把“支付确认”角色化：订阅合同只要求某种凭证能扮演支付确认，而具体凭证可以来自移动支付协议、预付费合同、企业账户合同等不同上下文。这样，支付确认就成为业务变化点。
这件事的意义不只是解耦代码。它说明业务变化点本来就藏在业务结构里。只要沿着合同、履约和凭证追溯，就能看到哪些地方允许不同上下文协作，哪些履约确认可以由多种凭证扮演，哪些角色可以由不同领域系统或合同上下文提供。
12. 用 8X Flow 看弹性边界：合同不是最小服务，履约才可能是
8X Flow 与云时代架构约束的关系，可以这样理解：
合同上下文表达业务一致性。一个合同里的履约项和违约项共同定义了业务规则，它们构成业务上的聚合。
履约上下文更接近弹性边界。不同履约项可能有完全不同的容量诉求。专栏订阅合同里，“访问付费内容”的流量可能远大于“支付确认”和“断更补偿”。如果为了弹性成本考虑，把访问履约独立出来是合理的；如果所有履约项弹性一致，也可以不拆。
领域上下文也可能是弹性边界。内容管理、搜索、推荐、支付能力等领域系统，可能因流量、算法或数据一致性诉求不同而独立部署。
因此，从模型到微服务不能机械地“一合同一服务”或“一履约一服务”。更稳妥的策略是：先以合同上下文作为服务边界候选，再根据履约项是否真的需要独立弹性边界决定是否继续拆分。
这也解释了微服务粒度问题。合适的粒度不是越小越好，而是业务能力、产品生命周期和弹性收益之间的平衡。
13. 中台的本质：复用业务模式，而不是堆共享服务
中台之所以混乱，是因为“前台”常被误解为前端系统。专栏里更准确的定义是：前台是小而灵活、具有自主性的业务团队。中台则是支撑多个小前台团队的软件平台。
中台要解决的是效能和创新的平衡。平台能力越强，前台复用成本越低，效能下限越高；但平台框定得越死，前台自主度越低，创新上限越低。好的中台不是把所有流程统一掉，而是在特定场景中提取可复用的业务模式，同时保留足够扩展点。
这类可复用业务模式，专栏称为宏流程。宏流程不是具体流程，而是流程模板。比如出行场景下，出租车、专车、快车、顺风车、共享单车都可以被看成“需求方提出出行需求，平台匹配运力资源，完成承运履约”的不同实例。但如果抽象成泛泛的“撮合需求和资源”，就太空了，因为它已经无法指导出行场景下的派单、抢单、接人、送达、取消、支付等具体决策。
业务模式的抽象难点就在这里：抽象不足会退化成具体业务功能，抽象过度会丧失决策价值。专栏建议从已有业务模型中提取宏流程，而不是凭空设计。先建具体模型，再通过角色化变化点做泛化。
以出行为例，出行合同里有取消、接人、送达、支付等履约项。承运人可以由网约车司机、出租车司机、共享单车等不同领域系统扮演；撮合算法可以由不同配置或算法策略扮演；支付确认、送达确认也可以角色化。这样，同一个合同流程就能在不同前台业务中实例化成不同业务流程。
这才是中台的建模核心：复用合同流程中蕴含的业务模式，并通过变化点支持不同业务场景。
14. 真微服务、伪微服务，以及模型如何落地
专栏对微服务的判断非常务实。真正的微服务至少要满足三点：
| 判断点 | 真微服务 | 常见伪形态 |
|---|---|---|
| 服务粒度 | 按业务能力组织 | 只按技术函数拆成分布式服务 |
| 生命周期 | 服务以产品方式研发和运营 | 多个服务仍按同一个项目节奏一起改 |
| 逻辑位置 | 逻辑集中在服务中，编排简单 | 服务只做 CRUD，复杂逻辑泄露到编排层 |
不按业务能力拆，只是分布式服务；生命周期绑在一起，是微工作组；服务没有业务能力，只把逻辑丢给编排引擎，是傻服务；一堆服务改一处牵全身、无法独立扩展，就是分布式单体。
把 8X Flow 模型实现为微服务时，建议顺序是：
先把合同上下文、履约上下文、领域上下文映射为 RESTful API，构建资源和超媒体关系。此时先不急着拆进程，因为 API 代表的是服务生态的模型边界。
再看弹性边界。合同上下文可以先作为服务候选，履约上下文只有在弹性诉求不同、独立部署有收益时才拆成独立服务。领域上下文通常可以先作为一个服务，因为对象模型内部的弹性边界不一定容易细切。
最后用产品化思路管理服务。一个服务对消费者的承诺，不只是接口不变，还包括版本生命周期、兼容策略、服务质量和运营责任。如果服务团队不能长期维护旧版本，消费者就会被迫跟着升级，微服务就会在生命周期上重新耦合。
15. SaaS 化：云时代的下一站是选项设计
专栏最后把话题推进到 SaaS 化，因为云平台、微服务和开放服务生态最终都会遇到一个问题：不同消费者需要的不是完全相同的服务质量。
传统云化策略常假设所有用户共享同一套服务质量。就像所有快递都按次日达提供，所有咖啡都只有超大杯。这当然能服务用户，但成本很高。更合理的方式是围绕选项建模。
选项可以理解为：
能力 + 服务质量 = Offering
快递都能把包裹从 A 地送到 B 地，这是能力；当天达、次日达、标快、特惠，是不同服务质量和成本结构。软件服务也一样：能力可能相同，但可用性、隔离性、响应速度、专属支持、数据独享程度可以不同。
魔球 SaaS 选项建模法把客户分为三类：
| 客户类型 | 特征 | 策略 |
|---|---|---|
| 高价值客户 | 重视服务质量和响应速度，愿意支付更高成本 | 独立环境、专属支持、快速满足个性化需求 |
| 现金奶牛 | 覆盖大多数用户，诉求标准化 | 自动化、自助式、共享环境，降低运营成本 |
| 尴尬客户 | 价值不高，成本又降不下来 | 转化为高价值客户或现金奶牛，必要时结束生命周期 |
这套方法也能指导存量系统 SaaS 化：先把现有系统定义为遗留选项，再从用户群体中分化出高价值客户和现金奶牛，逐步用新选项覆盖他们。SaaS 化的关键不是 Kubernetes 怎么配，而是选项设计是否准确。
核心概念表
| 概念 | 精炼解释 | 实践判断 |
|---|---|---|
| 业务建模 | 从业务角度定义问题，并形成可落地模型 | 是否简化了问题定义，而不是复杂化了方案 |
| 两关联一循环 | 模型-实现关联、语言-模型关联、知识提炼循环 | 模型变化是否能映射到代码和讨论语言 |
| 统一语言 | 基于模型的业务和技术共同语言 | 是否能暴露模型缺失，并推动模型演进 |
| 富含知识的模型 | 行为和规则围绕业务概念组织 | 逻辑是否散落在 DAO、Service 或脚本中 |
| 关联对象 | 把对象间关联本身建模 | 是否既保留业务概念，又封装查询和性能细节 |
| 角色对象 | 同一实体在不同上下文中扮演不同角色 | 是否缓解大类和上下文过载 |
| 能力供应商 | 把技术依赖转译为业务能力 | 是否能在业务上说清依赖的能力是什么 |
| 事件建模 | 通过事件追溯命令、角色、聚合和读模型 | 是否能让业务方参与发现事件流 |
| 四色建模 | 通过凭证和现金/KPI 逻辑追溯业务事件 | 是否能找到业务收入流和履约证据 |
| 弹性边界 | 以弹性作为首要因素划定的系统边界 | 独立扩缩容是否能降低成本或风险 |
| 弹性耦合 | 响应时间依赖导致边界无法独立利用弹性 | 同步等待是否拖住上下游资源 |
| 8X Flow | 以合同、权责履约、凭证建模业务 | 是否能解释履约、违约、补偿和变化点 |
| 宏流程 | 可在不同场景中实例化的业务模式模板 | 是否既可复用，又能指导具体业务决策 |
| Offering | 能力和服务质量的组合 | 是否按客户价值和成本设计服务选项 |
实践路径：拿到一个业务后怎么做
第一步，不要从系统边界或服务拆分开始。先问：这个业务靠什么赚钱或省钱？哪些逻辑属于运营模式，哪些只是领域功能？如果是内容产品，内容管理和订阅分成要分开看；如果是出行产品，地图、定位、运力管理和承运合同也要分开看。
第二步，找合同上下文。谁和谁之间存在权责？合同如何成立？主要履约项是什么？每个履约项的权利方、义务方、请求、确认和凭证分别是什么？
第三步，追违约和补偿。履约失败后发生什么？是合同作废、退款、罚息、补偿，还是进入外部法律流程？不要把它们当技术异常，要把它们作为业务规则建模。
第四步，寻找变化点。哪些履约确认可以由不同凭证扮演？哪些角色可以由不同领域系统扮演？哪些合同上下文之间存在凭证引用？这些地方往往就是扩展点、服务协作点或中台宏流程的配置点。
第五步，再考虑架构边界。合同上下文、履约上下文、领域上下文分别有什么弹性诉求？同步调用是否制造弹性耦合？异步后产生的中间态在业务上意味着什么？是否需要独立服务，取决于弹性收益、业务能力和产品化生命周期，而不是拆分欲望。
第六步，设计 API 和产品化服务。资源从模型来，URI 表达模型关系，超媒体表达服务生态。服务不是项目交付物，而是带生命周期、版本承诺、服务质量和消费者体验的产品。
常见误区
不要把 DDD 等同于战术模式。实体、值对象、聚合、仓储只是实现手段，不是 DDD 的核心。核心是模型、语言、代码和反馈循环是否连在一起。
不要从解决方案反推问题。看到策略模式、状态模式、中台、微服务、SaaS，都要先问它解决的具体问题是什么。模式等于问题加解决方案，只拿解决方案会制造认知噪音。
不要为了“领域复用”忽略业务逻辑。商业社会里，复用领域功能不等于复用业务。ERP 的历史已经说明，要么企业流程适配产品，要么产品被大量定制。真正难复用的是业务运营模式。
不要机械按业务上下文拆微服务。云平台上要看弹性边界。如果拆开不能带来独立扩缩容、独立生命周期或成本收益，拆分只会增加复杂度。
不要把中台理解成共享服务集合。中台的目标是支撑小前台团队快速试错，核心是复用特定场景中的业务模式，而不是沉淀一堆通用 CRUD 能力。
总结
这门课最有价值的地方，是把业务建模从“画模型”拉回到“定义问题”。DDD 解决的是模型、语言和实现如何相互反馈；事件建模和四色建模解决的是如何让业务维度自然展开；云时代的弹性边界提醒我们，架构约束会反过来改变模型；8X Flow 则用合同和履约，把业务本来就存在的异步、权责、凭证、变化点和服务边界显式化。
如果要把所有内容压缩成一句实践建议，那就是：先从业务本身寻找结构，再把结构映射到技术实现。不要从技术方案定义业务问题。
复习题
- 为什么说 DDD 的核心不是“领域对象写得很充血”，而是“两关联一循环”？
- 统一语言为什么不能只是术语表？它如何反向影响代码和模型？
- 在用户订阅专栏的例子中，贫血模型和富含知识模型的关键差异是什么？
- 关联对象、角色对象、能力供应商分别解决了什么现实障碍？
- 事件建模和四色建模都能获得事件流，它们的入口有什么不同？
- 为什么云平台更擅长处理吞吐量依赖，而不擅长处理响应时间依赖？
- “业务天生是异步的，同步是简化”这句话如何用订单、支付、发货解释？
- 领域逻辑和业务逻辑的差异是什么？为什么这个差异会影响建模方法？
- 在 8X Flow 中，为什么权责履约是最小业务交互，合同是最小业务上下文？
- 凭证角色化为什么能帮助发现变化点？
- 为什么合同上下文不一定等于弹性边界？什么时候履约项应该拆成独立服务？
- 中台复用的是能力、流程，还是业务模式？宏流程为什么不能过度抽象？
- 真微服务和分布式服务、微工作组、傻服务、分布式单体的差异是什么？
- Offering 为什么是“能力 + 服务质量”，而不是单纯的软件功能？