1. 课程导论：支付系统面临的挑战与 DDD 的应对之道
1.1 支付系统的核心挑战：三座大山
现代支付系统运行在每秒数万笔交易的流量洪峰之下，同时必须保证每一分钱的精确流转。这构成了支付架构设计的三个根本矛盾：高并发、一致性与资金安全。三者相互制约，任何一方的缺失都可能导致系统崩溃或资损。
| 挑战维度 | 典型场景 | 技术难点 | 后果 |
|---|---|---|---|
| 高并发 | 秒杀、红包、大促峰值 | 数据库连接池耗尽、热点账户锁竞争、响应超时 | 订单丢失、用户体验下降 |
| 一致性 | 跨账户转账、分账、退款 | 分布式事务、网络分区、状态机回滚 | 账务不平、对账失败 |
| 资金安全 | 支付成功但未入账、重复支付、篡改金额 | 幂等性、防重放、审计追踪、不可抵赖 | 资损、合规风险、法律纠纷 |
关键认知： 传统单体架构或简单的分层架构在面对这三座大山时，往往陷入“牵一发而动全身”的困境。业务逻辑与基础设施耦合，导致每次修改都充满风险。
1.2 为什么需要领域驱动设计（DDD）？
DDD 不是银弹，但它为支付系统提供了应对复杂性的核心武器：将业务复杂度与技术实现解耦。通过以下四个核心机制，DDD 直接回应了支付系统的三大挑战：
- 限界上下文（Bounded Context）：将支付拆分为“订单”、“支付”、“账务”、“对账”等独立上下文，每个上下文拥有自己的数据模型和事务边界，从根源上减少跨域耦合。
- 聚合（Aggregate）：以“支付订单”为聚合根，封装内部状态变更规则，确保在一个事务边界内完成所有一致性操作，避免跨表分布式事务。
- 领域事件（Domain Event）：通过事件驱动实现上下文间的最终一致性，例如“支付成功”事件触发账务记账、通知发货，天然支持高并发削峰。
- 仓储（Repository）：隔离领域层与持久化技术，使核心逻辑可脱离数据库进行单元测试，保障资金安全逻辑的可靠性。
实践提示： 在支付系统中，DDD 的“战术建模”阶段（聚合、实体、值对象）比“战略建模”阶段（限界上下文、上下文映射）更早产生直接收益。建议从核心支付流程的聚合建模入手。
1.3 支付系统面临的挑战与 DDD 应对策略对比
| 挑战 | 传统架构痛点 | DDD 应对策略 | 收益 |
|---|---|---|---|
| 高并发 | 单库单表锁竞争 | 聚合内强一致性 + 聚合间最终一致性 | 减少锁范围，提升吞吐 |
| 一致性 | 分布式事务（XA/TCC）复杂脆弱 | 领域事件 + 事件溯源（Event Sourcing） | 天然支持回放与补偿 |
| 资金安全 | 业务逻辑散落在 Service 层 | 聚合根封装不变规则 + 领域服务校验 | 核心逻辑可测试、可审计 |
| 需求变更 | 修改影响面大，回归成本高 | 限界上下文隔离，独立演进 | 快速响应业务变化 |
1.4 课程目标与学习路径
本课程旨在帮助你掌握一套可落地、可验证的支付订单领域聚合建模方法，并以此为基础设计微服务边界与通信机制。完成本课程后，你将能够：
- 独立完成支付订单核心流程的领域建模（聚合、实体、值对象、领域事件）。
- 合理划分支付微服务边界，避免“分布式单体”陷阱。
- 设计基于事件驱动的异步通信机制，保障最终一致性与资金安全。
- 应对高并发场景下的热点账户、库存扣减等经典难题。
学习路径分为四个阶段，层层递进：
- 基础篇（第1-5章）：支付系统挑战与 DDD 核心概念对齐，建立统一语言。
- 建模篇（第6-15章）：从支付订单聚合出发，逐步构建账务、对账、退款等核心聚合。
- 架构篇（第16-25章）：基于聚合划分微服务边界，设计同步/异步通信机制。
- 实战篇（第26-30章）：结合具体案例（秒杀、跨境支付）进行完整建模与架构推演。
学习建议： 不要跳过基础篇直接看实战。支付领域的 DDD 建模对“不变规则”和“事务边界”的敏感度极高，基础概念理解不透彻会导致后续建模出现资损漏洞。
1.5 支付订单领域核心概念关系图
下图展示了支付订单领域中最核心的几个限界上下文及其关系，这是后续所有建模工作的起点：
1.6 课程核心知识图谱
为了让你对后续 29 章的内容有一个全局预览，下面以知识图谱的形式展示本课程的核心模块及其依赖关系：
学习路径建议： 建议按照“建模 → 边界 → 通信 → 保障”的顺序学习。如果时间有限，可以优先掌握“支付订单聚合建模”和“异步事件驱动”两个模块，它们覆盖了支付系统 80% 的核心场景。