本篇要搞懂的 3 件事：DDD / 中台 / 微服务三者各是什么角色、它们怎么对应起来、用 DDD 给中台建模的五步流程。
本讲是 09（中台是什么）和 11（中台实战案例）之间的"桥"——把"中台"这个业务概念和"DDD/微服务"这套方法论正式接上。
承接前文：09 讲说清了"中台是什么、该共享什么"。10 讲回答一个更根本的问题——凭什么用 DDD 来建中台？三者怎么配合？
先用大白话打底：开连锁餐厅的故事
这一讲难，是因为满屏都是抽象词（中台、子域、限界上下文、领域模型、微服务），全靠抽象解释抽象。先讲一个全是实物的故事，每个抽象词都对一个看得见的东西，后面看表格就不晕了。
你开了个餐饮集团，旗下有好多家店：堂食店、外卖店、商场档口、小程序点单……（这些就是前台，直接面对顾客。）
一开始每家店各干各的：各自买菜、各自熬高汤、各自调酱料、各自切配。结果呢——重复劳动（每家店都熬一遍汤），而且各店口味还不统一。
于是你建了个 「中央厨房」：把"谁都要用、又该统一"的活集中做好，比如熬高汤、配酱料、净菜切配，做成半成品配送给各门店。门店要用直接拿，不用自己从头做。这个中央厨房，就是「中台」。
现在对号入座，每个抽象词 = 故事里的一个实物：
| 抽象词 | 餐厅故事里是什么 | 说明 |
|---|---|---|
| 领域 / 业务域 | 你整个餐饮集团的全部生意 | 最大的那个圈 |
| 子域 | 把生意切成几摊：熬汤、酱料、切配、招牌菜研发…… | 大圈切成的小块 |
| 核心域 | 招牌菜研发（你的核心竞争力，别人抄不走） | 最该砸资源的那摊 |
| 通用域 / 支撑域 | 熬汤、切配、洗菜（谁都要、不分高下） | 通用的活 |
| 中台 | 中央厨房里的一个个车间（高汤车间、酱料车间……） | 子域落到组织上 = 一个中台 |
| 核心中台 / 通用中台 | 招牌菜车间（核心）/ 高汤切配车间（通用） | 中台按重要性分类 |
| 限界上下文 | 一个车间内"自成一套、不和别人混"的工作范围 | 车间的边界 |
| 微服务 | 真正盖起来、能独立运转的那个车间（有自己的人、设备、流程） | 把"车间设计图"真正建成 |
| DDD | "怎么科学地规划这些车间、再把它们一个个建起来"的整套方法 | 贯穿设计到施工的方法论 |
带着这个故事，本讲三句话就懂了：
- 中台 = 业务模型：先在图纸上规划"中央厨房分几个车间"——这是抽象的业务能力。
- 微服务 = 系统实现：把每个车间真正盖出来、能跑起来——这是落地的代码系统。
- DDD = 方法论：既教你"怎么画车间规划图"（战略设计），又教你"怎么把车间盖出来"（战术设计）。
后面所有的表格和五步法，本质都在讲这一件事：先把生意切成车间（战略），再把每个车间盖成能跑的系统（战术）。
三者各是什么角色（一句话各就各位）
中台是业务模型（抽象出来的业务能力），微服务是这个模型的系统实现，DDD 是同时指导"建模"和"实现"的方法论。
| 角色 | 是什么 | 用 DDD 的哪把"利器" |
|---|---|---|
| 中台 | 抽象出来的业务模型（业务领域不断细分、聚合重构的产物） | 战略设计（领域建模、划限界上下文） |
| 微服务 | 业务模型的系统实现 | 战术设计（聚合/实体/领域事件/领域服务/分层架构） |
| DDD | 连接两者的方法论 | 战略 + 战术，两头都管 |
一句话：中台和微服务，正是 DDD 实战的最佳场景。
DDD 的本质（回顾）
DDD 解决业务问题的套路：把业务领域按规则不断细分 → 分到合适粒度后限定边界 → 在边界内建领域模型 → 用代码实现。
- 领域 → 子域 → 子子域……分到适合建模为止。
- 子域按重要性/功能属性分三类：核心域、通用域、支撑域（详见 02 讲）。
看图：保险这个"领域"被切成多块——营销/核保/理赔/承保是核心子域，用户/客户/订单/支付是通用子域，产品管理/单证/数据字典是支撑子域。
⚠️ 核心域怎么划没有标准答案，必须结合企业战略——这正体现了领域建模的重要性。划分的意义是：区分各子域的重要性，进而决定资源投入和建设策略。
三者怎么对应（建立映射关系）
作者从两个视角看同一个企业业务架构，把它们对照起来：
| DDD 视角 | 中台视角 | 关系 |
|---|---|---|
| 领域 | 业务域 | 对应 |
| 核心域 | 核心中台 | 对应 |
| 通用域 + 支撑域 | 通用中台 | 对应（划子域是为定资源投入，重点是核心域，所以通用/支撑可暂不严格区分） |
| 子域 | 中台 | 功能范围一致 → 可以把"子域"统一叫"中台" |
| 领域模型所在的限界上下文 | 微服务 | 对应 |
💡 关键一步——建通用语言：DDD 第一原则是先建通用语言。把 DDD 引入中台时，既然"子域"和"中台"功能范围一致，就统一术语为"中台"，避免团队各说各话。
建好这套映射后，就能用 DDD 来给中台做业务建模了。
保险例子里业务中台分两类：
- 核心中台：营销、承保、理赔等（保险核心业务能力）
- 通用中台：订单、支付、客户、用户等（支撑核心流程跑通全流程）
中台如何建模（DDD 五步法）
中台业务抽象 = 业务建模 = DDD 战略设计；系统抽象 = 微服务建设 = DDD 战术设计。
| 步骤 | 做什么 | 属于 |
|---|---|---|
| 第 1 步 | 把业务域细分为多个中台（核心域按业务流程分，通用/支撑域按功能属性/集合分），再归类为核心中台 / 通用中台 | 战略 |
| 第 2 步 | 选一个中台，用例/场景/用户旅程做事件风暴，找出实体、聚合、限界上下文，初步建主领域模型 | 战略 |
| 第 3 步 | 以主领域模型为基础，扫描其它中台领域模型，检查重复 / 需要重组的领域对象，提炼重构主领域模型 | 战略 |
| 第 4 步 | 换下一个主领域模型，重复第 3 步，直到所有模型都比对重构完 | 战略 |
| 第 5 步 | 基于领域模型设计微服务，系统落地 | 战术 |
⚠️ 为什么需要第 3、4 步：各中台是独立建模的，难免出现——同一个领域对象重复出现在多个模型里，或本该同属一个聚合的对象散落在不同中台。所以第 2 步只求"初步"，靠第 3、4 步跨中台比对、提炼、重组，才能得到内聚完整的最终模型。
🪞 接着餐厅故事理解：你让各车间分头列"自己要干的活"。结果发现——"切葱花"高汤车间在干、酱料车间也在干（重复）；而"熬骨汤"本该归高汤车间统一干，却散在好几个车间各熬各的（不内聚）。第 3、4 步就是把所有车间的活摊在一起对一遍：重复的合并、该归一处的归位。不这么做，盖出来的车间就会功能打架、各干各的。
看图：左侧"战略设计"= 第 1~4 步（业务域分解为中台、归类、领域建模）；右侧"战术设计"= 第 5 步（每个领域模型映射成一个微服务）。一个限界上下文/领域模型 → 一个微服务，是这里的落地主线。
保险领域填上真实数据后的样子（取通用中台的客户、订单、用户三个中台示例）：
| 中台 | 提炼出的领域模型 → 微服务 |
|---|---|
| 客户中台 | 客户信息、客户视图 |
| 用户中台 | 用户管理、登录认证、权限 |
| 订单中台 | 订单模型 |
总结
DDD、中台、微服务"看似风马牛不相及，实则缘分匪浅"：中台是业务模型、微服务是系统实现、DDD 是贯穿两者的方法论。
对应关系：领域↔业务域、核心域↔核心中台、通用/支撑域↔通用中台、限界上下文↔微服务；功能范围上子域与中台一致，可统一术语为"中台"（先建通用语言）。
建模五步法：①业务域分解为中台并归类 → ②选中台做事件风暴建初步模型 → ③跨中台比对、提炼重组 → ④遍历所有模型重复③ → ⑤领域模型映射为微服务落地。其中①~④是 DDD 战略设计，⑤是战术设计。
一句话速记
中台=业务模型、微服务=系统实现、DDD=方法论；战略设计把业务域切成中台并建领域模型，战术设计把每个领域模型（限界上下文）落成一个微服务。
思考题
你的企业在做中台吗？现在用什么方法做中台业务建模？和 DDD 的方法相比孰优孰劣？
- 你们的"中台/子域"划分，是结合企业战略来定核心域的吗，还是按技术/组织惯性切的？
- 有没有"同一个业务对象散落在多个系统、各建一份"的情况？（这正是第 3、4 步要解决的）
