DDD系列-背景

其实笔者认为，在软件的发展过程中，业务价值始终是排在第一位的，笔者之前所在的公司一直是敏捷开发模式，问题也基本上朝着单体应用的毛病一步一步演进，但是在期间也创造了大量的业务价值。在演进的过程中，会出现各种问题，更高级的开发模式往往能解决更多的问题，但是这并不大表越高级越好，适合当前业务的模式才是最好的开发模式。

瀑布流开发模式

模式介绍

软件设计有不同的方法，其中之一是瀑布设计法。这种方法包含了一些阶段，业务专家提出一堆需求同业务分析人员进行交流，分析人员基于那些需求来创建模型并将结果传递给开发人员，开发人员根据他们收到的内容开始编码。瀑布设计法中知识只有单一的流向。这种传统方法虽然应用很多年，但是还是有一定的缺陷和局限。主要是业务专家得不到分析人员的反馈信息，分析人员也得不到开发人员的反馈信息。

假设要做一个在线售卖机系统，那这个售卖机所有的用例集合起来称为需求，然后严格按照需求-设计-开发-测试一次性搞定。

有的人可能会有疑问，我们现在不就是这样开发的吗，注意，这里的需求不同于我们平时PM说的需求，PM层面的需求是一个一个用例，这里的需求是所有的用例集合。

整个过程可以用下图描述

主要缺点

这种方式的主要缺点是周期长，没有反馈闭环，项目失败的风险极高。而且，这种方式一开始就确定了所有需求，考虑面面俱到，但是这所有的需求中大部分的需求

都没有机会使用。这种方式的项目大部分以失败告终。

主要优点

但是，有一些场景必须用瀑布流开发模式，比如航天飞机，摩天大楼这些中途一旦变更需求，将会造成巨大的成本，所以肯定是需求阶段就已经面面俱到了。

敏捷开发模式

模式介绍

由于瀑布流开发模式失败率太高，另一个方法是敏捷方法学，这些方法不同于瀑布方法的一堆动作，产生背景是预先很难确定所有的需求，特别是需求经常变化的情况。敏捷开发试图解决另一个问题被称为"分析瘫痪"，团队成员会因为害怕做出任何设计决定而无济于事。敏捷开发者反对预先设计，相反，他们应用大量的灵活设计。在敏捷设计者的眼中，他们崇尚，天下武功，唯快不破。

还是用售卖机为例子，那这个售卖机中的一个支付支持作为一个需求，就仅仅这一个需求在敏捷者的眼里，也不会一次性开发完成，而是周期迭代方式进行。

敏捷开发的优点非常多，比如团队协作，项目风险控制，市场验证，非常适合创新项目，也是现在很多公司主流的开发模式

主要缺点

敏捷开发也有自己的不足，敏捷开发缺乏真实可见的设计原则，由开发人员执行持续重构会导致代码难以理解或者难以变更。瀑布流会过度工程，过度工程可能会带来另一种担心：害怕做出深度，彻底的设计。

敏捷开发非常考验开发者的功底，而且敏捷开发由于一开始并没有对完整需求做出一定合理性设计，最后可能演变成一个大单体应用，错综复杂，痛不欲生。

主要优点

第一个版本会非常快出来，并且确保满足用户需求的情况下再进行下一步迭代，这种就像搭建一个2层楼小平房，中途可以按照用户要求各种改，非常低的试错成本，并且会搭建这种小平房的人相对比较多

沦落成大单体

业务初期，我们的功能大都非常简单，普通的CRUD就能满足，此时系统是清晰的。但是对着迭代的不断演化，业务逻辑变得原来越复杂，我们的系统也越来越冗杂。这里面很大一部分原因来自市场压力，竞争压力大，如果业务不快速迭代，就会面临淘汰，其实也没什么办法，确实活下来才是第一要务。我们的模块彼此关联，很难说清楚模块的功能意图是啥，往往修改一个功能时，要回溯的时间，以及回溯涉及的面远远超出预期。硬着头皮往前冲，最后全部业务逻辑耦合在一起沦为大单体。

对研发而言，很容易形成如下的恶性循环：

新入职的研发因为担心修改遗留代码而出现不可预知的BUG，所以宁愿增加大量不必要的代码，也不愿意去冒一点风险。会导致应用越来越大，功能越来越复杂，可读性越来越差，最终陷入恶性循环。

下面是常见的单体系统耦合情况

1）开发问题：所有的业务，开发人员都在一个大App上修改需求，代码提交冲突严重，RD哭了

2）部署问题：必须统一部署，统一上线，没有差异化而言，一周能进行2次没有问题的部署算是烧了高香，说好的高效呢，PM哭了

3）大表问题：所有的字段集中到一个DB存储，甚至就放在一张表中，DBA哭了

4）测试问题：没有边界，测试只能黑盒测试，需要回归大量的用例，QA哭了

领域驱动开发

毫无疑问，敏捷开发依然是现在项目初期非常好的一个选择，对于一个竞争非常激烈，生死存亡的创新型项目，完全可以用敏捷开发的模式。到达一定阶段后，会到瓶劲期（不过相信项目已经活下来了），那大单体的毛病就会凸显出来了。

技术层面的重构能解决吗

这个时候有的技术人员可能单纯从类内部，函数内部做优化，尝试找到一种合理性的局部架构。更有甚者，尝试将每个表封装成微服务的增删改查，然后嵌入到大单体应用中，这种做法现在流行叫做"分布式大单体"，它除了改变请求协议之外，没有做出任何对业务有实质行的重构。

领域驱动开发认为：从技术层面无法看到全部问题，甚至只能看到很小的局部性问题。那么有没有一种解决方案能也从业务角度出发，涉及模型设计，代码开发全流程进行改造呢？有，目前普遍流行的DDD解决这个问题

DDD

前面描述到，DDD尝试从业务角度进行模型设计，所以以前产品和开发对话"对牛弹琴"的现象会极大减少，我们会在后面的篇幅介绍DDD如何解决这种普遍现象的。DDD包含的是一套从用户故事分析-领域划分-领域建模-领域实现的一套方法论。

DDD最核心的思想是使用建模来降低业务的复杂度。 

附件

看看单体应用的代码可以有多恐怖，和笔者的曾经的公司简直一摸一样。（截图来自B站，应该不会暴露公司隐私吧）

一个文件3000行，一个函数2000行，仅此而已。