DDD学习笔记 - 基础篇（Ⅱ）

╰+哭是因爲堅強的太久メ 2023-06-10 06:24 60阅读 0赞

# *04 | 实体和值对象：从领域模型的基础单元看系统设计* #

*课程链接：*[https://time.geekbang.org/column/article/152677][https_time.geekbang.org_column_article_152677]

实体和值对象，都是领域模型中的领域对象。

### 实体： ###

实体拥有唯一标识符，且标识符在历经各种状态变更后仍能保持一直。对于实体，重要的不是其属性，而是其延续性和标识，对象的延续性和标识会跨越甚至超出软件的生命周期。

**业务形态：**领域模型中的实体是多个属性、操作或行为的载体。**实体和值对象是组成领域模型的基础单元。**

**代码形态：**实体类，包含了实体的属性和方法。**DDD中实体类通常采用充血模型。**

**运行形态：**实体以DO（领域对象）的形式存在，每个实体都有唯一的ID。对实体进行多次修改，实体仍然有相同的ID，释然是同一个实体。

**数据库形态：**DDD先构建领域模型，根据场景构建实体和行为，再将实体映射到数据持久化对象。一个实体可能对应0、1或对各数据库持久化对象，大多数情况下是一对一。用户user与角色role两个持久化对象可生成权限实体，一个实体对应两个持久化对象，这是一对多的场景。

### 值对象： ###

**通过对象属性值来识别的对象，它将多个相关属性组合为一个概念整体。**在DDD中是一个没有标识符的对象。

可以将值对象理解为属性的集合。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h6Xzk0MDYxMQ_size_16_color_FFFFFF_t_70][]

人员实体原本包括：姓名、年龄、性别以及所在的省、市、县和街道等属性，但是这样显示地址相关的属性就很零碎了。现在可以将省、市、县和街道等属性拿出来构成一个“地址属性集合”，这个集合就是值对象。

**业务形态：**值对象和实体一起构成聚合。实体是看得到、摸得到实实在在的业务对象，具有业务属性、业务行为和业务逻辑。值对象只是若干个属性的集合，只有数据初始化操作和有限的不涉及修改数据的行为，基本不包含业务逻辑。值对象的属性集用于描述实体的特征。

**代码形态：**两种。如果值对象是单一属性，则直接定义为实体类的属性；如果值对象是属性集合，则设计为Class类，Class将具有整体概念的多个属性归集到属性集合，这样的值对象没有ID，会被实体整体引用。

看下代码，person实体有若干个单一属性的值对象，比如id、name等属性；同时也包含多个属性的值对象，如地址addrress：  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h6Xzk0MDYxMQ_size_16_color_FFFFFF_t_70 1][]

**运行形态：**实体实例化后的DO对象的业务属性和行为很丰富，但值对象除了数据初始化和整体替换意外，其他业务行为就很少了

值对象嵌入到实体，有两种方式。属性嵌入和序列化大对象。引用单一属性的值对象或只有一条记录的多属性值对象的实体，可以采用属性嵌入的方式。引用一条或多条记录的多属性值对象的实体，可以采用序列化大对象的方式。值对象创建后就不能修改了，只能用另一个值对象整体替换。

案例1：艺术性嵌入的方式形成的人员实体对象，地址值对象直接以属性值嵌入人员实体中。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h6Xzk0MDYxMQ_size_16_color_FFFFFF_t_70 2][]

案例2：一序列化大对象的方式形成的人员实体对象，地址值对象被序列化成大对象Json，嵌入人员实体中。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h6Xzk0MDYxMQ_size_16_color_FFFFFF_t_70 3][]

**数据库形态：**DDD引入值对象是希望实现从“数据建模为中心”向“领域建模为中心”转变，减少数据库表数量和复杂的依赖关系。传统的数据建模大多是根据数据库范式设计的，每一个数据库表对应一个实体，每一个实体的属性值用单独的一列来存储，一个实体主表会对应N个实体从表。而值对象在数据库持久化方面简化了设计，它的数据库设计大多采用非数据库范式，值对象的属性值和实体的属性值保存在同一个数据库实体表中。

例如上文的人员和地址的场景，实体和数据模型设计有两种方式：第一是把值对象的所有属性都放到人员实体表中，创建人员实体，创建人员表；第二是创建人员和地址两个实体，同时创建人员和地址两张表。第一个方案会破坏地址的业务含义和概念完整性，第二个方案增加了不必要的实体和表，需要处理多个表关系，增加了数据库复杂性。

所以要在这两者之间权衡。可以综合优势。

领域建模时，可以把地址作为值对象，人员作为实体，保留了业务含义和概念完整性。而在数据建模时，可以将地址的属性值嵌入到人员实体数据库表中，只创建人员数据库表。这样兼顾了业务含义，也不增加数据库复杂度。

