从架构设计的演进来看，我们真的需要 DDD

辛丑牛年的春晚已经渐行渐远，不知你是否留意，有个词在语言类节目中出现了多次，那就是“格局”。什么是格局？简言之就是认知维度高，不被浮云遮望眼更容易认清事物本质和发展趋势。众所周知，事物发展都是遵循一定规律的，也就是所谓的趋势，掌握趋势才能秉道而行，少走弯路，软件架构发展亦是如此！

早期在 servlet 和 jsp，applet 盛行的年代，软件开发基本上无架构可言，神通广大的 jsp 可以完成集页面展示，逻辑处理，数据操作一系列的功能。随着时间推移，其自身存在的一些问题也慢慢展现出来，一些问题现在看甚至是致命的，如页面复杂难以运维，排查问题困难，性能差等等。针对上述存在的问题，真正意义上的软件架构 MVC 慢慢开始流行。我们通常熟知的 MVC 架构，是按照 web 应用的几个职责进行分层划分的，即模型层（M）视图层（V） 控制层（C）。从最初的 struts 家族在 web 开发领域的独孤求败，到现在 spring mvc 的经久不衰，可以看出其是符合架构发展趋势的。即使初期有很多人抵制这种架构模式，认为过多的规范降低了开发的效率，但时间是最好的证明！

随着版本的不断迭代，业务逻辑的复杂性也越来越高，系统变得越来越臃肿。服务的功能模块只增不减，各个模块间又不断交织着千丝万缕的联系，最终导致项目组里没有人能清楚的了解其中的细节！即使一个很小的，看似微不足道的功能点修改，开发人员理清相关流程和影响范围所耗费的时间就比真正 coding 时间多出几倍甚至几十倍！另一方面 “铁打的系统，流水的开发”，不同开发人员的认知差异和技术水平的参差不齐加速了代码框架的腐败，系统搭建初期规划的合理的代码架构，随着时间的流逝也逐渐有了坏味道！逼迫开发从此走上重构-腐败-再重构循环往复的不归路。何解？简单分析后可以看出根因如出同辙，还是系统整体层面不可逆的复杂性！对应的软件架构又该如何演进呢？化繁为简，分而治之是个不错的方向，顺势而为“微服务”架构理念开始崭露头角。

何谓微服务？从字面解释就是将一个大的服务拆分成多个小的服务。看似很简单，但是如何拆，拆到多细的维度合适，就仁者见仁，智者见智了。由于项目组成员认知和侧重点的不同，提出的服务拆分方案也是五花八门，乍一看似乎所有的拆法都有其合理性。拆分过程中，几方坚持己见，争执在所难免。最终结果要么不欢而散，导致项目迟迟无法落地，要么技术负责人拍脑袋从个人认知出发选择其中一个看似更合理的方案，结果也可想而知了。拆分服务边界的确认迫切需要一种方法论或者思想来指导，沉寂了小 20 年的 DDD 终于要迎来高光时刻。

DDD 严格来说不是一种架构，而是一种架构的方法论，用于处理高度复杂领域的架构设计的思想。为什么把 DDD 视为现阶段架构设计的“版本之子”？主要其自身特性完全对症当下微服务的痛处，并且无出其右！业务方面，指导建立业务领域模型，划分领域边界，建立通用语言的限界上下文。技术方面，指导领域模型的技术实现，包括：聚合根、实体、值对象、领域服务、应用服务等代码逻辑的设计。

看到这，对老架构的 DDD 改造，或者开始学习 DDD 有没有一点点心动呢？来吧，我们一起行动起来吧，做一个顺应潮流的弄潮儿。不想被后浪拍在沙滩上，能做的只有不停的奔涌，奔涌……