DDD 是什么：为什么微服务设计要选择 DDD

学习《DDD实战课》（欧创新）的笔记，结合自己的理解整理。这是第一篇，先把"DDD 到底解决什么问题"讲清楚。

一、微服务拆分的老大难问题

做过微服务的团队基本都吵过一个问题：服务到底拆多细？边界划在哪？

我见过的典型场景：几个人对着一个单体系统讨论拆分方案，每个人按自己的理解拆出来的服务都不一样，谁也说服不了谁，最后靠拍脑袋定，上线之后运维天天救火。

问题的根源不是技术，而是——没人说得清业务的边界在哪里。连微服务概念的提出者 Martin Fowler 都没告诉大家该怎么拆。所以就出现了两种极端：

• 把单体拆成几个部署包就自称微服务
• 无脑拆细，越小越好，结果复杂度爆炸，上线都费劲

而 DDD（领域驱动设计）恰好就是解决"边界"问题的方法论。

二、DDD 和微服务的时间线

有个挺有意思的事：DDD 是 2004 年 Eric Evans 在《领域驱动设计》里提出的，比微服务早了差不多十年。但 DDD 提出后很长时间都是"雷声大雨点小"，直到微服务火了，大家发现拆分没有章法，回头一看——DDD 的领域边界思想正好能指导微服务拆分，这才真正流行起来。

一句话总结两者的关系：

DDD 负责"往哪拆"（业务边界），微服务负责"怎么跑"（技术落地）。

	DDD	微服务
本质	架构设计方法论	架构风格
关注点	领域边界划分、领域建模、业务与代码一致性	进程间通信、容错隔离、独立部署
视角	业务视角	运行时视角

三、DDD 的两大块：战略设计和战术设计

DDD 整套体系可以分成两部分，记住这个框架，后面所有概念都能挂在上面：

1. 战略设计（业务视角）——解决"往哪拆"

• 从业务出发，建立领域模型
• 划分领域边界，形成限界上下文
• 限界上下文 ≈ 未来微服务的边界

2. 战术设计（技术视角）——解决"怎么写代码"

• 把领域模型落成代码：聚合根、实体、值对象、领域服务、仓储等
• 保证代码结构和业务模型一一对应

四、从业务到微服务的三步走

DDD 建模的主要方法是事件风暴（后面会专门写一篇），整体是一个"先发散、再收敛"的过程：

1. 第一步：事件风暴，梳理业务流程里的用户操作、事件、外部依赖，找出领域实体
2. 第二步：把业务上紧密相关的实体组合成聚合，确定聚合根——这是第一层边界（逻辑边界，同一个微服务内）
3. 第三步：把一个或多个聚合装进一个限界上下文——这是第二层边界（物理边界，很可能就是微服务边界）

两层边界划清楚了，微服务怎么拆自然就有答案了。而且以后业务变了要重新拆分，也是按聚合为单位挪动，代价可控。这就是所谓的演进式架构。

五、DDD 不是银弹，几点提醒

• 战术设计门槛不低。对团队的设计能力有要求，不同公司研发水平差异很大，落地前要评估
• 业务简单就别硬上。DDD 擅长的是高复杂度业务领域，CRUD 系统套 DDD 纯属折腾自己
• DDD 不仅能指导微服务，也适用于单体应用，还能指导中台业务建模（后面中台篇会展开）

六、我的理解

学 DDD 之前，我做设计的习惯是从数据库表开始——先设计表和字段，再写代码。这其实是"数据驱动"。DDD 反过来了：先理解业务、建领域模型，代码和数据库都是模型的映射产物。

这个思路转变才是 DDD 最值钱的部分，术语反而是次要的。