DDD 复杂业务系统设计（十）：从战略到微服务，一张图跑通 DDD+中台+微服务

前言

前面 9 篇我们把 DDD 的核心概念、中台、微服务都拆开讲了。

这一篇我们把它们合起来：从战略设计开始，一步步走到微服务落地。

一、DDD + 中台 + 微服务的关系

三者的关系：

DDD 战略设计 ──→ 指导中台业务建模
DDD 战术设计 ──→ 指导微服务设计
中台 ──→ 落地的形式之一（也可以是单体）
微服务 ──→ 落地的形式之一（也可以是中台）

DDD 是方法论，中台和微服务是落地形式。

二、从战略到微服务的完整流程

我用 5 步走完整个流程：

[步骤 1] 业务域分解为中台
   ↓
[步骤 2] 中台归类（核心/通用/支撑）
   ↓
[步骤 3] 事件风暴，建立领域模型
   ↓
[步骤 4] 提炼并重构领域模型
   ↓
[步骤 5] 领域模型映射为微服务

每一步展开讲。

步骤 1：业务域分解为中台

把整个企业业务按业务流程或功能属性拆成多个中台。

以在线教育平台为例：

在线教育业务域
├── 课程中台
├── 学习中台
├── 教学中台
├── 证书中台
├── 用户中台
├── 订单支付中台
├── 营销中台
└── ...

步骤 2：中台归类

按核心/通用/支撑归类：

核心中台：自主研发，最强资源投入。 通用中台：可以借鉴开源或外购，标准化。

步骤 3：事件风暴，建立领域模型

对每个中台做事件风暴，找出实体、聚合、限界上下文。

以课程中台为例：

事件风暴
├── 参与者：教务、产品、技术
├── 事件列表：
│   - 课程已创建
│   - 章节已添加
│   - 课程已发布
│   - 课程已下架
├── 命令列表：
│   - 创建课程
│   - 添加章节
│   - 发布课程
│   - 下架课程
├── 领域对象：
│   - 课程（聚合根）
│   - 章节
│   - 课时
│   - 知识点
│   - 课程分类
├── 聚合：
│   - 课程聚合
├── 限界上下文：
│   - 课程内容上下文
│   - 课程分类上下文
└── 领域模型：{ 输出领域模型文档 }

步骤 4：提炼并重构领域模型

这一步是 DDD 的精髓。多个中台独立建模后，必然有重复或不一致。

举例：

• 课程中台有“讲师”概念。
• 教学中台也有“讲师”概念。
• 这两个“讲师”是同一个对象吗？应该是。

所以要扫描所有中台的领域模型，找出重复的对象，重构。

跨中台扫描：
├── 课程中台的“讲师” ←→ 教学中台的“讲师”
│   → 应该是同一个对象 → 教学领域更全（包含排课、绩效）
│   → 教学领域为主，课程领域引用
│
├── 课程中台的“学员” ←→ 用户中台的“学员”
│   → 应该是同一个对象 → 用户中台为主
│
└── 学习中台的“学习进度” ←→ 教学中的“作业完成度”
    → 应该是同一个对象 → 学习中台为主

重构原则：

• 每个领域对象只在一个上下文里是主，其他上下文引用。
• 优先保留业务最完整的上下文作为主。
• 通过领域事件或 API 同步数据。

步骤 5：领域模型映射为微服务

限界上下文 → 微服务。

课程内容上下文  →  course-content-service（微服务）
课程分类上下文  →  course-category-service（微服务）
学员档案上下文  →  student-profile-service（微服务）

每个微服务：

• 独立的代码库。
• 独立的数据库。
• 独立的部署。
• 独立的团队。

到这一步，从业务到系统的完整链路打通了。

三、一个完整案例：在线教育证书中台

我用一个证书中台走一遍完整流程。

业务背景

公司在多个业务线（K12、职业、企业内训）都会发证书。原来每个业务线自己做证书：

• K12 证书：结业证书
• 职业证书：技能等级证书
• 企业内训：培训证明

