背景
工作了这些年，进入多家公司，发现代码风格都不太一样，或许和各司制定的开发规范有关系，但不管怎样，随着业务功能增加，代码体量越来越臃肿，可维护性变的很差，不是自己开发功能根本不敢改，最后实在改不动的话，一般都会招新的技术牛人做重构，推倒重来，给公司造成成本上升，相信做过开发的小伙伴们都会感同身受。
那么，随着时间的推移，你会遇到什么样的工程问题呢？
- 工程体积庞大；
- 需求迭代会出现明明是类似的功能，却无法复用代码逻辑的情况；
- 重复的代码很多；
- 大类（几千上万行）随处可见；
- 出了 Bug 不敢直接修复，只能继续往上贴逻辑；
- 代码可读性很差，不加注释你都难以理解业务逻辑；
- 功能之间耦合严重，改了一个 Bug，莫名其妙又出现了好几个其他的 Bug；
- 外部系统 RPC 接口修改，大范围影响到本系统的逻辑；
- ……
总之，我们会遇到3种困境：
- 不知道有问题，一直堆代码，乐此不疲
- 知道有问题，但不知道如何解决，自己很困惑迷茫
- 知道有问题，可就是解决不好，总带来新问题
归根到底的原因是什么？
传统软件架构MVC存在弊端。
方案
我们静下来想一想，如果我们开发代码和现实世界的领域对应上，尽可能的还原世界，那是不是代码就清晰多了，代码的可阅读性会提高、可维护性变得容易，而DDD（领域驱动设计）高内聚、低耦合正好可以解决。
MVC 分层下，不论是系统内交互还是系统与外部交互，逻辑都是按照功能点被杂糅在一起。Service 层利用 DO、DTO、VO 等业务 POJO 作为数据载体，完成了所有模型之间的逻辑处理、数据转换等跟业务有关或者无关的事情。Service 层臃肿且条理不清晰。就像是吃大乱炖，什么都往里面加，反正最后能吃就行。而这些 POJO 除了字段属性，内部没有任何的业务逻辑，这就是典型的贫血模型。
DDD 核心思想是什么呢？解耦与内聚！建立领域模型形成聚合根，将原先散落在 Service 层的业务逻辑收拢到领域模型内部，变成充血模型，聚合即为业务。业务不是像炒大锅饭一样混在一起，而是一道道工序复杂的美食，都有它们自己独立的做法。
通过上面的介绍和剖析，不难总结出 DDD 主要有以下优势。
- 从业务出发，自顶向下设计系统，优先考虑领域模型，而不是切割数据和行为，告别贫血模型；
- 领域设计简化复杂业务，内聚逻辑实现，准确传达业务规则，分而治之；
- 应用服务层的编排即展示了业务逻辑，增强了代码的可读性与可维护性；
- 消除业务参与人员的信息不对称，提升协助效率；
- 将外部系统等不可控因素转化为可控因素，减小系统间依赖；
- 适合于业务复杂的中台化的系统设计。
到底什么样的系统适配DDD
看完上文对于 DDD 的分析之后，你是不是觉得一对比，MVC 简直就是“弟弟”？但是你回过头来想想，DDD 其实在十几年前就已经被提出来了，但为什么是近几年才开始逐渐进入大众的视野呢？总结起来，主要有以下几条原因。
- DDD 的结构不像 MVC 结构那么简单，分层更加复杂。
- 消除信息不对称的成本比较大，需要多方人员协作讨论业务模型。
- 迭代快的小系统不如直接使用 MVC 做好代码规范能够更快地上线。
因此，不适配 DDD 的系统是什么呢？
- 中小规模的系统，本身业务体量小，功能单一，选择 MVC 架构无疑是最好的。
- 项目化交付的系统，研发周期短，一天到晚按照甲方的需求定制功能（这种本身业务需求边界就不清晰，功能的可持续迭代性就很差，而且这种系统一般就是一口价买卖），这种也最好选择 MVC。
那相反地，适配 DDD 的系统是什么呢？中大规模系统，产品化模式，业务可持续迭代，可预见的业务逻辑复杂性的系统。
总而言之就是：
- 你还不了解 DDD 或者你们系统功能简单，就选择 MVC；
- 你不知道选用什么技术架构做开发，处于业务探索阶段，选用 MVC；
- 其他时候就酌情考虑 DDD。
这篇是个引子，后续会陆续更新DDD细节，欢迎关注。