DDD领域驱动设计.pdf

DDD领域驱动设计

2004年Eric
Evans
发表Domain-Driven
Design
‒Tackling
Complexity
in
the
Heart
of
Software
（领

域驱动设计），简称Evans
DDD。领域驱动设计分为两个阶段：

以⼀种领域专家、设计⼈员、开发⼈员都能理解的通⽤语⾔作为相互交流的⼯具，在交流的过程中发

现领域概念，然后将这些概念设计成⼀个领域模型；

由领域模型驱动软件设计，⽤代码来实现该领域模型；

由此可⻅，领域驱动设计的核⼼是建⽴正确的领域模型。

领域驱动设计的⼀个核⼼的原则是使⽤⼀种基于模型的语⾔。因为模型是软件满⾜领域的共同点，它

很适合作为这种通⽤语⾔的构造基础。使⽤模型作为语⾔的核⼼⻣架，要求团队在进⾏所有的交流是

都使⽤⼀致的语⾔，在代码中也是这样。在共享知识和推敲模型时，团队会使⽤演讲、⽂字和图形。

这⼉需要确保团队使⽤的语⾔在所有的交流形式中看上去都是⼀致的，这种语⾔被称为“通⽤语⾔

（Ubiquitous
Language）”。通⽤语⾔应该在建模过程中⼴泛尝试以推动软件专家和领域专家之间

的沟通，从⽽发现要在模型中使⽤的主要的领域概念。

DDD战略设计会建⽴领域模型
，
领域模型⽤来指导微服务的设计和拆分，
DDD第⼀步要做的就是来⼀

个头脑⻛暴，
可以理解成⼀起讨论对业务的理解
，
主要⽬的就是尽可能前⾯不遗漏的分解我们的业务

领域，
就好⽐刚刚的桃树，
最先要做的就是尽可能多的分析，
确保每⼀个领域都可以被关注到，
在

实践中
，往往会采⽤⽤例分析、场景分析和⽤⼾旅程分析，
这是⼀个发散的过程，头脑⻛暴阶段会产

⽣很多实体、命令、事件等领域对象，
我们从不同的维度对进⾏聚类形成聚合、限界上下⽂等边界，

建⽴领域模型，
这是⼀个收敛的过程。

具体来说，
我们可以通过三步来确定领域模型和微服务边界。

第⼀步
：在事件⻛暴中梳理业务过程中的⽤⼾操作、事件以及外部依赖关系等，根据这些要素梳理出

领域实体等领域对象。

第⼆步
：根据领域实体之间的业务关联性，将业务紧密相关的实体进⾏组合形成聚合，同时确定聚合

中的聚合根、值对象和实体。在这个图⾥，聚合之间的边界是第⼀层边界，它们在同⼀个微服务实例

中运⾏，这个边界是逻辑边界，所以⽤虚线表⽰。

第三步
：根据业务及语义边界等因素，将⼀个或者多个聚合划定在⼀个限界上下⽂内，形成领域模

型。在这个图⾥，限界上下⽂之间的边界是第⼆层边界，这⼀层边界可能就是未来微服务的边界，不

同限界上下⽂内的领域逻辑被隔离在不同的微服务实例中运⾏，物理上相互隔离，所以是物理边界，

边界之间⽤实线来表⽰。

上⾯除了领域、聚合、实体外还出现了聚合根、值对象等词语，
除此之外还有统⼀建模语⾔、⼦域、

核⼼域、通⽤域、⽀撑域等，
其实都是纸⽼⻁，
前⾯说过了为了⽅便对于某个领域的讨论往往会形成

⼀些概念，这些概念会有⼀些名词概括，
上⾯的名词就是这么来的，
这就叫统⼀建模语⾔
，
哈哈哈

，好了，不扯淡,
我后⾯的⽂章会解释下这些词语的意思，
这⼉主要讨论DDD解决什么了问题。

梳理⼀下
DDD与微服务
的关系，
DDD
是⼀种架构设计⽅法，微服务是⼀种架构⻛格，两者从本质上

都是为了追求⾼响应⼒，⽽从业务视⻆去分离应⽤系统建设复杂度的⼿段。两者都强调从业务出发，

其核⼼要义是强调根据业务发展，合理划分领域边界，持续调整现有架构，优化现有代码，以保持架

构和代码的⽣命⼒，也就是我们常说的演进式架构。

DDD
主要关注：
从业务领域视⻆划分领域边界，构建通⽤语⾔进⾏⾼效沟通，通过业务抽象，建⽴领

域模型，维持业务和代码的逻辑⼀致性。

微服务主要关
注：运⾏时的进程间通信、容错和故障隔离，实现去中⼼化数据管理和去中⼼化服务治

理，关注微服务的独⽴开发、测试、构建和部署。

1、DDD
包括战略设计和战术设计两部分

a、战略设计主要从业务视⻆出发，建⽴业务领域模型，划分领域边界，建⽴通⽤语⾔的限界上下⽂，

限界上下⽂可以作为微服务设计的参考边界。

b、战术设计则从技术视⻆出发，侧重于领域模型的技术实现，完成软件开发和落地，包括：聚合根、

实体、值对象、领域服务、应⽤服务和资源库等代码逻辑的设计和实现。

很多
DDD
初学者，学习
DDD
的主要⽬的，可能是为了开发微服务，因此更看重
DDD
的战术设计实

现。殊不知
DDD
是⼀种从领域建模到微服务落地的全⽅位的解决⽅案。

战略设计时构建的领域模型，是微服务设计和开发的输⼊，它确定了微服务的边界、聚合、代码对象

以及服务等关键领域对象。领域模型边界划分得清不清晰，领域对象定义得明不明确，会