事件风暴：从战略边界推到战术聚合的桥

前三章给了边界：领域与统一语言（01）、子域划分（02）、限界上下文与一词多义（03）。边界是一组"框"，但框里要放什么类、哪些字段必须在同一个事务里改、哪个对象是入口——这些战术问题，光盯着框看不出来。本章给一个把"框"展开成"协作流程"的具体工作法：事件风暴。它的产出不是图好看，而是一串可以直接翻译成命令、聚合、读模型的贴纸，正好接上 05 章的聚合设计。

全章用同一个具体场景走查：「云市」平台上一个买家把购物车结算成订单、订单被支付、库存被预留、运单被创建的全过程。这条主线会在 4.4 节被逐格拆成贴纸，再被翻成代码。

4.1为什么从"事件"起步，而不是名词或 ER 图

事件风暴：让业务专家用过去式的"已发生的事"来叙述业务，把这些事件按时间贴成一面墙，关键节点和知识盲区会自己浮出来。

为什么是过去式：一个领域事件 Domain Event 是"领域里已经发生、业务关心的一件事实"，命名用过去式——OrderPlaced（订单已下单）、OrderPaid（订单已支付）、StockReserved（库存已预留）。过去式不是语法洁癖：它强迫叙述者说"发生了什么"，而不是"系统应该有什么按钮"。业务专家天然会用过去式讲故事——"客户把购物车结算了，然后我们这边收到款，仓库再去备货"。这种叙述里，每一个分句几乎都是一个领域事件。把它们抄成贴纸贴上墙，建模就开始了。

事件优先比名词优先快在哪：名词优先时，"商品 Product"是一个词，大家以为指同一个东西，争论被推迟到写代码时才爆发（这正是 03 章一词多义 polysemy 的来源——目录里的胖展示对象、销售里的下单快照、库存里的 SKU 是三个类）。事件优先时，分歧立刻可见：当有人贴出"价格已变更"而另一人贴出"下单价格已锁定"，房间里马上意识到价格在下单那一刻被冻结，目录改价不影响已下单的订单——这是销售上下文里一条真实业务规则，名词建模要到很晚才会发现它。

暴露知识盲区，是它最被低估的产出。当一组事件之间贴不上"是谁、按什么规则触发的下一步"，墙上就留下一个空洞。空洞处常用一张显眼的贴纸标成热点 hotspot（争议/未知/风险）。云市的典型热点："运单已创建失败时，已经预留的库存怎么释放？"——这不是技术问题，是业务还没想清楚的规则。事件风暴的价值，一半在它贴出来的事件，另一半在它逼出来的这些问号。

4.2三个缩放层级：全局 / 流程级 / 设计级

事件风暴不是一种会，而是同一手法在三个缩放层级上的三场会：全局 Big-Picture 看地形、流程级 Process-Level 看一条流程、设计级 Design-Level 看一个聚合怎么落地。

三层之间是缩放关系，不是审批流水线。全局层的一段事件序列（云市的"下单到发货"）被挑出来，单独拉一场流程级；流程级里识别出的某个聚合候选（Order），再拉一场设计级把它的边界和不变量钉死。本书的主战场是设计级——因为只有设计级直接产出能翻成代码的结构，也只有它直接喂给 05 章的聚合设计。下一节先把设计级的贴纸语义对齐，后面才好做推导。

4.3设计级语义：六种贴纸各代表什么

设计级用六种颜色的贴纸表达一套固定语义：橙=领域事件、蓝=命令、黄=聚合、紫=策略、绿=读模型、黄底小人=参与者；颜色背后是确定的角色和连线规则。

下面是 Brandolini 约定的设计级语义。本教程是单色品牌（朱红 + 黑白），所以正文与图里用颜色名做文字标注，不真的上色——记住"橙色那张是事件"即可，颜色只是助记。

这六者不是平列，而是串成一条有方向的因果链，这是整套手法的发动机：

参与者 → 看读模型 → 发命令 → 命令落到聚合上 → 聚合发出事件 → 策略监听事件 → 策略触发下一个命令 →（回到聚合）……

4.4从事件墙推出边界与聚合：一条推导链

事件 → 命令 → 聚合 → 读模型 → 上下文，再到代码：这条链让聚合从协作里被推导出来，而不是凭一张表关系图设计出来。

先把云市下单主线一格一格摆成事件墙（按颜色名标注，不上色）：

逐步把贴纸推成模型（这是机械的，不是灵感）：

