2、支付订单领域模型分析
支付订单是支付系统的核心聚合根，承载着交易资金流转的完整生命周期。本章从领域驱动设计（DDD）视角，深入分析支付订单的核心业务流程、状态机设计以及上下文边界划分，为后续的缓存架构选型与性能调优奠定领域模型基础。
2.1 支付订单核心业务流程
支付订单的生命周期覆盖从用户发起支付到资金清算完成的完整链路。以下为典型的核心业务流程步骤：
- 订单创建：用户在前端确认支付后，业务系统生成支付订单，记录订单号、金额、商户信息、支付方式等核心字段。
- 支付请求：支付系统向渠道网关（如、支付宝、银联）发起支付请求，获取支付凭证或跳转链接。
- 用户支付：用户在渠道侧完成密码验证、指纹或扫码支付操作。
- 异步通知：渠道网关通过回调接口通知支付结果（成功/失败/处理中）。
- 订单处理：支付系统校验通知签名与金额，更新订单状态，触发后续业务（如发货、积分赠送）。
- 对账清算：T+1 日与渠道进行资金对账，处理长款、短款及差错账。
关键设计要点： 异步通知环节必须实现幂等处理，防止重复回调导致订单状态错乱；同时需设计超时关闭机制，处理用户中途放弃支付的场景。
2.2 支付订单状态机设计
状态机是支付订单领域模型的核心行为约束。以下为支付订单的标准状态定义与合法流转路径：
| 状态编码 | 状态名称 | 状态说明 |
|---|---|---|
| INIT | 待支付 | 订单已创建，等待用户支付 |
| PROCESSING | 支付处理中 | 已向渠道发起请求，等待异步结果 |
| SUCCESS | 支付成功 | 渠道确认资金已扣款成功 |
| FAILED | 支付失败 | 渠道返回明确失败原因（余额不足、风控拦截等） |
| CLOSED | 已关闭 | 超时未支付或用户主动取消 |
| REFUNDING | 退款中 | 发起退款申请，等待渠道处理 |
| REFUNDED | 已退款 | 退款完成，资金已退回用户账户 |
状态机合法流转路径如下：
- 正向路径：INIT → PROCESSING → SUCCESS
- 失败路径：INIT → PROCESSING → FAILED（可重试回到 INIT）
- 关闭路径：INIT → CLOSED（超时或取消）
- 退款路径：SUCCESS → REFUNDING → REFUNDED
实践建议： 状态变更必须通过领域事件驱动，禁止直接修改数据库状态字段。建议使用状态模式（State Pattern）封装每个状态下的行为逻辑，避免 if-else 泛滥。
2.3 支付上下文边界
在 DDD 战略设计中，支付订单作为核心域，需要明确其与周边限界上下文的交互边界。以下为支付上下文的主要划分：
| 限界上下文 | 职责范围 | 与支付订单的交互方式 |
|---|---|---|
| 订单上下文 | 管理业务订单（商品、金额、用户） | 通过领域事件触发支付订单创建 |
| 支付上下文 | 支付订单生命周期管理、渠道对接 | 核心域，独立数据库与缓存 |
| 渠道网关上下文 | 封装、支付宝等外部渠道协议 | 防腐层（ACL）隔离渠道差异 |
| 对账上下文 | 资金对账、差错处理 | 读取支付订单完成状态进行比对 |
| 通知上下文 | 向业务系统推送支付结果 | 通过消息队列异步通知 |
边界划分陷阱： 支付订单不应直接依赖业务订单的数据库表，必须通过聚合根 ID 或领域事件进行解耦。渠道网关的协议差异必须在防腐层内部消化，避免污染支付核心模型。
2.4 领域模型核心要素总结
支付订单领域模型的设计直接决定了后续缓存策略与性能优化的上限。以下为关键设计原则：
- 聚合根设计：支付订单作为唯一聚合根，所有状态变更必须通过聚合根方法执行，确保数据一致性。
- 事件驱动：状态变更后发布领域事件，由事件处理器驱动下游上下文（如通知、对账）。
- 防腐层隔离：渠道网关差异在 ACL 内部转换，支付核心模型只依赖统一的支付请求/响应对象。
- 缓存友好：支付订单的查询频率远高于写入，状态机设计应支持缓存键的合理划分（如按订单号、按用户 ID）。