背景
在互联网软件领域，对于DDD的认知，充斥着广泛且深刻的误解，比如：
DDD概念很复杂且抽象
DDD只适合复杂的大型系统
DDD没有用
为了搞清楚这些误解的本质和根源，今天，我们来聊聊DDD和非DDD的理念的最本质的区别，以及这种区别映射到现实，又是怎样呈现出来和发生作用和影响到。
为了方便表述，这里我们使用CRUD来代表非DDD的范式。
先对齐一下概念
为了大家能够建立统一的视角来探讨，需要先对齐一下概念，我们这里所说的DDD与网络上其他人所说的DDD是有差异的：
我们去掉了很多抽象的概念（子域、限界上下文、战略设计、战术设计）
我们所说的DDD，本质上是一种价值取向
我们为这个价值取向，定义了一套易于理解且可操作的原则
这里我们所说的DDD核心概念仅包括：
聚合即领域
领域事件
命令
查询
基于我们所认可的DDD价值观，推演出来的核心原则：
聚合之间不相互引用，即没有“耦合”
当聚合之间需要相互作用时，使用“领域事件”来达成目的
出发点
要说DDD，我们就要思考为什么要DDD，我们的观点是，DDD可以帮助我们掌控复杂度，从而掌控软件系统的迭代成本。
也就是说，我们的目的是掌控复杂度，要判断我们是否达成了这个目标，就需要一个衡量标准，来衡量不同的方案带来的复杂度。
取舍之间，彰显智慧
那么究极问题就是“什么是复杂？什么是简单？”。在我们打造一个软件系统时，最核心的组成部分，可以抽象为两个：
系统内的元素
元素之间的关系（即相互作用）
这两个要素，组成了软件系统，当然，也是软件系统复杂度的组成部分。那么当我们在面临软件需求给出解决方案时，就可以有两种倾向：
用元素之间的关系来解决问题
用更多的元素来解决问题，避免建立元素之间的关系
那么DDD和CRUD的核心差异也就是在这里，取舍之间，决定了我们走完全不同的路线：
可能上面的描述不太具体，这里我举个例子大家就更容易理解。
设计RBAC权限系统，有用户、角色、权限点这些要素，那么，会有一个需求叫“查看用户拥有的角色”：
CRUD，会设计一个关系表，表述用户和角色之间的关联关系，这个关系表本质上是“关系”，它处于用户和角色之间。
DDD，会为用户设计一个子实体，表示用户拥有哪些角色，会包含角色的标识和名称等必要的信息，这个子实体看起来很像“关系”，但它处于用户内部，它的存在，增加了实体的数量。
道
很神奇的巧合，道德经第四十二章：“道生一，一生二，二生三，三生万物”，我猛然间发现，前面我们所述的“核心区别”，就是DDD和CRUD的“道”之不同，因为“道”的不同，我们在面对问题时，做出的决策是不同的，最终就是道生一，一生二，二生三，三生万物，我们在软件系统内生出的万物也就形成了完全不同的景象：
CRUD，因为使用关系，而获得万物互联的状态
DDD，因使用数量，而获得各自成块的状态
另外一面
我相信，看到这里，大家会发现，如果切换成技术术语，来描述前面所述的核心区别，应该是：
CRUD倾向于用元素之间的关系来解决问题
DDD倾向于“冗余数据”来避免元素之间的关系
我相信，到这里你一定会意识到，在实际的项目中，我们最经典的决策点就是：关联还是冗余？那么这个核心区别就可以等价为：关联代价大，还是冗余代价大？我相信大部分情况下会是这样的情形：
CRUD认为冗余代价大
DDD认为关联代价大
为什么会有分歧
如果您有通读过我之前的文章，那么一定会对我的一个观点有印象：
工具会影响认知
认知会影响工具的选择
基于这样的观点，我发现CRUD和DDD在技术实现层面最核心的差异就是“事件”，而这个“事件”的技术实现，核心意义就是解决聚合之间的相互影响和协作，基本上决定了“冗余”的代价大小，从而影响开发者在决策时候的判断。
也就是说，开发框架对“事件”的支持程度，决定了“冗余”代价的大小，从而影响了开发者的“道”，最终影响了所有的关键决策，从而走向了完全不同的方向。
人的偏见是一座大山
那么，我们回到现实，很抱歉，目前国内广泛应用的“主流”技术框架，并不关心“事件”这件事，开发者自身也很难在这样的背景下迭代认知，撬动工具改变。工具和认知形成了一个强大的相互制约，虽然我也看到不少DDD实践者在努力推动工具和认知的发展，至少目前看来，在“你发任你发,我用Java 8”的当下，距离成为主流还有很远的路要走。
诗和远方
DDD在软件工程领域具有非常好的复杂度控制能力表现，这种能力会直接体现在软件团队的交付效率上，而这正是软件团队的核心能力之一，改良和简化后的DDD将具备良好的普世性和竞争力，因此长期来看，DDD将有机会成为软件工程的标配。
至于现在，我觉得，但行好事，莫问前程。