图穷匕见-所有反DDD模式都是垃圾

本文书接上回《主观与客观，破除DDD凭经验魔咒》，关注公众号（老肖想当外语大佬）获取信息：

1. 最新文章更新；

2. DDD框架源码（.NET、Java双平台）；

3. 加群畅聊，建模分析、技术实现交流；

4. 视频和直播在B站。

开个玩笑

"我不是针对这一个问题，我是说所有的反DDD模式都是垃圾"，作为教练，在团队中我时常用这样的玩笑来调侃不符合DDD价值观的判断逻辑和决策结果，并指出具体不符合的点在哪里，由于大家已经相互非常了解，能够很快反应过来并建立共识，从而不断修正决策逻辑和决策结果，使问题的范围和解决方案收敛在一个确定的范围内，持续地保持对系统复杂度的掌控。

===

前提条件

首先需要对齐我们讨论的场景，主要在下面的条件范围内：

1. 软件系统是长期迭代的

2. 软件系统是业务向的系统

在这个条件范围下，我们可以解读为：

1. 我们认为迭代成本是软件成本的重要组成部分

2. 我们认为自己打造的软件系统的业务复杂度高于技术复杂度

成本与复杂度

为了尽可能降低系统迭代的综合成本，本质上就是掌控系统复杂度，而系统复杂度由业务复杂度和技术复杂度共同构成。

为了实现"掌控系统复杂度"的目标，基于复杂度守恒定律，我们有以下观点：

1. 复杂度不可被消除，只可被转移

2. 尊重业务固有复杂度

3. 避免引入额外技术复杂度

而我们在《关于领域驱动设计，大家都理解错了》一文推导过关于复杂度的结论：

1. 系统复杂度与元素的数量和元素的关系有关；

2. 元素的关系对系统复杂度的影响远远大于元素的数量所产生的影响；

===

核心观点

如果你已经跟随《老肖的领域驱动设计之路》系列一路读过来，那么我们接下来的推导过程就需要在之前构建的认知基础上进行，这里列出核心观点以供复习：

1. 领域驱动设计是一种价值观

2. DDD价值观：边界明确是最重要的事

3. 软件长期主义：可维护性是最重要的事

4. DDD是软件工程的第一性原理

基于上面这些观点，DDD的核心，就是掌控系统元素之间的关系，明确边界，将复杂度控制在一个个有限的范围内，完全匹配软件工程的成本控制的逻辑，那么是不是就可以得出下面的结论：

1. 符合DDD价值观，意味着符合软件工程的成本利益

2. 反DDD的模式，意味着不符合软件工程的成本利益

那么回到本文的标题，"所有反DDD模式都是垃圾"，更准确的描述应该是"所有反DDD模式都是不符合软件工程成本利益的"，我认为，这个逻辑是成立的。

如果你认同《DDD是软件工程的第一性原理？》一文的观点，那么同样也能得出这样的结论，违反软件工程第一性原理，当然会适得其反，走向系统快速失控的深渊。

所以，很抱歉，如果你的软件设计思维，没有围绕着"明确和维护边界"来开展，那么大概率是错误的价值判断思路，系统的复杂度大概率也很难被掌控，而具象化出来的现象，就是我们常说的"迭代不动了"。

那么，快来和我一起实践DDD吧！