学习笔记之DDD

参考：https://www.jdon.com/jdonframework/manual.htm

 

领域驱动设计（Domain-driven Design）

Domain：一个领域本质上可以理解为就是一个问题域，只要是同一个领域，那问题域就相同。所以，只要我们确定了系统所属的领域，那这个系统的核心业务，即要解决的关键问题、问题的范围边界就基本确定了。

Design：设计主要指领域模型的设计

Driven：1）领域驱动领域模型设计；2）领域模型驱动代码实现。

 

• 领域就是问题域，有边界，领域中有很多问题；
• 任何一个系统要解决的那个大问题都对应一个领域；
• 通过建立领域模型来解决领域中的核心问题，模型驱动的思想；
• 领域建模的目标针对我们在领域中所关心的问题，即只针对核心关注点，而不是整个领域中的所有问题；
• 领域模型在设计时应考虑一定的抽象性、通用性，以及复用价值；
• 通过领域模型驱动代码的实现，确保代码让领域模型落地，代码最终能解决问题；
• 领域模型是系统的核心，是领域内的业务的直接沉淀，具有非常大的业务价值；
• 技术架构设计或数据存储等是在领域模型的外围，帮助领域模型进行落地。

拆分领域
将复杂领域进行拆分，本质上就是把大问题拆分为小问题，然后各个击破的思路。然后既然把一个大的领域划分为了多个小的领域（子域），那最关键的就是要理清每个子域的边界；然后要搞清楚哪些子域是核心子域，哪些是非核心子域，哪些是公共支撑子域；然后，还要思考子域之间的联系是什么。

细化子域
从领域概念、业务规则、交互场景、业务流程等维度梳理了我们到底要什么，整理了整个系统应该具备的功能。

建模工具：聚合、实体、值对象、工厂、仓储、领域服务、领域事件。

界限上下文：
在一个领域/子域中，我们会创建一个概念上的领域边界，在这个边界中，任何领域对象都只表示特定于该边界内部的确切含义。这样边界便称为限界上下文。限界上下文和领域具有一对一的关系。
将一个限界上下文中的所有概念，包括名词、动词和形容词全部集中在一起，我们便为该限界上下文创建了一套通用语言。通用语言是一个团队所有成员交流时所使用的语言，业务分析人员、编码人员和测试人员都应该直接通过通用语言进行交流。
限界上下文之间的集成关系也可以理解为是领域概念在不同上下文之间的映射关系，因此，限界上下文之间的集成也称为上下文映射图。

贫血领域对象（Anemic Domain Object）是指仅用作数据载体，而没有行为和动作的领域对象。

领域服务

资源库：用于保存和获取聚合对象。资源库分为两种，一种是基于集合的，一种是基于持久化的。

领域事件
DDD的一个重要原则便是一次事务只能更新一个聚合实例。
最终一致性取代了事务一致性，通过领域事件的方式达到各个组件之间的数据一致性。

四色原型

开发模式的转变：
1. 传统的分层模式Action/Service/DAO，很多关于OO理论的也毫无用武之地。
使用这种开发方式，对象只是数据的载体，没有行为。以数据为中心，以数据库ER设计作驱动。
分层架构在这种开发模式下，可以理解为是对数据移动、处理和实现的过程。

2. 采用领域模型的开发方式，将数据和行为封装在一起，并与现实世界中的业务对象相映射。
各类具备明确的职责划分，将领域逻辑分散到领域对象中。