本篇要回答的问题：微服务到底该怎么拆？为什么是 DDD？
微服务火了之后，团队最大的争吵不是"要不要拆"，而是"拆多大、按什么拆"。Martin Fowler 提出微服务架构时，也没回答"边界划在哪"。直到大家重新翻出 2004 年 Eric Evans 的 DDD，才发现它正好接上了这个口子。
本篇先看清楚架构演进到微服务后留下的难题，再看 DDD 如何用领域边界来解。
软件架构演进的三个阶段
| 阶段 | 设计方法 | 代表特征 | 痛点 |
|---|---|---|---|
| 单机架构 | 面向过程 | C/S 模式，UI + 数据库两层，从设计字段开始 | 强耦合、扩展难 |
| 集中式架构 | 面向对象 | 三层架构（接入 / 逻辑 / 数据库），部分采用 SOA | 系统臃肿、弹性差 |
| 分布式微服务 | 业务驱动 | 服务拆分、独立部署、独立演进 | 边界怎么划？ |
前两个阶段的共同问题：分析、设计、开发各干各的（A 提需求、B 分析、C 设计、D 写码），信息层层丢失，最后做出来的不是需求方想要的。微服务架构本来要解决这个问题，但它只解决了"怎么部署"，没解决"怎么拆"。
微服务时代的拆分困境
进入微服务后冒出来的常见争论：
- 微服务的粒度应该多大？
- 边界应该划在哪里？
- 是不是越细越好？
项目实践里常见两种极端：
- 一种是"换皮"：把单体应用拆成几个部署包就当微服务，结果只是把单体的复杂度从代码内挪到了网络间。
- 另一种是"拆碎"：信奉"越细越好"，结果服务之间依赖错综复杂，根本无法上线运维。
根本原因：不知道业务边界和应用边界到底在哪。只要边界确定了，"微服务怎么拆"就有答案了。
那边界由谁来定？这就是 DDD 入场的时机。
DDD 是什么？
2004 年 Eric Evans 在《Domain-Driven Design》提出 DDD。它"雷声大雨点小"了很多年，直到微服务时代才真正火起来。
一句话定义：DDD 是一种处理复杂业务的架构设计方法论，通过划分领域边界、构建领域模型，让业务模型和代码模型保持一致。
注意：DDD 不是架构本身，而是设计架构的方法。它分两部分：
| 部分 | 视角 | 主要工作 | 主要产出 |
|---|---|---|---|
| 战略设计 | 业务视角 | 划领域边界、建领域模型、定义通用语言 | 限界上下文（≈ 微服务的参考边界） |
| 战术设计 | 技术视角 | 把领域模型落地成代码 | 聚合根、实体、值对象、领域服务、应用服务、资源库 |
战略设计：三步划定微服务边界
战略设计的主要方法是事件风暴（Event Storming），一个"先发散、再收敛"的过程：
- 发散：用例分析、场景分析、用户旅程分析，尽量列出所有领域对象（实体、命令、事件）。
- 收敛：把这些对象按维度聚类，形成聚合和限界上下文。
具体落地三步走：
- 梳理领域实体：通过事件风暴找出用户操作、事件、外部依赖里的实体对象。
- 形成聚合：把业务紧密相关的实体组合成聚合，并确定聚合根、值对象和实体——聚合之间是逻辑边界（虚线），在同一个微服务实例内运行。
- 形成限界上下文：把一个或多个聚合圈在一个限界上下文里——限界上下文之间是物理边界（实线），就是未来微服务之间的边界。
两层边界一确定，微服务怎么拆就清楚了。
DDD 与微服务的关系
两者本质相同：从业务视角分离系统复杂度，追求高响应力。但关注的层面不同：
| 维度 | DDD | 微服务 |
|---|---|---|
| 关注什么 | 业务领域怎么划分、领域模型怎么建 | 服务怎么独立部署、怎么通信、怎么容错 |
| 核心问题 | 业务和代码如何保持一致 | 系统如何解耦、独立演进 |
| 抽象层次 | 业务架构 | 系统架构 |
简单说：DDD 解决"拆什么"，微服务解决"怎么部署"。两者从不同方向都在做同一件事——让业务变化时，系统能跟得上。
总结
本篇围绕一个核心问题：微服务到底该怎么拆？ 先回顾了软件架构从单机、集中式到微服务的演进路径，指出了微服务时代"拆多大、按什么拆"的真实困境；再给出 DDD 的解法——用事件风暴梳理业务，用聚合圈逻辑边界，用限界上下文圈物理边界，让微服务的拆分从"拍脑袋"变成"有据可依"。DDD 不是给微服务发牌照，而是给微服务画地图。
先把"是什么"回答清楚
| 概念 | 一句话说明 |
|---|---|
| DDD（领域驱动设计） | 用领域模型驱动软件设计的架构方法论 |
| 战略设计 | 从业务视角划边界、建模型 |
| 战术设计 | 从技术视角把模型落地成代码 |
| 领域模型 | 业务知识的结构化表达，是连接业务和代码的桥梁 |
| 限界上下文 | 业务和代码的边界单元，对应一个微服务 |
| 事件风暴 | 建立领域模型的主要方法，先发散后收敛 |
再讲"为什么 DDD 适合微服务"
- 微服务最难的是边界划分，DDD 的战略设计正好给出一套"业务驱动 → 领域模型 → 微服务边界"的标准流程。
- 这条流程保证了微服务"高内聚、低耦合"，并且业务变化时模型和代码能同步演进。
- 不只适合微服务，企业中台、单体重构同样适用。
一句话速记
微服务问的是"拆多细"，DDD 答的是"按业务边界拆"——拆什么由领域模型决定。
什么时候该用 DDD？
| 场景 | 是否值得用 |
|---|---|
| 业务复杂、领域逻辑多变 | ✅ 非常适合 |
| 企业中台建设 | ✅ 非常适合 |
| 单体演进到微服务 | ✅ 值得遵循其架构原则 |
| CRUD 主导的小系统 | ⚠️ 战术设计太重，不一定划算 |
| 团队没有领域专家深度参与 | ⚠️ DDD 强依赖业务方协作 |
战术设计落地门槛较高，对设计 / 开发能力要求大。团队能力跟不上时，建议先用战略设计的思想划边界，战术细节按团队情况渐进推进。
思考题
目前所在项目的微服务边界是怎么划的？如果用 DDD 的"事件风暴 → 聚合 → 限界上下文"流程重走一遍，会拆得不一样吗？