值对象就是这样简化了数据库设计。**在领域建模时，可以将部分对象设计为值对象，保留对象的业务含义，同时减少了实体数量在数据建模时，可以将值对象嵌入实体，减少实体表的数量，简化数据库设计。**

也有DDD专家认为，需要有限领域建模，弱化数据库的作用，只作为一个保存数据的仓库即可。

**优势和劣势：**简化数据库设计，提升数据库性能。减少了实体表的数量，简单、清晰的表达业务概念。但却无法满足基于值对象的快速查询，导致搜索值对象书香之变得困难。如果实体引用的值对象过多，会导致实体堆积一堆缺乏概念完整性的属性，这样值对象就是去了业务含义，操作也不方便。

### 实体和值对象的关系： ###

实体和值对象时微服务底层最基础的对象。在某些场景下时可以互换的，值对象在某些场景下有很好的价值，但并不是所有场景都适合值对象。

DDD引入值对象还有一个重要的原因，就是到底领域建模优先还是数据建模优先？

DDD提倡从领域模型设计出发，而不是有限设计数据模型。值对象的诞生，在一定程度上和实体是互补的。

在某些场景中，地址会被某一实体引用，它只承担描述实体的作用，并且它的值只能被整体替换，这时候就可以将地址设计为值对象，比如收货地址。而在其他业务场景中，地址会被经常修改，是作为一个独立对象存在的，这时候应该将它设计为实体，比如行政区划中的之地信息维护。

实体着重唯一性和延续性，不在意属性的变化，属性全变了，它还是原来那个它；值对象着重描述性，对属性的变化很敏感，属性变了，它就不是那个它了。

实体和值对象都是领域模型的成员，实体是业务唯一性的载体，是个富对象，包含业务逻辑和唯一标识。值对象是属性的集合，没有唯一标识，只是数据的容器，没有业务逻辑。值对象是实体的一部分，为了简化设计，将部分相关属性抽离成值对象。如果值对象变动，原来的值对象可以直接丢弃。也可以理解为值对象是当时数据的快照，只是当时的状态。值对象过多会导致业务的缺失，影响查询性能。具体哪些属性可以作为值对象存在要具体问题具体分析。

\-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

# *05 | 聚合和聚合根：怎样设计聚合* #

*课程链接：*[https://time.geekbang.org/column/article/154547][https_time.geekbang.org_column_article_154547]

将业务关联紧密的实体和值对象进行组合，构成聚合，再根据业务语义将多个聚合划定到同一个限界上下文中，并在限界上下文内完成领域建模。

**聚合：**DDD中实体一般对应业务对象，具有业务属性和业务行为；而值对象主要是属性集合，对实体的状态和特征进行描述。但实体和值对象都是个体化的对象，他们的行为表现出来的是个体的能力。

**领域内的实体和值对象就好比个体，而能让实体和值对象协同工作的组织就是聚合，它用来确保这些领域对象在实现共同的业务逻辑时，能保证数据的一致性。**

就好像一个个人和社团、机构、部门等组织的关系。

聚合是由业务和逻辑紧密关联的实体和值对象组合而成的，是数据修改和持久化的基本单位，每一个聚合对应一个仓储，实现数据持久化。聚合有一个聚合根和上下文边界，这个边界根据业务单一职责和高内聚原则，定义了聚合内部应该包含哪些实体和值对象，聚合之前的边界是松耦合的。

聚合在DDD分层架构中属于领域层，内部实体以充血模型实现个体业务能力。跨多个实体的业务逻辑通过领域服务来实现，跨多个聚合的业务逻辑通过应用服务来实现。

**聚合根：**主要目的是为了避免由于复杂数据模型缺少统一的业务规则控制，而导致聚合、实体之间数据不一致性的问题。

**如果把聚合比作组织，那聚合根就是这个组织的负责人。聚合根也成为根实体，它不仅是实体，还是聚合的管理者。**作为实体，拥有实体的属性和业务行为，实现自身业务逻辑。作为聚合管理者，负责协调实体和值对象按照固定业务规则协同完成业务逻辑。在聚合之间，它还是聚合对外的接口人，以聚合根ID关联的方式接受外部任务的请求，在上下文内实现聚合之间的业务协同。即聚合之间通过聚合根ID关联引用。访问其他聚合的实体，需要先访问聚合根，再导航到聚合内部实体，外部对象不能直接访问聚合内的实体。

### 怎样设计聚合？ ###

DDD领域建模通常采用事件风暴，通常采用用例分析、场景分析、用户旅程分析等，通过头脑风暴列出所有可能的业务行为和事件，然后找出产生这些行为的领域对象，并梳理对象之间的关系，找出聚合根，找出与聚合根业务紧密关联的实体和值对象，再将聚合根、实体和值对象组合，构建聚合。

以保险的投保业务场景为例：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h6Xzk0MDYxMQ_size_16_color_FFFFFF_t_70 4][]