1. 事件 → 命令：每个事件问"是哪个意图导致它发生的"。订单已下单 的前因是下单命令；库存已预留 的前因是预留库存命令。命令和事件一一配对，命令祈使、事件过去式。
2. 命令 → 聚合：每个命令问"谁来接收它、谁负责保证产出的那个事件的不变量"。下单落到 Order——只有 Order 能保证"总额 = Σ 行金额、状态从 CREATED 起步"这些不变量。预留库存落到 StockItem——只有它能保证"预留量不超过可用量"。谁守护事件的不变量，谁就是聚合，这是聚合浮现的判据，比看表关系可靠。
3. 事件 → 策略：两个聚合之间的衔接靠策略。"每当 订单已下单，就发预留库存命令"——这是一张紫色策略贴纸。注意它跨在销售和库存两个上下文之间，所以这次衔接不是同一个事务（05、07 章详解）。
4. 读模型 → 参与者决策：买家点"结算"前，看的是绿色的购物车视图读模型。读模型是参与者做决定的依据，不属于任何聚合的内部状态，常单独走查询路径（CQRS-lite，08 章）。
5. 聚类成上下文：把"守护相关不变量、用同一套语言"的聚合圈在一起，就回到了 03 章的限界上下文。Order 在销售 Sales，StockItem 在库存 Inventory，圈的位置正是图里那道朱红竖线。

最后一步：贴纸落到代码骨架。设计级的产出可以几乎机械地映射成 Java 结构——命令是一个意图对象、聚合是接收命令并发事件的类、策略是监听事件的反应。这里只给骨架说明模型，不要求端到端可运行；不变量与工厂的完整写法留给 05、06 章。

// 蓝色「命令」→ 一个表达意图的不可变对象
public record PlaceOrder(String buyerId, List<OrderLineDraft> lines) {}

// 黄色「聚合」Order：接收命令、守护不变量、发出橙色事件
public class Order {
    private OrderStatus status;          // CREATED -> CONFIRMED -> PAID -> ...
    private final List<OrderLine> lines; // 聚合内部实体，外部不可直接持有

    // 工厂：产出的 Order 已满足全部不变量（详见 05/06 章）
    public static Order place(PlaceOrder cmd, PricingService pricing) {
        // ……校验非空、用 PricingService 算价、置状态为 CREATED……
        Order order = new Order(/* ... */);
        order.raise(new OrderPlaced(order.id(), cmd.buyerId())); // 橙色事件
        return order;
    }
}

// 紫色「策略」：每当 OrderPlaced，就向库存上下文发「预留库存」命令
public class ReserveStockOnOrderPlaced {
    public void on(OrderPlaced event) {
        // 跨上下文、异步：不在下单同一个事务里（07 章最终一致）
        commandBus.send(new ReserveStock(event.orderId()));
    }
}

4.5互补工具：领域叙事与实例化映射

事件风暴不是唯一的协作建模法，而是工具箱里的一件：领域叙事擅长走通一个具体案例，实例化映射擅长把规则落成可验收的例子，三者分工互补，不是竞争。

领域叙事 Domain Storytelling：走一个具体案例

领域叙事让业务专家用一句话句式——"谁（参与者）用什么（工作对象）对谁做了什么"——把一个具体案例从头讲到尾，边讲边用图标和编号箭头记录。它的产出是一个带顺序的故事图，专治事件风暴容易停留在类型层面的毛病：与其讨论抽象的"下单流程"，不如走一遍"买家张三把购物车里两件商品结算成订单 #1024、付款、仓库备货发运"。具体案例会逼出事件风暴漏掉的分支（缺货怎么办、优惠券失效怎么办）。Hofer 与 Schwentner 在《Domain Storytelling》里把它定位成统一语言（01 章）的采集器——故事里反复出现的名词和动词，就是该进统一语言的词。

实例化映射 Example Mapping：把规则落到验收例子

实例化映射（Matt Wynne 提出）处理事件风暴留下的热点。它用四色卡片围绕一条规则展开：黄卡=要讨论的故事，蓝卡=规则，绿卡=每条规则的具体例子，红卡=当场答不出的问题。云市那个热点"超时未支付如何取消"，用实例化映射会被拆成：规则"创建后 30 分钟未支付则取消"，例子"29 分钟时支付成功 → 不取消"、"31 分钟仍未支付 → 自动取消并释放预留库存"，以及红卡"已部分支付的订单算不算未支付？"。这些绿卡例子可以直接变成聚合状态机的验收测试，把模糊规则钉成可执行的判据。

顺序常是：事件风暴找出流程和热点 → 领域叙事走通有歧义的具体案例、定准语言 → 实例化映射钉死每条规则的验收例子。三者都不替代彼此，挑哪件、挑几件，取决于当下卡在"看不清流程"、"语言不统一"还是"规则没收敛"。