3. 事件风暴中的事务边界识别：如何通过事件风暴识别聚合边界、确定事务一致性边界、区分强一致与最终一致

在分布式系统设计中，事务边界的误判是导致数据不一致、性能瓶颈和故障扩散的首要原因。事件风暴（Event Storming）作为一种协作建模技术，能够将业务专家与技术专家的隐性知识显性化，从而精准定位聚合边界与一致性边界。本节将系统阐述如何通过事件风暴的“命令-事件-聚合”三要素，推导出强一致与最终一致的决策依据。

3.1 从业务事件到聚合边界的推导路径

聚合（Aggregate）是事务一致性的最小单元。在事件风暴画布上，聚合边界并非凭空定义，而是通过以下三步逐步收敛：

1. 识别领域事件（Domain Event）：业务人员用橙色便签描述“已经发生的事实”，例如“订单已提交”、“库存已扣减”。
2. 追溯触发命令（Command）：蓝色便签标注导致事件发生的操作，例如“提交订单”、“扣减库存”。
3. 归并聚合（Aggregate）：将同一业务生命周期内、必须保持强一致性的命令与事件归入同一个黄色便签聚合。

以下表格展示了典型电商场景中聚合边界的划分对比：

3.2 事务一致性边界的二维判定模型

在事件风暴画布上，确定一致性边界需要同时评估业务紧密度与性能容忍度两个维度。下图展示了二维判定矩阵：

3.3 强一致与最终一致的决策清单

在事件风暴画布上完成聚合划分后，使用以下清单对每个跨聚合交互进行一致性模式决策：

• 业务约束检查：该操作是否涉及资金、库存、账户余额等核心资产？如果是，优先考虑聚合内强一致。
• 时间敏感度：业务方能否接受秒级甚至分钟级的数据延迟？能接受则选择最终一致。
• 幂等性支持：下游消费者是否具备幂等处理能力？不具备则必须使用强一致或至少“至少一次”语义。
• 补偿可行性：如果最终一致失败，是否有明确的补偿流程（如退款、冲正）？有补偿则最终一致更安全。
• 吞吐量要求：目标 TPS 是否超过 1000？超过则避免跨聚合强一致，改用事件驱动。

3.4 事件风暴画布上的边界可视化

在物理事件风暴画布上，推荐使用以下视觉约定来标记边界类型，确保所有参与者一目了然：

3.5 从事件风暴到代码实现的边界映射

完成事件风暴画布上的边界识别后，需要将结果映射到代码实现。以下是一个典型的聚合边界代码示例：

// 订单聚合：强一致边界
public class OrderAggregate {
    private OrderId id;
    private OrderStatus status;
    private List<OrderLineItem> items;
    private InventoryReservation reservation;

    // 命令：提交订单
    public OrderSubmittedEvent submit() {
        // 校验库存（聚合内操作）
        this.reservation.reserve(this.items);
        this.status = OrderStatus.SUBMITTED;
        return new OrderSubmittedEvent(this.id, this.items);
    }
}

// 跨上下文事件处理：最终一致
public class InventoryProjection {
    @EventHandler
    public void on(OrderSubmittedEvent event) {
        // 异步扣减库存，允许短暂不一致
        inventoryService.deduct(event.getItems());
    }
}

上述代码清晰地体现了：OrderAggregate 内部的状态变更（订单状态 + 库存预留）在同一个事务中完成；而库存的实际扣减通过事件监听异步执行，属于最终一致。