*  第1步：事件风暴，根据业务行为，梳理出在投保过程发生这些行为的所有的实体和值对象，比如投保单、标的、客户、被保人等；
 *  第2步：从众多实体中选出适合作为对象管理者的根实体，也就是聚合根。可以根据以下场景分析：是否有独立的生命周期？是否有全局唯一ID？是否可以创建或修改其他对象？是否有专门的模块来管这个实体。图中的聚合根分别是投保单和客户实体；
 *  第3步：根据业务单一职责和高内聚原则，找出与聚合根关联的所有紧密以来的实体和值对象。构建出1个包含聚合根（唯一）、多个实体和值对象的对象集合，这个集合就是聚合。图中构建了客户和投保这两个聚合；
 *  第4步：在聚合内根据聚合根、实体和值对象的依赖关系，画出对象的引用和依赖模型。上图中投保人和被保人是通过关联客户ID从客户聚合中获取的，在投保聚合中他们是投保单的值对象，是客户的冗余数据，即使未来客户聚合的数据发生了改变，也不影响投保单的值对象数据。可以看出实体之间的引用关系，比如在投保聚合里投保单集合跟引用了报价单实体，报价单实体则引用了报价规则子实体。
 *  多个聚合根据业务语义和上下文一起划分到同一个限界上下文中。

### 聚合的设计原则： ###

1.**在一致性边界内建模真正的不变条件。**聚合用来封装真正的不变性，而不是简单地将对象组合在一起。边界外的东西都与该聚合无关，这也是聚合能实现业务高内聚的原因。

**2.设计小聚合。**如果聚合过大，包含的实体过多，实体之间的管理就会很复杂，高频操作会出现并发冲突或数据库锁，导致可用性变差。

**3.通过唯一标识引用其他聚合。**聚合之间通过关联外部聚合根ID的方式引用，而不是直接对象引用。边界清晰，不会增加耦合度

**4.在边界之外使用最终一致性。**聚合内数据强一致性，聚合之间数据最终一致性。一次事务最多只能更改一个聚合的状态。若一次业务操作设计多个聚合状态的修改，应采用领域事件的方式异步修改相关的聚合，实现聚合之间解耦。

**5.通过应用分层实现跨聚合的服务调用。**应避免跨聚合的领域服务调用和跨聚合的数据库表关联。

**聚合的特点：**高内聚、低耦合。是领域模型中最底层的边界，可以作为拆分微服务的最小单位。一个微服务可以包含多个聚合，聚合之间的边界时微服务内天然的逻辑边界。

**聚合根的特点：**聚合根是实体，有实体的特点，具有全局唯一标识，有独立的生命周期。一个聚合内只有一个聚合根，聚合根在聚合内对实体和值对象采用直接引用的方式进行组织和协调，聚合与聚合根之间通过ID关联的方式实现聚合之间的协同。

**实体的特点：**有ID标识，通过ID判断相等性，ID在聚合内唯一即可。状态可变，依附于聚合根，生命周期由聚合根管理。实体一般会持久化，但与数据库持久化对象不一定是一对一的关系。实体可以引用聚合内的聚合根、实体和值对象。

**值对象的特点**：无ID，不可变，无生命周期，用完即扔。值对象之间通过属性值判断相等性。它的核心本质是值，是一组概念外争的属性组成的集合，用于描述实体的状态的特征。值对象尽量只引用值对象。

[https_time.geekbang.org_column_article_152677]: https://time.geekbang.org/column/article/152677
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h6Xzk0MDYxMQ_size_16_color_FFFFFF_t_70]: /images/20230531/2551ba6d59fe44ba87e3cc9c7e89383f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h6Xzk0MDYxMQ_size_16_color_FFFFFF_t_70 1]: /images/20230531/4c7ecc9ba4df44749020fd2111d94383.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h6Xzk0MDYxMQ_size_16_color_FFFFFF_t_70 2]: /images/20230531/17a8c5d6689f47deb05adab8f3f2651d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h6Xzk0MDYxMQ_size_16_color_FFFFFF_t_70 3]: /images/20230531/26948ee70bca4746ae016e69dffb6569.png
[https_time.geekbang.org_column_article_154547]: https://time.geekbang.org/column/article/154547
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h6Xzk0MDYxMQ_size_16_color_FFFFFF_t_70 4]: /images/20230531/3b0ef4bb7c6a4688aa9e1dc60e9b7be3.png