Domain-driven design并不是一个新鲜的东西，从 2004 年Eric Evans提出这个理念以来，十几年间时不时就有一股DDD的热潮，近几年随着微服务的大行其道，DDD又成了宠儿。但终究逃不过雷声大雨点小。

领域驱动设计最根本的思路是一套自上而下的设计方法，即从要解决的问题领域或系统目标出发，由业务和架构专家一起，对复杂的业务场景和关联性进行分组归类，形成一个一个相对单一职责的子领域。子领域和子领域之间要有明确的界限。在子领域内部，再通过业务上的模型去归类对应的属性和行为。

从设计思想上看，我非常赞同自上而下的架构设计理念，也在不断践行。但今天在技术圈里流传的DDD早已超出了上述的定义，而变成了一套以充血模型为基础，围绕聚合根，并通过门面代理、分离查询、事件传播等手段的软件架构方法。通过这种构建，想达成三种目的：

  • 统一语言：业务与技术统一
  • 让行为回归到实体中去
  • 降低传统service层的复杂度

我所不采纳的即是这样一种“术”，有三个主要原因。

  • 行为是变化的，对象的表达却是几乎不变的，将变化的与不变的聚合在一起，违反了动静分离的原则。
  • 软件实现的是策略，最终想要引发的是对象的变化，对象的变化最终是持有在DB中的，所以领域的划分是在数据库建模的时候去考虑的，而非在软件实现层面。数据库更贴近现实。
  • 领域驱动设计的实现模型会引入无谓的复杂度。而且除了垂直切分实现内聚之外，还需要考虑水平上的相似性，从而提高复用。这套架构方法很难去指导软件设计的真实过程。这也是目前DDD火归火，但落地少的一个原因吧