DDD（三）领域模型关键词解释、领域模型分类、关系图

一、关键词解释

1. 领域

​ 领域 其实就是我们常说的范围，而范围实际上就是我们的边界，我们做什么，做到什么程度，最低多少，最高多少。

• 比如：“电商” 是一个领域，“金融” 是一个领域，“教育” 是一个领域，你要确定你做的软件产品，具体的领域边界，分析涉及到的数据、业务规则、流程，然后通过面向对象的方式建立一个模型，再选择合适的技术实现。

2. 子域

​ 领域太过于复杂，业务太过于分散，这个时候我们做一个拆分，把领域划分为 子域，比如电商系统很复杂，将他拆分成比如一个个的模块，订单、商品、库存，甚至我们的模块还能进行细分，比如库存，可以分为本地库、异地库、三方托管库。划分子域有两个好处：一是分治，二是可以对子域进行分析，重要的子域加资源。

3. 核心域（子域）

​ 核心域 是指业务核心，核心的竞争力，因为企业愿景不同，领域愿景也不同，核心域也不同，说白了，就是你们项目最初立项的目的是什么，目标是什么？为什么要做这个项目？核心域的范围并不一定是一次就能确认的，可能需要迭代很多次，每一次都有可能扩大或缩小。

4. 通用域（子域）

​ 整个领域都能够用到的子域，比如：我们的认证，权限等相关的模式，这就是我们的 通用域。

5. 支撑域（子域）

​ 支撑域 实际上就是不包括核心竞争力的功能，也不包含通用的功能，但是又是必须的支撑。

6. 通用语言

​ 必须要有一个东西能够让我们的团队人员交流起来有一个标准。并且他还需要能够正确的、简单的、清晰的表达业务。让我们的技术专家、业务人员、产品、测试、架构都能够达到共识，并且协同合作。这个叫做 通用语言，类似需求文档里的词语解释，就是让大家能在同一纬度进行高效的交流沟通。

7. 限界上下文

​ 限界上下文 可以分为限界和上下文。限界就是领域的边界，也就是范围，而上下文则是语义环境。通过领域的限界上下文，我们就可以在同一的领域边界内用统一的语言进行交流。

8. 领域模型

​ 领域模型 是对领域内的概念类或现实世界中对象的可视化表示，领域模型是用来描述业务对象之间的应用关系。

• 业务角色方面，领域模型表达的是一个角色承担的一系列责任。比如收银员，他的责任是计算商品价格、收银、找零，甚至退换货。
• 业务实体方面，领域模型表达的是你使用或者可交付的工作、资源、事件。比如电商项目中的商品、你需要给买家打印的发票等。
• 业务用例方面，实际上领域模型表达的是协作角色与业务实体之间如何执行工作流程，也就是我们的业务链路。
• 实体（Entity）方面：领域模型是正常的实体对象，有唯一键标识，就算所有字段内容一样也不是一个，例如有学生实体，实体中有 id、姓名、年龄三个字段，就算姓名年龄一样，也不是一个。

9. 值对象（Value Object）

​ 没有唯一性标识，例如：学生实体上有一个地址，这个地址是一个对象，里面字段为：省，市，接到，详细地址，这个地址信息对象就是值对象。通过对象属性来识别的对象，它将多个属性组合为一个概念整体；

• 业务形态方面，值对象只是若干个属性的集合，只有数据初始化操作和有限的不设计修改数据的行为，基本不包含业务逻辑。
• 代码形态方面，值对象在代码中有这样两种形态。如果值对象是单一属性，则直接定义为实体类的属性；如果值对象是属性集合，则把它设计为 Class 类，Class 将具有整体概念的多个属性归集到属性集合，这样的值对象没有 ID，会被实体整体引用。
• 运行形态方面，引用单一属性的值对象或只有一条记录的多属性值对象的实体数据库形态。

10. 聚合根

​ 聚合根 是聚合的管理者，在聚合内部负责协调实体和值对象按照固定的业务规则协同完成共同的业务逻辑。聚合根是实体，有实体的特点，具有全局唯一标识，有独立的生命周期。一个聚合只有一个聚合根，聚合根在聚合内对实体和值对象采用直接对象引用的方式进行组织和协调，聚合根与聚合根之间通过 ID 关联的方式实现聚合之间的协同。

平常我们有的实体比较负责，为了满足业务，有可能会弄出一个非常复杂的实体，里面包含很多实体，跟这个类似，这里的聚合是指同一生命周期，同一业务域的实体聚合成一个聚合根，也就是最外面的实体，并且这个实体管理者里面的所有实体，外面只能通过聚合根进行任何请求，聚合根再对里面进行操作，这里我感觉就是高内聚，聚合根不宜过大。

11. 领域服务

​ 如果业务逻辑写在哪个实体中都不合适就可以写到 领域服务 中。

注意：

