📚 课程目录第3章聚合的定义

3. 聚合的定义：聚合、聚合根、边界的概念，以及聚合在领域模型中的角色

在领域驱动设计中，聚合（Aggregate）是用于维护领域模型一致性边界的核心模式。它并非简单的对象集合，而是一组具有紧密业务关联、必须保持数据一致性的领域对象的事务性集群。理解聚合、聚合根与边界，是构建高内聚、低耦合领域模型的前提。

下表从定义、职责与关键特征三个维度，对聚合、聚合根与边界进行对比：

概念	定义	核心职责	关键特征
聚合	一组相关领域对象的集合，作为一个数据修改的原子单元。	封装内部对象之间的业务规则，确保跨对象的状态变更满足业务约束。	内部对象之间通过引用关联，对外仅暴露聚合根。
聚合根	聚合中唯一的入口对象，也是外部访问聚合内部对象的唯一通道。	维护聚合的全局一致性，控制所有对内部对象的修改操作。	拥有全局唯一标识（ID）；内部对象仅具有本地标识。
边界	聚合内部与外部世界的事务隔离线。	定义哪些对象属于同一个事务范围，哪些对象必须通过聚合根间接访问。	边界内所有变更在单个事务中完成；边界外对象只能引用聚合根的ID。

实践要点：聚合边界是领域模型中最昂贵的设计决策。边界过大导致事务范围膨胀、并发冲突加剧；边界过小则破坏业务一致性，需要引入最终一致性补偿机制。

聚合在领域模型中扮演三个关键角色，这些角色直接决定了微服务架构中服务边界的划分方式：

一致性守卫者：聚合确保其内部的所有实体和值对象在任何业务操作完成后，都满足预定义的不变条件（Invariants）。例如，订单聚合必须保证“订单总金额 = 所有订单项金额之和 + 运费 - 折扣”。
事务边界定义者：聚合是领域模型中最小的事务范围。一个事务只能修改一个聚合实例，不能跨聚合提交事务。这直接映射到微服务架构中“一个服务实例管理一个聚合类型”的原则。
业务能力封装者：聚合将一组相关的业务逻辑（方法）与数据（状态）封装在一起，对外提供高层次的业务接口，隐藏内部实现细节。这降低了服务之间的耦合度。

下面的SVG图展示了一个典型的订单聚合结构，清晰呈现了聚合根、内部实体、值对象以及外部引用的关系：

在识别和设计聚合时，应遵循以下三条经过大量项目验证的法则：

法则一：在边界内保证一致性——聚合内部的所有对象必须在同一个事务中完成状态变更。如果业务操作需要修改多个聚合，则必须采用最终一致性（事件驱动）而非分布式事务。
法则二：通过聚合根访问内部对象——外部对象不能直接持有聚合内部实体或值对象的引用。所有修改请求必须通过聚合根的方法接口发起，由聚合根校验业务规则后委派给内部对象。
法则三：聚合之间通过ID引用——一个聚合引用另一个聚合时，只存储对方的全局标识（ID），而不是直接持有对象引用。这避免了跨聚合的级联遍历，也使得聚合可以独立部署为微服务。

  设计陷阱警示：初学者常犯的错误是将数据库的外键关系直接映射为聚合之间的对象引用。例如，在订单对象中直接包含“客户对象”的引用。这破坏了聚合边界，导致一个事务可能无意中修改了客户聚合的状态，引发数据不一致。

聚合在领域模型中的边界，直接决定了微服务架构中的服务拆分粒度。下图展示了这种映射关系：

关键原则：一个微服务通常管理一个聚合类型（或一组高度相关的聚合）。如果将一个聚合拆到多个微服务中，会导致跨服务事务，破坏聚合的一致性边界。反之，如果将多个不相关的聚合合并到一个微服务中，则会导致服务内聚性下降，失去微服务独立演进的收益。

在实际建模过程中，可以使用以下清单来评估聚合设计的合理性：