DDD笔记

(1) DDD是什么

领域驱动设计(Domain-Driven Design,简称DDD)

(2) 为什么使用DDD

防腐层,该层负责与外部服务提供方打交道,还负责将外部概念翻译成自己的核心领域能够理解的概念。

(3) 怎么做

(3.1) DDD战略战术

DDD的战略设计主要包括领域/子域、通用语言、限界上下文和架构风格等概念。 

(3.1.1) 战略

DDD的战略设计主要包括领域/子域、通用语言、限界上下文和架构风格等概念。 

领域

在日常开发中,我们通常会将一个大型的软件系统拆分成若干个子系统。
在DDD中,我们对系统的划分是基于领域的,也即是基于业务的。 

统一语言

DDD引入了统一语言,把业务名词含义事先确定好,减少不必要的翻译过程,车同轨,书同文,行同伦

这也消除了业务与技术之间的重复,共同使用业务原语对话,代码就是文档,代码就是领域知识

userService.love(Jack, Rose) => Jack.love(Rose) 

界限上下文

引入限界上下文的目的,不在于如何划分边界,而在于如何控制边界
限界上下文是“分而治之”架构原则的体现,我们引入它的目的其实为了控制(应对)软件的复杂度
是对领域模型、团队合作以及技术风险的控制 

限界上下文和上下文映射图

限界上下文和领域具有一对一的关系。

当限界上下文作为领域模型的边界时,一方面它限制了跨限界上下文之间领域模型的关系,另一方面它作为知识语境,分离了同一个领域概念的不同视角。我将限界上下文称为战略设计的基本架构单元。

架构风格

DDD并不要求采用特定的架构风格,因为它是对架构中立的。
你可以采用传统的三层式架构,也可以采用REST架构和事件驱动架构等。
在《实现领域驱动设计》中,作者比较推崇事件驱动架构和六边形(Hexagonal)架构。

(3.1.2) 战术

战略设计为我们提供一种高层视野来审视我们的软件系统,而战术设计则将战略设计进行具体化和细节化,它主要关注的是技术层面的实施,也是对我们程序员来得最实在的地方。
对于开发人员而,战术是最实用的,比如聚合、实体、值对象、工厂、仓储、领域事件等等。

自上而下的结构化分解 + 自下而上的面向对象建模,过程化分析更好地清理了模型之间的关系,而对象模型提升代码复用性和业务语义表达能力。

行为饱满的领域对象

要创建行为饱满的领域对象并不难,我们需要转变一下思维,将领域对象当做是服务的提供方,而不是数据容器,多思考一个领域对象能够提供哪些行为,而不是数据。

实体vs值对象

实体表示那些具有生命周期并且会在其生命周期中发生改变的东西;
而值对象则表示起描述性作用的并且可以相互替换的概念。

聚合(Aggregate)

资源库(Repository)
资源库用于保存和获取聚合对象,在这一点上,资源库与DAO多少有些相似之处

DAO只是对数据库的一层很薄的封装,而资源库则更加具有领域特征。
所有的实体都可以有相应的DAO,但并不是所有的实体都有资源库,只有聚合才有相应的资源库。

参考

[1] DDD之战略战术设计
[2] DDD 领域驱动设计落地实践系列:战略设计和战术设计
[3] 领域驱动设计在马蜂窝优惠中心重构中的实践
[4] 如何分辨应用服务与领域服务
[5] 领域驱动建模与面向对象建模的差异
[6] 端口和适配器架构——DDD好帮手
[7] 有了MVC,为什么还要DDD?