每套重复建设，证书模板管理混乱，用户体验差（用户要在不同地方查证书）。

步骤 1：业务域分解

把证书能力抽成独立中台。

步骤 2：中台归类

证书中台归核心中台（证书业务是公司特色竞争力）。

步骤 3：事件风暴

事件列表：
- 课程已完成
- 学时已达标
- 考试已通过
- 证书已生成
- 证书已发放
- 证书已吊销

领域对象：
- 证书（聚合根）
- 证书模板
- 发放记录
- 证书类型
- 持证人引用

聚合：
- 证书聚合
  - 证书（聚合根）
  - 证书模板（值对象）
  - 发放记录

限界上下文：
- 证书模板上下文（管理模板）
- 证书发放上下文（管理发放、查询）

步骤 4：跨中台扫描

证书中台“持证人” ←→ 用户中台“学员”
→ 应该是同一个对象 → 引用用户中台的学员 ID

证书中台“学时” ←→ 学习中台“学习进度”
→ 引用学习中台的进度事件 → 通过领域事件同步

步骤 5：微服务落地

certificate-template-service  # 证书模板微服务
certificate-issuance-service  # 证书发放微服务

两个微服务通过领域事件协同：

学习中台                              证书中台
  │                                       │
  ├── 学习进度达成                       │
  │   ↓                                  │
  ├── 发布 CourseCompletedEvent ──→ 消息中间件
  │                                       │
  │                                       ├── 证书服务订阅事件
  │                                       ├── 检查学时达标
  │                                       ├── 生成证书
  │                                       ├── 发布 CertificateIssuedEvent
  │                                       ↓
  │                                       └── 通知学员

四、避坑要点

坑 1：领域模型一步到位

错。领域模型需要多次迭代才能稳定。

正确做法：

• 第 1 轮：跑通主线，粗粒度。
• 第 2 轮：补充细节，细粒度。
• 每 3-6 个月回顾一次。

坑 2：中台过早抽象

错。中台是业务发展到一定阶段才需要的。

判断标准：

• 至少 2-3 个业务线有相同需求 → 可以考虑中台。
• 业务还在快速试错 → 先放在业务里，不要进中台。
• 业务稳定运行 1 年以上 → 可以考虑沉淀中台。

坑 3：忽略康威定律

康威定律：系统结构反映组织结构。

中台需要专门的中台团队：

• 业务中台团队：负责中台建设，对业务方提供 API。
• 数据中台团队：负责数据加工和分析。
• 前台团队：负责用户端应用。

如果组织结构不调整，中台建不起来。

坑 4：微服务拆太细

反例：一个 5 人的小项目，硬拆 20 个微服务。

正确做法：

• 聚合是微服务拆分的最小单位。
• 一个微服务 2-5 个聚合是合理的颗粒度。
• 业务没发展到一定阶段，不要拆。

五、为什么 DDD 适合做这件事？

DDD 是目前唯一能同时覆盖业务建模和中台、微服务设计的方法论。

这就是为什么 DDD 在中台时代被重新重视。

📌 2026 年补注：上文写于 2020 年中台概念火热期。“中台时代”这一说法在 2022 年后已较少使用——阿里 2023 年的”1+6+N”拆分标志着中台战略的转向。但本文所讲的”DDD → 中台能力识别 → 微服务落地”方法论链条依然成立，只是”中台”这一中间层是否需要独立建设，需要根据公司规模和业务复杂度审慎评估。

六、总结

这一篇我们讲了：

• DDD 战略设计 → 指导中台业务建模。
• DDD 战术设计 → 指导微服务设计。
• 5 步走完从业务到微服务的完整链路。
• 中台和微服务都是业务发展到一定阶段的产物。
• 康威定律决定中台建设必须配组织调整。
• DDD 是目前最系统的覆盖业务到落地的方法论。

下一篇是这个系列最后一篇：3 个实战中常被问到的典型问题（边界量化的标准 / 聚合与依赖倒置 / 事件一致性）。