本文书接上回《主观与客观，破除DDD凭经验魔咒》，关注公众号（老肖想当外语大佬）获取信息：
- 最新文章更新；
- DDD框架源码（.NET、Java双平台）；
- 加群畅聊，建模分析、技术实现交流；
- 视频和直播在B站。
开个玩笑
“我不是针对这一个问题，我是说所有的反DDD模式都是垃圾”，作为教练，在团队中我时常用这样的玩笑来调侃不符合DDD价值观的判断逻辑和决策结果，并指出具体不符合的点在哪里，由于大家已经相互非常了解，能够很快反应过来并建立共识，从而不断修正决策逻辑和决策结果，使问题的范围和解决方案收敛在一个确定的范围内，持续地保持对系统复杂度的掌控。
前提条件
首先需要对齐我们讨论的场景，主要在下面的条件范围内：
- 软件系统是长期迭代的
- 软件系统是业务向的系统
在这个条件范围下，我们可以解读为：
- 我们认为迭代成本是软件成本的重要组成部分
- 我们认为自己打造的软件系统的业务复杂度高于技术复杂度
成本与复杂度
为了尽可能降低系统迭代的综合成本，本质上就是掌控系统复杂度，而系统复杂度由业务复杂度和技术复杂度共同构成。
为了实现“掌控系统复杂度”的目标，基于复杂度守恒定律，我们有以下观点：
- 复杂度不可被消除，只可被转移
- 尊重业务固有复杂度
- 避免引入额外技术复杂度
而我们在《关于领域驱动设计，大家都理解错了》一文推导过关于复杂度的结论：
- 系统复杂度与元素的数量和元素的关系有关；
- 元素的关系对系统复杂度的影响远远大于元素的数量所产生的影响；
核心观点
如果你已经跟随《老肖的领域驱动设计之路》系列一路读过来，那么我们接下来的推导过程就需要在之前构建的认知基础上进行，这里列出核心观点以供复习：
- 领域驱动设计是一种价值观
- DDD价值观：边界明确是最重要的事
- 软件长期主义：可维护性是最重要的事
- DDD是软件工程的第一性原理
基于上面这些观点，DDD的核心，就是掌控系统元素之间的关系，明确边界，将复杂度控制在一个个有限的范围内，完全匹配软件工程的成本控制的逻辑，那么是不是就可以得出下面的结论：
- 符合DDD价值观，意味着符合软件工程的成本利益
- 反DDD的模式，意味着不符合软件工程的成本利益
那么回到本文的标题，“所有反DDD模式都是垃圾”，更准确的描述应该是“所有反DDD模式都是不符合软件工程成本利益的”，我认为，这个逻辑是成立的。
如果你认同《DDD是软件工程的第一性原理？》一文的观点，那么同样也能得出这样的结论，违反软件工程第一性原理，当然会适得其反，走向系统快速失控的深渊。
所以，很抱歉，如果你的软件设计思维，没有围绕着“明确和维护边界”来开展，那么大概率是错误的价值判断思路，系统的复杂度大概率也很难被掌控，而具象化出来的现象，就是我们常说的“迭代不动了”。
那么，快来和我一起实践DDD吧！