2. 领域驱动设计基础：实体、值对象、聚合、聚合根、领域事件、限界上下文的概念与关系
领域驱动设计（DDD）提供了一套用于构建复杂业务系统的战术建模工具。在支付订单系统中，正确理解并运用这些核心概念，是确保模型准确、代码健壮的关键。本章将逐一解析这些基础元素及其相互关系。
2.1 核心概念定义
DDD 的战术模式围绕业务概念展开，每个模式都有其明确的职责和约束。下表总结了六个核心概念的定义与关键特征：
| 概念 | 定义 | 关键特征 | 支付订单系统示例 |
|---|---|---|---|
| 实体 (Entity) | 具有唯一标识符，且其属性会随时间变化的对象。实体的身份由其 ID 而非属性值决定。 | 有 ID、可变、需跟踪生命周期 | 订单 (Order)、用户 (User)、支付单 (Payment) |
| 值对象 (Value Object) | 描述某种状态或属性，没有唯一标识符，由属性值本身决定其相等性。通常不可变。 | 无 ID、不可变、可共享、自包含 | 金额 (Money)、地址 (Address)、货币 (Currency) |
| 聚合 (Aggregate) | 一组相关对象的集合，作为一个整体进行数据变更的一致性边界。 | 一致性边界、内部强一致、外部弱一致 | 订单聚合（包含订单实体、订单项实体、金额值对象） |
| 聚合根 (Aggregate Root) | 聚合中唯一的顶级实体，外部对象只能通过聚合根来访问聚合内的其他对象。 | 唯一入口、负责全局一致性、全局唯一标识 | 订单实体 (Order) 作为订单聚合的根 |
| 领域事件 (Domain Event) | 领域专家关心的、发生在过去的事件。用于解耦聚合之间的通信，记录业务变更。 | 过去时、不可变、携带上下文数据 | 订单已支付 (OrderPaid)、订单已取消 (OrderCancelled) |
| 限界上下文 (Bounded Context) | 一个显式的边界，定义了模型应用的上下文。每个上下文内部有统一的语言和模型。 | 边界清晰、独立演化、团队对齐 | 订单上下文、支付上下文、库存上下文 |
建模提示： 在支付订单系统中，金额 (Money) 是一个典型的值对象。它由
amount 和 currency 两个属性组成，两个金额对象只要这两个属性值相同，就被视为同一个对象。它没有 ID，且通常被设计为不可变，以避免因引用共享导致的意外修改。
2.2 概念关系与协作
这些概念并非孤立存在，它们通过特定的关系共同构成领域模型。下图展示了它们之间的核心协作关系：
关系要点：
- 聚合根是聚合的唯一入口：外部对象（如应用服务）只能通过
Order聚合根来操作OrderItem实体或Money值对象，不能直接修改它们。 - 领域事件用于跨聚合通信：订单聚合在支付成功后发布
OrderPaid事件，支付上下文订阅该事件后创建Payment聚合。这实现了两个聚合之间的最终一致性。 - 限界上下文是模型的边界：订单上下文和支付上下文各自拥有独立的模型、语言和数据库。它们通过领域事件或 API 进行集成，避免了模型之间的耦合。
2.3 聚合设计原则与案例
聚合是 DDD 战术建模的核心，其设计质量直接影响系统的复杂度和性能。以下是聚合设计的关键原则：
- 一致性边界：聚合内部的所有对象必须保持强一致性。一个事务只能修改一个聚合实例。
- 小聚合原则：聚合应尽可能小，只包含必须保持强一致性的对象。过大的聚合会导致性能瓶颈和并发冲突。
- 通过 ID 引用外部聚合：聚合内部不应持有其他聚合的实体对象引用，而应持有其 ID。这有助于保持聚合边界的清晰。
- 最终一致性：跨聚合的更新应通过领域事件实现最终一致性，而非使用分布式事务。
常见设计错误： 在支付订单系统中，一个常见的错误是将
Order 和 Payment 放在同一个聚合内。虽然它们业务上紧密相关，但支付流程通常涉及外部网关，状态变化频繁。如果放在一个聚合内，每次支付状态变更都需要锁定整个订单聚合，会导致严重的并发问题。正确的做法是将它们分为两个独立的聚合，通过领域事件进行协调。
2.4 限界上下文与上下文映射
限界上下文是 DDD 战略设计的核心。它定义了模型的适用范围，并强制团队使用统一的语言（Ubiquitous Language）。在支付订单系统中，常见的限界上下文包括：
- 订单上下文：负责订单的创建、修改、查询和生命周期管理。核心实体是
Order。 - 支付上下文：负责支付请求的发起、处理、回调和对账。核心实体是
Payment。 - 库存上下文：负责商品库存的扣减和释放。核心实体是
Inventory。 - 用户上下文：负责用户身份、账户余额和信用额度。核心实体是
User。
上下文之间的关系通过上下文映射 (Context Map) 来描述。下图展示了支付订单系统中几个关键限界上下文之间的典型关系：
上下文映射模式： 上图中，订单上下文与支付上下文之间使用了事件驱动模式，实现了松耦合。订单上下文与库存上下文之间使用了RPC/消息模式，用于同步扣减库存。选择哪种模式取决于业务对一致性和响应时间的要求。
2.5 总结：从概念到模型
理解实体、值对象、聚合、聚合根、领域事件和限界上下文，是掌握 DDD 建模的基础。在支付订单系统中，这些概念共同构建了一个清晰、可维护的领域模型：
- 实体 定义了业务对象的身份和生命周期。
- 值对象 封装了不可变的业务属性。
- 聚合 和 聚合根 保证了数据变更的一致性边界。
- 领域事件 实现了聚合之间的松耦合通信。
- 限界上下文 划定了模型的独立演化范围。