1. 课程导论：支付订单在电商系统中的核心地位，为什么需要聚合建模与缓存策略

1.1 支付订单：电商系统的“资金命脉”与“状态中枢”

在任何一个电商系统中，支付订单都不是一个简单的数据记录。它既是用户交易行为的最终凭证，也是资金流转的法定依据，更是整个系统状态一致性的核心锚点。从用户点击“提交订单”到最终“支付成功”，一笔支付订单的生命周期会穿越购物车、库存、优惠券、支付网关、账务、物流等多个限界上下文（Bounded Context）。

支付订单的核心地位体现在以下三个维度：

1.2 为什么需要聚合建模？——从“数据表思维”到“领域模型思维”

很多团队在设计支付订单时，习惯从数据库表结构出发：设计一张 order 表、一张 order_item 表、一张 payment_record 表，然后通过外键关联。这种“数据表思维”在业务简单时勉强可用，但一旦遇到复杂的支付场景（如部分退款、多次支付、优惠券分摊），就会暴露出严重问题：

• 业务规则散落：支付金额校验、状态流转逻辑分散在 Service 层各处，难以维护。
• 事务边界模糊：一次支付操作需要更新多张表，分布式事务成本高，容易产生不一致。
• 并发控制困难：多线程同时操作同一笔订单的不同子表时，容易出现脏写或丢失更新。

领域驱动设计（DDD）中的聚合（Aggregate）模式正是为了解决这些问题而生。聚合将一组具有紧密业务关联的实体和值对象封装为一个整体，通过聚合根（Aggregate Root）作为唯一的外部访问入口，确保业务不变量的强一致性。

1.3 为什么需要缓存策略？——支付订单的“读”与“写”双重挑战

支付订单场景对缓存的需求远比其他业务模块复杂。它不仅要解决高并发读的压力，还要谨慎处理写操作的缓存一致性。以下是支付订单场景中缓存面临的典型挑战：

• 高频查询：用户频繁刷新订单列表、订单详情页，支付网关回调后需要立即查询订单状态。
• 写后立即读：支付成功后，用户立即刷新页面期望看到“已支付”状态，缓存更新必须及时。
• 状态敏感：订单状态一旦错误（如显示“待支付”实际已支付），可能导致用户重复支付或投诉。
• 数据一致性要求极高：缓存与数据库的不一致窗口必须尽可能短，甚至在某些场景下需要“缓存失效后强同步”。

因此，支付订单的缓存策略不能简单套用“先删缓存再更新数据库”或“先更新数据库再删缓存”的通用方案，而需要结合聚合建模的边界，设计针对聚合根的缓存策略。

1.4 聚合建模 + 缓存策略：1+1 > 2 的协同效应

将聚合建模与缓存策略结合，可以产生显著的协同效应：

1.5 本章小结与课程路线图

通过本章导论，我们明确了以下核心观点：

1. 支付订单是电商系统的核心聚合，其建模质量直接影响资金安全和系统稳定性。
2. 聚合建模通过聚合根封装业务规则，解决了数据表思维下业务规则散落、事务边界模糊、并发控制困难的问题。
3. 缓存策略需要针对支付订单“写后立即读”和“状态敏感”的特点，以聚合根为粒度设计缓存方案。
4. 两者结合可以实现数据一致性、并发性能、维护成本和扩展性的最优平衡。

在接下来的课程中，我们将按照以下路线图逐步深入：