4. 订单状态机与领域事件：状态流转定义、事件发布订阅机制、事件溯源思想

在支付订单系统中，订单的生命周期由一系列严格的状态转换构成。状态机（State Machine）与领域事件（Domain Event）是保障订单一致性、可追溯性和系统解耦的核心建模手段。本节将深入定义订单状态流转、设计事件发布订阅机制，并引入事件溯源（Event Sourcing）思想以应对复杂对账与审计需求。

4.1 订单状态机定义

订单状态机定义了订单从创建到终态的所有合法路径。每个状态转换由特定的业务动作触发，并伴随领域事件的发布。以下是支付订单的核心状态定义：

4.2 状态流转规则与合法性校验

状态转换必须遵循预定义的规则矩阵，防止非法跳转。以下为关键状态转换规则：

• INIT → PAYING：用户提交支付请求，校验订单未超时且未取消。
• PAYING → PAID：支付网关异步通知成功，校验签名与金额。
• PAYING → FAILED：支付网关返回失败或超时未回调。
• PAID → PROCESSING：系统自动或人工触发履约。
• PROCESSING → SUCCESS：履约完成，所有子任务结束。
• INIT / PAYING → CANCELLED：用户取消或系统超时取消。
• PAID / PROCESSING → REFUNDING：发起退款申请。
• REFUNDING → REFUNDED：退款成功。

4.3 领域事件发布订阅机制

每次状态转换都应发布对应的领域事件，用于解耦下游处理逻辑（如发送通知、更新缓存、触发对账）。事件模型设计如下：

事件发布采用 事务性发件箱模式（Transactional Outbox），确保事件与订单状态变更的原子性：

// 伪代码：事务性发件箱模式
@Transactional
public void changeOrderStatus(String orderId, OrderStatus newStatus) {
    // 1. 校验状态转换合法性
    Order order = orderRepository.findById(orderId);
    order.validateTransition(newStatus);
    
    // 2. 更新订单状态
    order.setStatus(newStatus);
    orderRepository.save(order);
    
    // 3. 写入事件发件箱（同一事务）
    DomainEvent event = DomainEventFactory.create(order, newStatus);
    outboxRepository.save(event);
}

// 独立的后台线程轮询发件箱，发布事件到消息队列
@Scheduled(fixedDelay = 1000)
public void publishOutboxEvents() {
    List<DomainEvent> pendingEvents = outboxRepository.findPendingEvents();
    for (DomainEvent event : pendingEvents) {
        messageQueue.publish(event);
        outboxRepository.markAsPublished(event.getId());
    }
}

4.4 事件溯源思想与订单审计

事件溯源（Event Sourcing）将订单状态视为一系列领域事件的累积结果，而非存储当前快照。核心思想：

• 存储事件流：每次状态变更仅追加写入事件，不更新订单记录。
• 重建聚合状态：通过回放事件流计算当前订单状态。
• 快照优化：定期生成状态快照，避免全量回放。

在支付订单场景中，事件溯源的主要价值：

1. 完整审计链路：所有状态变更均有不可篡改的事件记录，满足金融级审计要求。
2. 时间旅行调试：可回溯订单在任意时间点的状态，便于问题排查。
3. 事件驱动分析：事件流可直接用于实时风控、用户行为分析。

4.5 状态机与事件驱动架构图

下图展示了订单状态机与领域事件的协同工作流程：

4.6 状态机与缓存协同策略

在 Redis 缓存中，订单状态与事件的处理需要精细设计：