1. 课程导论与背景：支付系统面临的挑战与领域聚合建模的必要性
1.1 支付系统的核心痛点：三大顽疾
在电商、金融、SaaS 等业务场景中，支付订单系统是资金流转的核心枢纽。然而，随着业务规模增长与分布式架构的普及，系统会频繁遭遇以下三类致命问题：
| 问题类型 | 典型场景 | 业务后果 |
|---|---|---|
| 重复支付 | 用户点击“支付”按钮后因网络延迟多次提交；支付网关回调超时后重试导致同一订单被扣款两次。 | 资金损失、客诉激增、财务对账异常。 |
| 掉单 | 支付网关回调丢失；异步消息队列积压后消息被丢弃；数据库主从切换导致订单状态未持久化。 | 用户已付款但订单显示“未支付”，引发退款或重复发货。 |
| 对账不平 | 内部订单状态与第三方支付渠道的交易记录不一致；部分退款场景下金额拆分错误。 | 每日资金轧差失败，财务无法结账，严重时触发监管合规风险。 |
行业数据： 据某头部支付平台统计，超过 70% 的生产事故与重复支付或掉单直接相关；每次重复支付事故的平均赔付成本超过 15 万元人民币。
1.2 问题根源：缺乏统一的领域抽象与幂等保障
上述问题的技术根源可归纳为两点：
- 领域模型混乱： 订单、支付单、流水、退款单等核心概念边界模糊，状态机分散在多个服务中，导致状态流转不可控。
- 接口缺乏幂等性： 外部渠道回调、用户重试、内部重试均未设计幂等令牌，同一请求被多次执行时产生副作用。
下图展示了典型支付系统中，因缺乏聚合建模与幂等设计而导致的重复支付与掉单链路：
1.3 为什么需要领域聚合建模？
领域驱动设计（DDD）中的聚合（Aggregate）概念，为支付系统提供了精确的边界划分与一致性保障：
- 聚合根（Aggregate Root）：如
PaymentOrder作为聚合根，所有对支付单的操作必须通过聚合根进行，确保内部状态的一致性。 - 边界内强一致性：聚合内部的状态变更（如支付成功、退款中、已完成）在同一个事务边界内完成，避免跨服务状态不一致。
- 明确的业务不变式：例如“一个订单只能关联一个有效的支付单”、“支付金额不能超过订单金额”等规则，由聚合自身保障。
实践建议： 在支付系统中，建议将
PaymentOrder（支付单）、PaymentTransaction（支付流水）、RefundOrder（退款单）分别建模为独立的聚合，每个聚合拥有自己的生命周期与状态机。
1.4 为什么需要幂等设计？
幂等性（Idempotency）是指：无论请求被调用多少次，产生的结果与调用一次完全相同。在支付系统中，幂等设计是防止重复支付和掉单的最后一道防线：
| 幂等实现方式 | 适用场景 | 关键要素 |
|---|---|---|
| 幂等令牌（Idempotency Key） | 用户提交支付、退款请求 | 客户端生成唯一 Key，服务端去重 |
| 去重表（Deduplication Table） | 支付网关回调、消息队列消费 | 以回调流水号或消息 ID 为主键 |
| 乐观锁 / 版本号 | 状态更新操作 | 数据库行级版本号，CAS 更新 |
| 状态机前置校验 | 状态流转控制 | 只允许合法状态迁移，拒绝重复成功 |
下图展示了引入幂等设计后，支付系统的安全处理流程：
1.5 课程核心目标
本课程将围绕以下三条主线展开：
- 领域聚合建模：使用 DDD 方法论，对支付订单、支付单、退款单、流水等核心领域进行聚合划分与状态机设计。
- OpenAPI 接口规范：基于 OpenAPI 3.0 标准，设计幂等友好的接口契约，包括幂等 Key 的传递、响应码定义、错误处理模式。
- 幂等处理方案：从去重表、分布式锁、乐观锁到状态机前置校验，给出完整的幂等实现策略与代码示例。
前置要求： 读者需具备基本的支付业务常识、RESTful API 设计经验以及 Java/Spring 开发基础。本课程不涉及具体的支付渠道对接细节，聚焦于通用架构设计。