知识卡片
用DDD设计单体应用，也能为未来的微服务拆分铺路
内容
DDD不仅适用于微服务拆分和设计，同样适用于单体应用。如果单体应用在设计之初就采用DDD方法，内部会天然形成多个聚合，聚合之间是松耦合的，聚合内部的功能则是高内聚的；有了这层清晰的聚合边界，未来某天真的需要把这个单体拆分成多个微服务时，会比传统三层架构设计出来的单体容易得多——因为拆分工作本质上只是把已经存在的聚合边界，从”逻辑边界”升级成”物理边界”，不需要从零去梳理业务到底该怎么切。这个思路特别适合一类常见的现实处境：项目当前还不具备微服务运行所需的基础设施和运维能力，但业务复杂度已经逼近必须重构的临界点——与其在不具备条件时强行上微服务，或者继续用传统三层架构堆砌代码、把拆分的代价留给未来，不如先用DDD方法把单体内部的边界理清楚，等具备微服务运行支撑能力后再实施拆分，这样可以把”想清楚边界”和”具备物理拆分的基础设施条件”这两件事解耦，不必等到条件都齐备才开始做正确的设计。
参考来源
- 位置：第3章《微服务设计为什么要选择DDD》"3.4 本章小结"（源文件：_epub-src/OEBPS/Text/chapter2-3-4.xhtml）
- 结论依据：原文说明"DDD不仅适用于微服务拆分和设计，同样也适用于单体应用。如果单体应用采用了DDD方法设计，当某一天你想将单体应用拆分为多个微服务时，你会发现采用DDD方法设计出来的单体应用，拆分起来比采用传统三层架构设计出来的单体应用容易很多……这种设计方式特别适合当前不具备微服务运行支撑能力，但又必须完成系统重构，待具备能力后再进行微服务拆分的项目"，直接支撑本卡片结论。
- 原始内容：这是因为用DDD方法设计的单体应用，在应用内部会有很多聚合，聚合之间是松耦合的，但聚合内部的功能具有高内聚的特点。有了这一层清晰的聚合边界，我们就可以很容易完成从单体应用向微服务的拆分了。这种设计方式特别适合当前不具备微服务运行支撑能力，但又必须完成系统重构，待具备能力后再进行微服务拆分的项目。