1. 领域驱动设计基础：DDD 核心概念、实体与值对象、聚合与聚合根、领域事件
领域驱动设计（Domain-Driven Design，DDD）是构建复杂业务系统的核心方法论。在支付订单系统中，资金流向、状态流转、对账一致性等核心逻辑高度复杂，DDD 通过将业务概念显式建模为代码，确保软件实现与领域知识紧密对齐。本节将系统梳理 DDD 的四大核心概念，为后续的聚合建模与缓存架构选型奠定理论基础。
1.1 DDD 核心概念全景
DDD 提供了一套从业务到代码的完整建模语言。下表对比了四个核心概念在支付订单系统中的典型映射：
| 概念 | 定义 | 支付订单系统示例 | 生命周期 | 标识方式 |
|---|---|---|---|---|
| 实体（Entity） | 具有唯一标识、生命周期可追踪的对象 | 订单（Order）、支付单（Payment）、账户（Account） | 可变，状态持续变化 | 订单号、支付流水号、账户 ID |
| 值对象（Value Object） | 描述属性，无唯一标识，不可变 | 金额（Money）、地址（Address）、支付方式（PaymentMethod） | 不可变，可替换 | 无标识，通过属性值相等判断 |
| 聚合（Aggregate） | 实体与值对象的边界封装，保证内部一致性 | 订单聚合（Order + OrderItem + PaymentInfo） | 整体加载、整体持久化 | 聚合根标识 |
| 领域事件（Domain Event） | 领域中发生的、业务人员关心的有意义的事件 | 订单已支付、退款已发起、对账不平 | 瞬时，发布后可能被订阅 | 事件 ID + 时间戳 |
建模原则：优先使用值对象封装无标识的业务概念（如金额、费率），减少实体数量；聚合边界是事务一致性的最小单元，跨聚合修改必须通过领域事件异步协调。
1.2 实体与值对象
实体与值对象的区分是 DDD 建模的第一步，直接影响数据库表设计和缓存策略。
实体（Entity）
- 标识唯一性：每个实体拥有全局唯一的业务标识（如订单号），即使所有属性相同，标识不同则视为不同对象。
- 可变性：实体状态随时间变化，例如订单状态从“待支付”变为“已支付”。
- 持久化方式：通常映射为数据库主表，缓存时以实体 ID 作为 Key。
值对象（Value Object）
- 无标识：通过属性值相等来判定两个值对象是否相同。
- 不可变性：一旦创建，属性不可修改；需要变更时直接替换整个对象。
- 共享与复用：值对象可以在多个实体间共享，例如多个订单共享同一个“标准费率”值对象。
- 持久化方式：通常作为实体的一部分内联存储（如 JSON 字段），或映射为从表。
支付场景实战：金额（Money）是典型的值对象，包含币种和金额数值。两个订单的金额对象只要币种和数值相同，即视为相等。金额对象不可变，任何加减操作都返回新的金额实例，避免精度丢失和并发修改问题。
1.3 聚合与聚合根
聚合是 DDD 中最核心的建模单元，它定义了数据一致性的边界。聚合根是聚合中唯一允许外部访问的实体。
聚合设计三原则
- 边界一致性：聚合内部的所有修改必须通过聚合根，保证事务边界内的数据强一致。
- 引用外部：聚合根可以持有其他聚合根的 ID，但不应直接持有其他聚合的实体引用。
- 整体加载：加载聚合时，一次性加载聚合内的所有对象，避免延迟加载带来的不一致。
支付订单聚合示例
下图展示了一个典型的支付订单聚合结构，聚合根为 Order，内部包含多个值对象和实体：
常见误区：不要将数据库的外键关联直接映射为聚合间的对象引用。聚合之间应通过 ID 引用，而非对象引用，否则会导致聚合边界模糊，引发跨聚合的事务扩散和缓存一致性问题。
1.4 领域事件
领域事件是 DDD 中实现聚合间解耦和最终一致性的关键机制。当聚合内的状态发生业务人员关心的变化时，发布领域事件，由其他聚合或限界上下文异步处理。
领域事件三要素
- 事件名称：使用业务语言，如
OrderPaid、RefundInitiated。 - 事件数据：包含事件发生时的关键上下文，如订单 ID、支付金额、时间戳。
- 事件元数据：事件 ID、事件类型、版本号、发生时间。
支付订单典型领域事件
| 事件名称 | 触发时机 | 关键数据 | 典型订阅者 |
|---|---|---|---|
OrderCreated |
用户提交订单 | orderId, userId, totalAmount | 库存服务、风控服务 |
OrderPaid |
支付网关回调成功 | orderId, paymentId, paidAmount | 发货服务、积分服务 |
RefundRequested |
用户发起退款 | orderId, refundAmount, reason | 财务服务、对账服务 |
SettlementCompleted |
清算完成 | settlementId, merchantId, netAmount | 通知服务、报表服务 |
领域事件发布流程
下图展示了领域事件在聚合操作中的完整生命周期：
缓存视角：领域事件是缓存失效的最佳触发点。当
OrderPaid 事件发布时，缓存层可以立即失效该订单的缓存，或异步更新缓存中的订单状态，实现缓存与数据库的最终一致性。在后续章节中，我们将基于领域事件设计缓存更新策略。
1.5 核心概念关系总结
实体、值对象、聚合、领域事件四者共同构成了 DDD 的建模骨架。实体提供标识和生命周期，值对象封装不可变属性，聚合划定事务边界，领域事件实现跨边界通信。在支付订单系统中，正确识别这些概念是后续进行聚合拆分、缓存粒度设计和性能调优的前提。
实战提醒：不要为了 DDD 而 DDD。如果业务逻辑简单，过度设计聚合和领域事件反而增加复杂度。建议从核心支付链路开始，逐步将稳定的业务边界抽象为聚合，再引入领域事件解耦非核心流程。