3. 支付订单的领域分析：识别支付订单上下文中的核心实体
在支付订单的领域模型中，核心实体是承载业务状态与行为的基本单元。通过领域分析，我们识别出三个关键实体：订单（Order）、支付单（Payment） 和 交易流水（Transaction）。它们各自承担不同的职责，并通过明确的关联关系构成完整的支付领域模型。
3.1 核心实体职责与属性
下表对比了三个核心实体的关键属性与职责边界：
| 实体 | 职责 | 关键属性 | 生命周期 |
|---|---|---|---|
| 订单（Order） | 记录用户购买意图，包含商品明细、金额、收货信息等业务数据 | orderId, userId, totalAmount, status, items, createTime | 从创建到完成/取消，状态机驱动 |
| 支付单（Payment） | 管理一次支付请求的全过程，包含支付方式、渠道、金额等支付数据 | paymentId, orderId, payAmount, channel, status, expireTime | 从发起支付到支付成功/失败/关闭 |
| 交易流水（Transaction） | 记录与外部支付渠道的每一次交互结果，用于对账与审计 | txId, paymentId, channelTxId, request, response, status, time | 单次请求-响应，不可变记录 |
领域提示： 订单与支付单是 一对多 关系（一个订单可多次支付尝试），支付单与交易流水是 一对多 关系（一次支付可能产生多次渠道交互）。这种分层设计保证了业务与支付逻辑的解耦。
3.2 实体关系与领域边界
下图展示了三个核心实体在支付上下文中的关系与边界：
3.3 实体状态机与关键流程
每个核心实体都有明确的状态转换规则，这是领域建模的核心。以下是各实体的状态机描述：
3.3.1 订单状态机
- 待支付 → 已支付 → 已发货 → 已完成（正向流程）
- 待支付 → 已取消（用户主动取消）
- 已支付 → 退款中 → 已退款（逆向流程）
3.3.2 支付单状态机
- 待支付 → 支付中 → 支付成功 / 支付失败
- 支付中 → 支付超时 → 已关闭
- 支付成功 → 退款中 → 已退款
3.3.3 交易流水状态
- 已发送 → 已接收 → 处理成功 / 处理失败
- 交易流水一旦写入，不可修改，仅支持追加新记录
建模陷阱： 不要将交易流水与支付单合并为一个实体。交易流水是 不可变事件记录，而支付单是 可变状态聚合。合并会导致状态管理混乱，且无法满足对账审计的不可变性要求。
3.4 实体间的数据流与依赖关系
下图展示了支付请求发起后，三个实体之间的数据流转与依赖关系：
3.5 实体识别总结
通过领域分析，我们明确了三个核心实体的职责边界与协作关系：
- 订单（Order）：业务聚合根，管理商品购买全生命周期，不直接处理支付逻辑。
- 支付单（Payment）：支付聚合根，管理支付请求的发起、重试、超时与结果处理，是幂等控制的核心载体。
- 交易流水（Transaction）：不可变事件记录，保存与外部渠道的每一次交互细节，用于对账、审计与问题排查。