- 领域驱动设计 vs. 数据驱动设计
- 领域驱动设计的黑铁时代和黄金时代
- 单体架构是邪恶的吗
- 领域驱动设计的不足与领域驱动设计统一过程
¶ 领域驱动设计 vs. 数据驱动设计
通过比较领域驱动设计和数据驱动设计，探讨为何基于数据库进行设计容易催生出贫血模型与事务脚本，指出领域驱动设计与数据驱动设计的不同之处在于限界上下文和聚合。
拙著《解构领域驱动设计》特别强调了限界上下文和聚合的重要性，分别将其称之为是基本的架构单元和设计单元。限界上下文与聚合的引入，也是领域驱动设计有别于面向对象设计的根本特征。
¶ 领域驱动设计的黑铁时代和黄金时代
由此引出我对诞生于2003年的领域驱动设计为何得不到广大程序员青睐的原因。
除了在团队管理、需求管理和项目管理方面，领域驱动设计提出了更高要求之外，多数软件设计人员并未认识到限界上下文与聚合的价值；相反，由于限界上下文与聚合边界对设计的诸多限制和约束，程序员更倾向于选择简单的事务脚本和贫血模型的设计模式，更何况，大多数早期软件系统并无高并发、高可靠等质量属性的压力，无法预见到限界上下文在应对架构演进时的重要意义，故而更愿意选择重用领域逻辑的单体架构。这样的单体架构缺少限界上下文的边界保护，随着需求的变化和时间的推移，较容易成为大泥球。直到微服务的诞生——
大多数软件设计人员充分认识到，原来，十余年前领域驱动设计的限界上下文已经给出了微服务的边界约束，只不过一个是逻辑边界，一个是物理边界罢了。
¶ 单体架构是邪恶的吗？
在限界上下文边界约束下的单体架构并不邪恶，只是相较于微服务而言，它的重用成本更低，无法在有效边界隔离下制止那些肆意穿越限界上下文边界形成领域模型重用的调用，从而得到了这一恶名。
因此，我在整洁架构与六边形架构的基础上提出了菱形对称架构，希望在代码模型和设计原则上促进开发人员认识到边界的约束力，提高整个系统架构的演进能力。
¶ 领域驱动设计的不足与领域驱动设计统一过程
我承认领域驱动设计无论伦比的设计魅力，尊敬Eric Evans卓越的洞见与设计前瞻能力，但也不讳言领域驱动设计本身存在的不足。
这几年，领域驱动设计随着微服务的流行变成了显学，但领域驱动设计不是“银弹”，既然如此，领域驱动设计统一过程（DDD-UP）就更不是“银弹”了，它不过是对领域驱动设计的一种补充和完善罢了。
浸淫软件设计近二十年，我越来越觉得设计玩不得玄虚，不要认为设计是一种“道”，它自有不可言说之处，但那种高妙不是高冷，更不是“道可道非常道”，关键还是落地。若能提供一种简便实用的方法让一套方法体系更容易落地，何乐而不为？！理论体系当然重要，但更重要的是能够真正将方法体系运用到软件构建中，降低开发门槛，提升设计与编码质量，这才是实证主义的态度。