• 不能再领域服务里面写太多的业务逻辑；
• 不能再领域服务里调用 dao 和仓储；
• 领域服务视为实体的一种补充，里面的属性和逻辑也和实体一样，不能是基础类型，得是含有业务含义的值对象；
• 领域服务之间可以进行调用，最好是保持父域的领域服务调用子域的的领域服务，不允许跨越上下文进行调用；
• 和实体一样，如果有不相关的领域服务的调用，或者有跨上下文的情况，使用领域事件进行解耦。

12. 领域事件

​ 领域事件 是领域模型中非常重要的一部分，用来表示领域中发生的事件。一个领域事件将导致进一步的业务操作，在实现业务解耦的同时，还有助于形成完整的业务闭环，在做用户场景分析时，我们要捕捉业务、需求人员或领域专家口中的关键词：“如果发生…，则…” “当做完…的时候，请通知…” “发生…时，则…”等。在这些场景中，如果发生某种事件后，会触发进一步的操作，那么这个事件很可能就是领域事件。事件驱动，有一些代码逻辑，例如下单，后面后很多操作，一般我们一个下单方法里面会包含好几个字方法，并且带有 if，时间长了会非常冗余，并且方法越来越大，事件驱动就是，当下单之后发一个事件（mq），如果需要做一些操作，多个端接收这个消息事件，然后做自己的操作就行，扩展的话就多一个接收方，对之前代码物侵入修改。

领域专家所关心的发生在领域中的一些事件。

将领域中所发生的活动建模成一系列的离散事件。每个事件都用领域对象来表示…领域事件时领域模型的组成部分，表示领域中所发生的事情。

13. 数据持久化对象（Persistent Object，PO）

​ 与数据库结构一一映射，它是数据持久化过程中的数据载体。

14. 领域对象（Domain Object，DO）

​ 微服务运行时核心业务对象的载体，DO 一般包括实体或值对象。

15. 数据传输对象（Data Transfer Object，DTO）

​ 用于前端应用于微服务应用层或者微服务之间的数据组装和传输，是应用之间数据传输的载体。

16. 视图对象（View Object，VO）

​ 用于封装展示层至顶页面或组件的数据。

17. 工厂（Factories）

    创建复杂对象，隐藏创建细节。

18. 仓储（Repository）

    提供查找和持久化对象的方法。

---

二、领域模型分类

2.1 失血模型

失血模型 实际上就是我们的对象模型中只包含我们的 get、set 方法，像我们的排序、分页等等任何的通用性操作都不会包含在我们的对象中。

优点：

• 领域对象结构简单。

缺点：

• 肿胀的业务服务代码逻辑，难于理解和维护；
• 无法良好的应对复杂业务逻辑和场景。

2.2 贫血模型

贫血模型 实际上就是在失血模型的基础上增加了不依赖于持久化的院子领域逻辑。比如我们经常会使用到的排序、分页等等操作。

优点：

• 层次结构清楚，各层之间单向依赖；
• 对于只有少量业务逻辑的应用来说，使用起来非常自然；
• 开发迅速，易于理解。

缺点：

• 无法良好的应对非常复杂逻辑和场景。

2.3 充血模型

充血模型 中实际上我们的领域对象不仅仅包含了我们的非持久化逻辑，甚至还包含了我们的持久化逻辑，那么我们的业务逻辑层在充血模型里还需不需要呢？依然是需要的，但是我们的充血模型的业务层实际上只会做一些整合的操作以及封装事务，其他的操作都会在我们的领域对象中完成。

优点：

• 更加符合 OO 的原则；
• Business Logic 层很薄，符合单一职责，不像在贫血模型里面那样包含所有的业务逻辑太过沉重，只充当事务管理以及整合的角色，不和 DAO 打交道。

缺点：

• 职责不好进行划分，我们的业务逻辑到底是划分到我们哪一个层呢？是领域对象还是业务属性呢？哪些划分到领域对象呢？而且持久化的内容都放在我们的领域对象里，所以我们在写业务的时候会渗入到领域对象去，这对于开发者的水平要求很高，变相的增加了企业的成本。
• 其次，由于充血模型包含了太多的操作，你是李华的时候也会有很大的麻烦，拿到了很多你不需要的关联模型。

2.4 胀血模型

胀血模型 取消掉了 service 层，所有业务逻辑的整合都放在了领域模型中，简化了分层架构，也算是符合面向对象设计原则，取消了业务逻辑层，直接在 domain object 封装事务和授权，可能会授权很多原本不属于这个领域对象的逻辑，从而影响模型不稳定。代码的稳定性和维护的稳定性。

---

三、关系图

3.1 DDD 架构图

3.2 各层的概念以及关系

3.3 DDD 和 中台 的关系

3.4 三层架构 VS. DDD

3.5 领域事件

3.6 领域驱动设计的核心原则

整理完毕，完结撒花～🌻

参考地址：

1.DDD领域驱动模型设计，https://blog.csdn.net/weixin_45207323/article/details/136217303