前言
这一系列我从基础概念到落地，写了 10 篇关于 DDD 的文章。这一篇是收官之作。
下面这张图，是整个系列的总览脉络。它把 10 篇串成 ① 三层视角 → ② 端到端路径 → ③ 落地成熟度 → ④ 核心心法。你也可以把它当作这个系列的目录。
下面把图里画过的内容用文字展开，方便检索和深读。
一、关键概念速查表
把整个系列的核心概念浓缩在一张表里，方便查阅：
战略设计
| 概念 | 一句话 | 详细 |
|---|---|---|
| 领域 Domain | 有边界的问题空间 | #1 #2 |
| 子域 Subdomain | 拆小后的领域 | #2 |
| 核心域 | 公司核心竞争力所在 | #2 |
| 通用域 | 多个子域共用的通用能力 | #2 |
| 支撑域 | 必需但不通用也不核心 | #2 |
| 限界上下文 | 模型的边界 ≈ 微服务边界 | #3 |
| 通用语言 | 上下文内的统一术语 | #3 |
战术设计
| 概念 | 一句话 | 详细 |
|---|---|---|
| 实体 Entity | 有 ID、生命周期延续 | #4 |
| 值对象 ValueObject | 无 ID、不可变、按值判断 | #4 |
| 聚合 Aggregate | 一致性边界 | #5 |
| 聚合根 | 聚合对外的唯一接口 | #5 |
| 仓储 Repository | 聚合的加载/持久化接口 | #5 |
| 领域服务 | 跨实体的业务逻辑 | #5 #7 |
| 领域事件 | 已发生的事实 | #6 |
架构
| 概念 | 一句话 | 详细 |
|---|---|---|
| DDD 分层 | 用户接口/应用/领域/基础 四层 | #7 |
| 整洁架构 | 洋葱形，依赖只能由外向内 | #8 |
| 六边形架构 | 端口-适配器架构 | #8 |
| 中台 | 企业级能力复用平台 | #9 |
| 业务中台 | 业务能力的复用 | #9 |
| 数据中台 | 数据价值的萃取 | #9 |
| BFF | 服务于前端的后端 | #8 |
二、从战略到落地的完整路径
总览图模块 ② 已经把 8 步落地路径画得很清楚了——从「业务愿景」到「微服务系统 + 业务能力中台」。这里把每一步背后的关键决策点展开说：
- [#1] 决策：评估团队规模、业务复杂度、未来 3 年的演进方向，确认「用 DDD」而不是「先堆功能」。
- [#2] 业务域分解：用「业务愿景 → 价值链 → 子域」三步走，先把核心域圈出来。
- [#3] 事件风暴：召集业务 + 技术一起，识别领域事件 → 命令 → 聚合 → 限界上下文。
- [#4-#6] 领域建模：在选定的限界上下文内做战术设计，遵循 #4-#6 的实体/值对象/聚合/事件规范。
- [#7] 分层架构：用 DDD 四层（用户接口/应用/领域/基础）作为代码骨架。
- [#8] 架构选型：根据团队 OO 能力、测试覆盖度，决定走分层 / 整洁 / 六边形中的哪一种。
- [#9] 中台规划：当业务 ≥ 3 条线时，识别可共享能力，上中台。
- [#10] 端到端落地：领域模型 → 微服务 → 中台三者的协作模式与反模式。
遇到具体问题，回看对应文章。
三、给不同角色的建议
架构师
- 必看：#1 #2 #3 #10
- 重点：战略设计的完整链路
- 技能要求：业务理解力、抽象能力、组织协调
后端开发
- 必看：#4 #5 #6 #7
- 重点：战术设计 + 分层架构
- 技能要求：OO 设计、领域建模、单元测试
技术负责人 / CTO
- 必看：全部 10 篇
- 重点：#1（决策）、#8（架构选型）、#9（中台）、#10（端到端）
- 技能要求：业务洞察、架构决策、组织设计
产品经理
- 必看：#1 #2 #3 #9
- 重点：通用语言、子域划分、中台识别
- 技能要求：业务建模、跨团队沟通
四、落地建议（按成熟度分阶段）
总览图模块 ③ 用 5 张卡片画了「业务初期 → 业务成长期 → 业务复杂期 → 中台建设期 → 规模化期」的成熟度路线。下面把每个阶段团队规模、关键动作、产出物展开：
阶段 0：业务初期（团队 < 10 人）
- 不要做 DDD。三层架构 + 单体足够。
- 关注点：跑通业务，验证模式。
- 产出：稳定的业务系统。
阶段 1：业务成长期（团队 10-50 人）
- 开始引入 DDD。先做一个微服务试点。
- 必做：通用语言 + 限界上下文。
- 产出：1 个 DDD 微服务作为样板。
阶段 2：业务复杂期（团队 50-200 人）
- 全面 DDD。所有新服务按 DDD 规范。
- 必做：聚合设计 + 领域事件 + 分层架构。
- 产出：标准化的微服务体系。
阶段 3：中台建设期（业务 ≥ 3 条线）
- 识别中台机会。核心能力 + 通用能力中台化。
- 必做：业务梳理 + 跨中台领域扫描。
- 产出：业务中台 + 数据中台。
阶段 4：规模化期（多业务 / 集团）
- 中台成熟。持续优化和演进。
- 必做：中台治理、领域模型迭代、组织调整。
- 产出：可持续的中台体系。
五、避坑清单
我整理了 10 个最容易踩的坑：
| # | 坑 | 正确做法 |
|---|---|---|
| 1 | 所有子域都按核心域标准做 | 区分核心/通用/支撑，资源倾斜核心域 |
| 2 | 上下文越多越好 | 能在一个上下文搞定的就别拆 |
| 3 | 数据库表直接对应实体 | 实体要充血模型，业务行为在实体里 |
| 4 | 业务逻辑放在应用层 | 业务规则放领域层，流程放应用层 |
| 5 | 跨聚合同步调用 | 一次事务只改一个聚合 |
| 6 | 微服务内滥用事件总线 | 能用应用服务直接编排的，就别用事件总线 |
| 7 | 事件忘了幂等 | 订阅方必须实现幂等 |
| 8 | 中台过早抽象 | 业务稳定 1 年以上再考虑中台 |
| 9 | 忽略康威定律 | 中台需要专门的中台团队 |
| 10 | 微服务拆太细 | 一个微服务 2-5 个聚合是合理颗粒度 |
六、推荐阅读书单
我自己在 DDD 学习过程中受益最大的几本书：
入门必读
- 《领域驱动设计精粹》 Vaughn Vernon：DDD 入门最快的书，案例丰富。
- 《领域驱动设计》 Eric Evans：DDD 圣经，原作。
实战必读
- 《实现领域驱动设计》 Vaughn Vernon：战术设计的详细参考。
- 《微服务架构设计模式》 Chris Richardson：微服务落地的实战指南。
架构延伸
- 《整洁架构》 Robert C. Martin：架构内功。
- 《企业 IT 架构转型之道》 钟华：阿里巴巴中台战略思想与架构实战（⚠️ 2020 年视角下的推荐；阿里 2023 年已拆分中台，此书建议作为历史参考阅读，不代表当前最佳实践）。
七、最后想说
DDD 不是一个技术，它是一种思维方式。
它教你：
- 用边界来组织复杂度。
- 用通用语言来消除误解。
- 用领域模型来沉淀知识。
掌握这套思维方式，比任何具体技术都更有长期价值。
我自己在不同公司带团队时，最深的感受是：
技术是工具，业务是核心，组织是关键。 DDD 是少数能同时贯穿这三者的方法论。
如果你只能记住一句话，记住这个：
业务先于技术，模型先于代码，边界先于实现。
系列完整目录
- 为什么从领域开始 — 战略设计入门
- 领域与子域 — 核心/通用/支撑三类子域
- 限界上下文 — 通用语言与微服务边界
- 实体与值对象 — 战术设计基础
- 聚合与聚合根 — 一致性边界
- 领域事件 — 解耦微服务
- DDD 分层架构 — 代码组织
- 整洁/六边形/分层 — 架构选型
- 中台 — 企业级能力复用
- DDD+中台+微服务协作 — 端到端流程
总结（本文） — 收官之作
致谢
感谢你能读到这里。
愿你在复杂业务的战场上，有 DDD 为伴。
后续我会继续写其他主题（架构演进、领域事件深入、中台治理等），如果感兴趣，欢迎持续关注。