📚 课程目录第2章事件风暴基础

2. 事件风暴基础：什么是事件风暴、核心元素

事件风暴（Event Storming）是由 Alberto Brandolini 提出的一种协作建模方法，它通过高密度、低仪式感的“工作坊”形式，让领域专家、开发人员、产品经理围坐在一张巨大的白板前，用彩色便签纸快速暴露业务全貌。在分布式事务架构设计中，事件风暴是发现聚合边界、识别一致性需求、划分限界上下文的最有效工具。

  核心认知：事件风暴不是 UML 图，不是架构图，而是一种“业务发现仪式”。它把隐藏在每个人头脑中的业务规则、异常流程、补偿逻辑，通过“事件”这个统一语言暴露到桌面上。

2.1 什么是事件风暴

事件风暴本质上是一种“时间轴 + 事件流”的协作建模技术。工作坊参与者按以下节奏推进：

先写“过去发生的事”（橙色便签）—— 领域事件，例如“订单已创建”、“库存已扣减”。
再写“谁触发了这件事”（蓝色便签）—— 命令，例如“提交订单”、“确认支付”。
然后找“谁在执行命令”（黄色便签）—— 聚合/实体，例如“订单聚合”、“库存聚合”。
最后划出“业务边界”（绿色便签/粗线）—— 限界上下文，例如“订单上下文”、“支付上下文”。

整个过程通常持续 2–4 小时，产出物是一张覆盖整面墙的“事件风暴画布”，它直接映射为微服务拆分和分布式事务边界的设计依据。

实战建议：在分布式事务课程中，事件风暴画布上的每一个“聚合”都对应一个本地事务边界；每一条跨聚合的事件流，都意味着需要引入 Saga、TCC 或 Outbox 模式来保证最终一致性。

2.2 核心元素详解

事件风暴包含四个核心建模元素，它们构成了从“业务行为”到“技术架构”的完整映射链。下表总结了每个元素的定义、便签颜色、在分布式事务中的角色：

核心元素	便签颜色	定义	分布式事务中的角色
事件（Event）	橙色	已经发生的、不可变的事实，通常用过去时命名	触发 Saga 步骤、记录 Outbox 消息、驱动补偿流程
命令（Command）	蓝色	用户或系统发出的意图，期望改变系统状态	对应 API 请求、消息指令，是事务的入口
聚合（Aggregate）	黄色	一组强一致性实体的边界，保证事务原子性	本地事务的边界，一个聚合内使用 ACID，跨聚合使用最终一致性
限界上下文（Bounded Context）	绿色/粗线	模型与语言的边界，对应微服务或模块的划分	分布式事务的“域”边界，跨上下文通信必须通过事件或消息

2.3 核心元素关系图

下图展示了四个核心元素在事件风暴画布上的典型关系：命令触发事件，事件改变聚合状态，聚合被限界上下文包裹，跨上下文的事件流构成分布式事务的协调路径。

2.4 事件（Event）—— 业务的事实记录

事件是事件风暴的“第一公民”。它描述的是已经发生且不可撤销的业务事实。在分布式事务中，事件扮演着“状态变更通知”和“补偿触发信号”的双重角色。

命名规范：过去时 + 业务含义，例如 OrderCreated、PaymentFailed、InventoryReserved。
包含数据：事件 ID、发生时间、业务关键 ID（如订单号）、状态快照（可选）。
分布式事务用途：作为 Saga 的步骤输出、作为 Outbox 的消息体、作为补偿流程的启动信号。

  避坑指南：不要将“事件”与“命令”混淆。事件是“已经发生的事实”，命令是“想要发生的意图”。例如“用户点击支付按钮”是命令，“支付已处理”才是事件。在事件风暴画布上，命令写在左侧，事件写在右侧，中间是聚合。

2.5 命令（Command）—— 意图的载体

命令代表用户或外部系统发出的操作意图。它不一定成功执行——可能被聚合的校验逻辑拒绝。命令是分布式事务的“入口点”。

命名规范：动词 + 宾语，例如 SubmitOrder、ConfirmPayment、CancelReservation。
与事件的关系：一个命令通常对应一个或多个事件。命令成功 → 产生“已成功”事件；命令失败 → 产生“已失败”事件。
在 Saga 中的角色：命令是 Saga 编排器向参与者发送的“执行步骤”或“补偿步骤”。

2.6 聚合（Aggregate）—— 一致性边界

聚合是 DDD 战术模式中最关键的概念，也是分布式事务中本地事务的边界。一个聚合内的所有实体共享强一致性（ACID），跨聚合则必须使用最终一致性。

聚合特性	说明	分布式事务影响
原子性	聚合内所有修改要么全成功，要么全回滚	一个聚合 = 一个本地数据库事务
一致性边界	聚合保证内部业务规则不被破坏	跨聚合的规则一致性需要 Saga 协调
唯一标识	每个聚合通过 ID 被外部引用	事件中携带聚合 ID 用于关联
事件发布	聚合状态变更时发布领域事件	事件驱动跨聚合的最终一致性

常见错误：初学者容易把“数据库表”当作聚合边界。聚合是业务一致性边界，不是数据表边界。一个聚合可能包含多张表，也可能一张表包含多个聚合（通过聚合 ID 区分）。在事件风暴中，聚合的大小直接影响分布式事务的复杂度——聚合越大，本地事务越重，但跨聚合协调越少；聚合越小，本地事务越轻，但 Saga 步骤越多。

2.7 限界上下文（Bounded Context）—— 微服务的边界

限界上下文是 DDD 战略设计中最核心的边界概念。它定义了模型、语言、业务规则的适用范围。在分布式系统架构中，一个限界上下文通常对应一个微服务或一个独立模块。

语言边界：同一个词在不同上下文中含义不同。例如“客户”在“订单上下文”中指下单人，在“风控上下文”中指风险主体。
数据边界：每个上下文拥有自己的数据存储，不直接访问其他上下文的数据库。
通信方式：跨上下文通过事件、API 或消息队列通信，禁止共享数据库。
分布式事务边界：跨限界上下文的事务必须使用 Saga、TCC 或 Outbox 模式，不能使用分布式事务（如 XA）。

2.8 核心元素在分布式事务中的协作流程

下面这张 SVG 图展示了从“用户发起命令”到“跨上下文最终一致”的完整协作流程，帮助理解四个元素如何共同支撑分布式事务：

2.9 本章小结

事件风暴的四个核心元素构成了分布式事务架构设计的“语法”：

事件是事实，驱动跨聚合的最终一致性；
命令是意图，是事务的入口；
聚合是本地事务边界，保证强一致性；
限界上下文是微服务边界，定义分布式事务的协调范围。