本篇要搞懂的 4 件事：传统企业为啥会"重复造轮子"、避免重复建设的中台思想是什么、构建中台业务模型的两种策略（自顶向下 / 自底向上）、以及自底向上"三步法"具体怎么一步步把散落的领域模型重组成中台。
⚠️ 这是一讲实战案例课——它不教新概念，而是把第 10 讲讲的"用 DDD 建中台"的方法，用一个保险公司的真实案例从头到尾走一遍。看的时候别死记结论，重点跟着案例的手感走：先有什么、对比出什么、最后重组成什么。
承接前文：第 10 讲讲了"中台是什么、为什么用 DDD 来建中台"——那是方法论。第 11 讲就是把这套方法论落到一个具体案例上：一家保险公司，既有传统核心系统，又有互联网电商平台，两边功能一堆重叠，怎么用 DDD 把它们重构成一套干净的中台？
10 讲：中台是什么 + 为什么用 DDD 建中台（讲道理）
11 讲：拿保险公司当例子，从头走一遍（动手做）
↓ 三步法
分域建模型 → 对齐找差异、聚合重组 → 中台归类、定微服务
一、先看病：传统企业为什么会"重复造轮子"
故事背景是这样的：很多传统企业本来有一套传统核心系统（面向柜台、业务员，大而全、很重）。后来互联网 / App 火了，市场变化快，需要快速发版，于是企业又单独建了一套互联网电商平台（面向个人客户，要轻、要快）。
问题来了：两套系统卖的是同样的产品（比如都卖保险），所以业务高度同质，必然撞车。作者把这种撞车归成四类：
看图抓什么：中间椭圆交叠的部分（客户、用户、投保、报价、核保、出单……）就是两边都建了一遍的能力；左右两侧不重叠的，是各自的个性能力（电商有购物车、在线客服；传统核心有再保、佣金、理赔）。这张图就是"病灶"图。
| 撞车类型 | 大白话 | 例子 |
|---|---|---|
| 核心能力重复 | 最值钱的主营业务，两边各做一套 | 报价、投保、核保、出单 |
| 通用能力重复 | 公共底座，两边各做一套（电商嫌核心系统太重，自己搞了个缩小版） | 用户、客户 |
| 业务职能分离 | 同一件事被拆成两半，各做一半，合起来才完整 | 缴费：电商用支付宝/微信，核心用 POS 机 |
| 前后完全独立 | 各管各的，本来就不该合并 | 电商有购物车/在线客服；核心有再保/佣金/打印 |
🪞 辅助理解：想象一家公司开了两家分店——总店（传统核心）什么都有、流程一大套；新开的网店（互联网电商）为了快，自己又雇了一套收银、客服、库管。结果两家店各有一个"客户管理表"、各有一套"收款流程"，数据对不上、改一处要改两遍。这就是重复造轮子。中台要干的，就是把"两家店都需要的公共能力"抽出来，建成一个总仓库，谁要谁来调。
二、开药方：中台的核心就是"别重复造轮子"
第 10 讲的定义"中台是企业级能力复用平台"，这一讲用大白话点破——“复用"就是"重复使用”，就是不让你重复造轮子。
它和软件设计里那条老原则 “高内聚、低耦合” 完全一致：
高内聚：把相关的业务行为聚在一起，不相关的踢出去。这样要改某个业务行为，只改一处就行。
所以遇到重复建设，处理方式是一句话：
站在全企业的高度，把"重复的、需要共享的"通用能力和核心能力沉淀到中台；把"被拆散的"业务能力重组成完整的板块。前端个性能力留前端，后端管理能力归后台，建立前台 / 中台 / 后台边界清晰的可复用模型。
三、两种建模策略：自顶向下 vs 自底向上
用 DDD 建中台，有两条路，选哪条取决于你公司的家底：
| 自顶向下 | 自底向上 | |
|---|---|---|
| 怎么做 | 先做顶层设计，从最高的"领域"逐级往下拆成子域、中台 | 先按现状各自建模，再对齐、对比、重组 |
| 看不看现有系统 | 基本不看，只看业务本质 | 紧贴业务和系统现状 |
| 适用场景 | 全新系统 或 旧系统推倒重建 | 遗留系统的演进式重构（不推倒，慢慢改） |
自顶向下的拆法就是经典的 DDD 逐级分解，三步走：
看图抓什么：从上到下是一条单向分解链——最顶上的"领域"先分成核心域/通用域/支撑域，每个域里再拆子域，子域里建领域模型，领域模型对应限界上下文，最后落地成一个个微服务（六边形）。注意右边那个"自顶向下"的大箭头，整条链是从抽象一路具体到代码。
💡 大多数传统企业不可能推倒重来，所以这一讲后面的案例走的是自底向上——这才是真实世界里最常用的路子。
四、自底向上三步法（本讲主菜）
作者拿保险公司的真实案例，一步步演示"自底向上"怎么走。记住这条主线就行：先各自建模 → 再对齐重组 → 最后归类定微服务。
第一步：锁定业务域，各自先建好领域模型
先别想合并，先把现有的几个业务域用事件风暴各自建模（找领域对象、建聚合、划限界上下文）。案例选了 5 个业务域：
看图抓什么：每个大色块是一个业务域（用户、客户、传统收付、承保、互联网电商），里面的白圆圈是领域模型，圆圈里的黄椭圆是聚合。这里先盘点出来：
| 来源 | 领域模型（共几个） |
|---|---|
| 传统核心（8 个） | 用户域：用户认证、权限；客户域：个人、团体；传统收付：POS 刷卡；承保域：定报价、投保、保单管理 |
| 互联网电商（6 个） | 报价、投保、订单、客户、用户认证、移动收付 |
这一步的产出就是一张"原料清单"。重点是去发现：哪些领域模型名字相似（说明能力重复），哪些是职能被拆散（比如移动支付 vs 传统支付）——这些就是下一步要动手重组的对象。
第二步：对齐业务域，对比 → 重组
把两边的领域模型按业务域横向对齐，左右一摆，差异就一目了然：
看图抓什么：左列是电商、右列是传统核心，中间用双向箭头按"用户/客户/承保/收付/订单"5 个基准域对齐。一眼能看出右边（传统核心）的模型明显比左边（电商）多、更完备——只有"订单"是电商独有、传统核心打了个红叉（没有）。
由此定下重组的总原则：
以传统核心的领域模型为"主"，电商的为"辅"。把电商里重复的能力沉淀进核心的模型，电商只保留自己的个性能力（比如订单）。既要模型完备，又要照顾电商敏捷响应市场的需要。
接下来以**「客户」**为例，演示一次完整的重组。先看原料：
| 来源 | 客户域里有什么聚合 |
|---|---|
| 电商客户 | 个人、积分（积分是为了营销） |
| 传统核心客户 | 个人模型有：个人、视图、评级、归并 4 个聚合；外加一个团体模型 |
重组动作分三下：
- 打散：把两边和"个人客户"相关的聚合全拆出来，凑齐 5 个——个人、积分、评级、归并、视图。
- 归类重组：按业务亲缘关系重新分组——
- 个人 + 归并 + 视图 → 合成 「个人」领域模型（管客户信息）
- 评级 + 积分 → 合成 「评级积分」领域模型（面向个人客户）
- 直接搬：团体客户只有传统核心有，电商没有，直接把传统核心的「团体」模型搬过来。
最终客户中台 = 个人 + 团体 + 评级积分 三个领域模型。
🪞 辅助理解：这一步像整理两个搬家纸箱。A 箱（电商）和 B 箱（核心）里都有"个人客户"相关的零件，还各有些独有的。你不会把两个箱子原样摞起来，而是全倒出来、按"用途"重新分堆：信息管理的归一堆，积分评级的归一堆，团体客户单独一堆。重组的依据是业务亲缘，不是原来放在哪个箱子。
作者把这步的心法浓缩成一句口诀：
💡 “分域建模型，找准基准域，划定上下文，聚合重归类。” —— 这就是整个第二步的精华。
其它业务域（用户、承保、收付、订单）是同样的套路，作者留作练习。重构后的全貌长这样：
看图抓什么：左列是"重构后的中台业务模型"，右列是文字版的重构说明。对照第二步那张"对齐图"看，你会发现散落两边的聚合，现在都被收拢进了统一的中台模型里——比如收付域把"支付宝、微信、POS 刷卡"三种收付方式整合进了一个收付模型。
第三步：中台归类，按领域模型设计微服务
最后把这些重组好的领域模型归到对应的中台，并标出哪些是核心中台、哪些是通用中台，一棵树就清楚了：
看图抓什么：从左到右四层——业务域 → 中台（核心中台/通用中台）→ 领域模型（圆圈）→ 微服务（六边形）。注意承保中台被归为核心中台（保险公司的命根子），其余客户、订单、用户、收付都归通用中台（公共能力）。最右侧每个领域模型基本对应一个微服务——领域模型定下来，微服务怎么拆就定下来了。
💡 这正好接上第 10 讲的链条：DDD 建模 → 划领域模型/限界上下文 → 落地为微服务。中台业务建模做完，微服务的边界自然就有了。
五、再往下钻：重组时领域对象在发生什么
前面四步都是在聚合这个粒度（相对高阶）上搬家。但聚合一动，里面更细的领域对象（聚合根、实体、命令、领域服务）也会跟着重排。作者还是用「客户」举例，给了三张对照表。
重构前——传统核心客户（个人/团体/评级 三个聚合）：
重构前——互联网电商客户（个人/积分 两个聚合）：
重构后——客户中台（个人/团体/评级积分 三个领域模型）：
看图抓什么：三张表的列都是"业务域 / 领域模型 / 聚合 / 领域对象 / 领域类型"。对比着看第三张——它把前两张表里的领域对象合并去重、重新归位了。比如电商的"积分（MemberLoyaltyPoints）“和传统核心的"评级（Rating）”，在重构后被装进了同一个**「评级积分」领域模型**里，各自带着原来的聚合根、命令、领域服务一起搬进新家。
💡 两个要注意的细节：① 部分领域对象会从原聚合分离、重组到别的聚合；② 搬进新模型后，实体、领域服务等还可能根据新业务场景再做一轮代码重构。也就是说，重组不是简单挪位置，落到代码层还有二次打磨。
总结
这一讲是一堂纯实战课。它要解决的现实病是：传统企业又有老核心系统、又有新电商平台，两套系统卖同质产品，导致核心能力、通用能力重复建设，业务职能被拆散。药方就是用 DDD 把公共能力沉淀成中台、把拆散的能力重组成完整板块，做到"高内聚、松耦合"的企业级复用。
建模有两种策略：自顶向下（适合全新系统或推倒重建，从领域逐级分解）和自底向上（适合遗留系统演进式重构，先各自建模再对齐重组）。真实企业大多走自底向上，三步法是核心：第一步各业务域用事件风暴各自建模、盘出原料清单；第二步按基准域左右对齐，以"完备的一方"为主、重复能力往里沉淀、个性能力保留，把聚合打散重组；第三步把领域模型归到核心/通用中台，按领域模型设计微服务。
最关键的一句话作者也点了：中台业务模型的重构过程，就是微服务架构演进的过程——业务边界即微服务边界，业务边界划好了，微服务边界自然就好了。
一句话速记
中台就是别重复造轮子；自底向上三步走——分域建模型、对齐找差异聚合重归类、中台归类定微服务；业务边界即微服务边界。
思考题
你正在做的开源项目 MemoryEngine，本质上也是一个"被多个上层应用复用的能力底座"——这其实就是个小中台。试着用本讲的视角盘一盘：
- 盘原料：如果未来 MemoryEngine 要服务多个场景（比如"对话记忆"“文档记忆”），它们各自需要的能力里，哪些是重复的（该沉淀进核心）、哪些是个性的（该留在上层）？画一张类似第一张"两个椭圆相交"的图。
- 找重组：有没有两个看起来名字不同、其实业务亲缘很近的模块，可以像"评级+积分"那样合并成一个领域模型？
- AI 代写视角：当你让 AI 帮你写代码时，"聚合 / 领域模型"的边界划清楚没有，直接决定 AI 生成出来的模块是干净解耦、还是一坨缠在一起——你打算怎么在让 AI 动手前，先把这些边界用一两句话说清楚？
