1. 课程导论：支付订单在电商系统中的核心地位，为什么需要聚合建模与幂等设计
1.1 支付订单：电商交易闭环的“最后一公里”
在电商系统中，支付订单并非简单的“订单+支付”拼接，而是承载了资金流、状态机、外部渠道交互与业务一致性的核心聚合。一次支付操作可能涉及以下关键环节：
- 订单状态变更：待支付 → 支付中 → 支付成功/失败 → 退款中/已退款。
- 资金账户操作：用户余额扣减、平台账户入账、优惠券核销。
- 外部渠道对接：支付、支付宝、银联等网关的异步回调处理。
- 幂等保障：防止重复扣款、重复退款、重复通知。
核心观点： 支付订单是电商系统中状态最复杂、一致性要求最高、外部依赖最多的领域对象。任何状态错乱或重复操作都直接导致资损。
1.2 为什么需要聚合建模？—— 从“数据表”到“领域边界”
传统开发常将支付订单拆散为多张表（订单主表、支付流水表、退款表、回调日志表），通过外键或服务层协调。这种方式的痛点：
| 问题 | 传统表设计表现 | 聚合建模解决方式 |
|---|---|---|
| 数据一致性 | 多表更新需分布式事务，易出现中间状态 | 聚合内强一致性，一次事务提交所有变更 |
| 业务规则分散 | 支付金额校验、渠道重试逻辑散落在多个服务 | 聚合根统一封装业务不变量 |
| 并发冲突 | 多线程同时操作同一订单的不同流水 | 聚合根作为唯一入口，版本号/乐观锁控制 |
| 可测试性 | 依赖数据库和外部服务，单元测试困难 | 聚合纯内存操作，领域事件驱动 |
通过聚合建模，我们将支付订单聚合定义为：以支付订单为聚合根，内部包含支付流水、退款记录、回调记录等实体与值对象，所有外部操作必须通过聚合根方法执行，确保边界内的数据一致性与业务规则。
DDD 实践要点： 支付订单聚合的边界应覆盖“一次支付行为”的全生命周期，包括发起、渠道选择、回调处理、退款、关闭。超出此边界的操作（如用户账户余额查询）应通过领域服务或应用服务协调。
1.3 为什么需要幂等设计？—— 重复请求的“隐形杀手”
支付场景中，重复请求的来源多种多样：
- 用户重复点击：支付按钮未及时置灰，用户多次提交。
- 网络超时重试：客户端或服务端因超时自动重试。
- 消息队列重复消费：支付回调消息被多次投递。
- 渠道重复通知：支付网关因未收到确认而重复发送回调。
如果没有幂等设计，一次支付可能产生：
- 用户被扣款两次，但订单只成功一次（资损）。
- 退款请求重复执行，导致平台多退一笔钱。
- 回调重复处理，订单状态被错误覆盖。
资损案例： 某电商平台因未对支付回调做幂等处理，导致同一笔订单被重复确认支付成功，用户账户余额被扣减两次，平台当日损失超 50 万元。事后排查发现，仅需一个幂等 key 即可避免。
1.4 支付订单聚合与幂等 key 的关系
幂等 key 是聚合建模中保障业务不变量的关键工具。在支付订单聚合中，幂等 key 通常作为聚合内值对象或实体标识，确保同一业务请求只被处理一次。典型场景：
| 场景 | 幂等 key 生成规则 | 聚合内作用 |
|---|---|---|
| 支付请求 | 订单号 + 支付渠道 + 时间戳 | 防止同一订单重复发起支付 |
| 退款请求 | 原支付流水号 + 退款批次号 | 防止同一退款单重复执行 |
| 渠道回调 | 渠道通知 ID + 支付流水号 | 防止重复处理回调消息 |
幂等 key 的生成规则必须满足：全局唯一、业务可追溯、不可篡改。在后续章节中，我们将深入讲解不同场景下的 key 生成策略与实现细节。
1.5 本章小结
支付订单是电商系统中资金安全与业务一致性的最后防线。通过聚合建模，我们为支付行为划定了清晰的领域边界，确保内部数据与规则的一致性；通过幂等设计，我们为重复请求提供了“免疫系统”，防止资损与状态错乱。本课程后续将深入讲解：
- 支付订单聚合的实体、值对象与领域服务设计。
- 不同支付场景下的幂等 key 生成规则与实现。
- 聚合持久化、事件驱动与分布式事务的平衡策略。
- 实际项目中的代码落地与测试方案。