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

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

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

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

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

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