1.1 聚合根概念：领域模型的“守护者”
在领域驱动设计（DDD）中，聚合根（Aggregate Root）是聚合（Aggregate）的入口点和唯一外部引用点。它负责维护聚合内部所有实体和值对象的不变性，确保业务规则在每次操作后都得到满足。可以把聚合根想象成一个“根实体”，它拥有全局标识，并控制着聚合内部所有对象的生命周期。
核心定义：聚合根是一个具有全局唯一标识的实体，它是聚合的“门面”。外部对象只能通过聚合根来访问或修改聚合内的任何元素，不能直接持有对聚合内部非根实体的引用。
1.1.1 聚合根在 DDD 中的角色
聚合根在领域模型中扮演着多重关键角色，这些角色共同保证了领域逻辑的完整性和一致性：
- 一致性边界（Consistency Boundary）：聚合根定义了事务的边界。在一个聚合内部，所有状态变更必须在单个事务中完成，确保数据始终处于一致状态。聚合根是这一边界的管理者。
- 业务不变量的守护者（Invariant Guardian）：聚合根负责执行和验证聚合内所有业务规则。例如，一个订单聚合根必须确保订单总金额等于所有订单项金额之和，且订单状态转换符合业务流程。
- 持久化单元（Persistence Unit）：在数据存储层面，聚合通常作为一个整体被加载、修改和持久化。聚合根是这一操作的入口，存储库（Repository）只对聚合根进行操作。
- 全局标识的持有者（Global Identity Holder）：聚合根拥有一个在整个系统中唯一的标识符（如 UUID）。聚合内的其他实体（如订单项）只拥有本地标识（在聚合内唯一），外部系统通过聚合根 ID 来引用整个聚合。
实践提示：在微服务架构中，聚合根也是服务间通信的“原子单元”。一个服务通常不会直接操作另一个服务的聚合内部对象，而是通过聚合根 ID 发起命令或查询。
1.1.2 聚合根 vs 实体 vs 值对象
理解这三者的区别是掌握 DDD 建模的基础。下表从多个维度进行了对比：
| 维度 | 聚合根（Aggregate Root） | 实体（Entity） | 值对象（Value Object） |
|---|---|---|---|
| 全局标识 | 有，全局唯一 | 有，但在聚合内唯一 | 无，由属性值定义 |
| 可变性 | 可变 | 可变 | 不可变（Immutable） |
| 生命周期 | 管理整个聚合的生命周期 | 由聚合根管理 | 无独立生命周期，随实体创建/销毁 |
| 相等性判断 | 通过全局 ID 判断 | 通过本地 ID 判断 | 通过所有属性值判断 |
| 外部引用 | 允许被外部直接引用 | 禁止被外部直接引用 | 允许被共享和引用 |
| 业务角色 | 一致性边界、不变量的守护者 | 具有业务行为的个体 | 描述性、度量性概念 |
为了更直观地理解三者在聚合中的关系，请看下面的结构图：
1.1.3 聚合根的设计原则
在设计聚合根时，需要遵循一些关键原则，以避免常见的建模陷阱：
- 保持聚合小巧（Small Aggregates）：聚合不应该包含过多的实体。过大的聚合会导致性能问题和并发冲突。通常，一个聚合包含一个聚合根和少数几个紧密相关的实体/值对象。
- 通过 ID 引用外部聚合（Reference by ID）：聚合根不应直接持有对其他聚合根的引用（对象引用），而应持有其 ID。这有助于保持聚合边界的清晰，并支持微服务间的松耦合。
- 在边界内保证一致性（Consistency Within Boundary）：聚合根只负责保证其内部的一致性。跨聚合的一致性通常通过领域事件（Domain Events）和最终一致性（Eventual Consistency）来实现。
- 避免过度设计（Avoid Over-Engineering）：并非每个实体都需要成为聚合根。如果一个实体没有子实体，且不承担一致性边界职责，它可能只是一个普通实体或值对象。
常见误区：将数据库表的一对多关系直接映射为聚合关系。例如，认为“用户”和“订单”是“一对多”关系，就将“用户”设计为包含“订单”的聚合根。这通常是不合理的，因为“用户”和“订单”各自有独立的生命周期和一致性边界，它们应该是两个独立的聚合。
1.1.4 支付订单聚合中的聚合根示例
在支付订单领域，一个典型的聚合设计如下。我们以“支付订单”作为聚合根，它包含以下元素：
- 聚合根：支付订单（PaymentOrder） — 全局唯一 ID，如
pay_123456。 - 实体：支付流水（PaymentTransaction） — 本地 ID，记录每次支付尝试（如首次支付失败后的重试）。
- 值对象：金额（Money） — 包含币种和数值，不可变。
- 值对象：支付方式（PaymentMethod） — 描述支付渠道（如支付、信用卡）和相关信息。
下面的 SVG 图展示了支付订单聚合的内部结构：
在这个设计中，外部系统（如订单服务）只能通过 PaymentOrder 聚合根来发起支付、查询状态或取消支付。所有对 PaymentTransaction 和 Money 的操作都必须经过聚合根，从而保证了支付金额计算、状态流转等业务规则的一致性。