4. 识别领域事件：从业务流程中提取关键事件
领域事件（Domain Event）是事件风暴的核心产出，它记录了业务中发生的、对后续流程有影响的事实。在分布式事务场景下，领域事件往往对应着跨服务的数据变更、状态转移或补偿触发点。本节将引导你从业务流程中系统性地提取这些关键事件。
4.1 领域事件的定义与特征
一个合格的领域事件必须满足以下特征：
| 特征 | 说明 | 反例 |
|---|---|---|
| 过去时态 | 事件名称必须是已经发生的动作，使用过去分词 | “订单已创建” ✅ / “创建订单” ❌ |
| 业务有意义 | 事件对业务方或下游系统有实际价值 | “数据库行已插入” ❌ |
| 不可变事实 | 事件一旦发生，不能被修改或撤销，只能通过补偿事件对冲 | “订单金额已修改” ❌（应使用“订单金额已更正”） |
| 触发后续动作 | 事件通常会被一个或多个订阅者消费，驱动下一步流程 | “日志已记录” ❌（通常不触发业务动作） |
命名规范： 推荐使用
{业务主体}已{过去分词} 格式，例如：订单已提交、库存已预占、支付已成功。保持全团队统一，避免歧义。
4.2 从业务流程到事件列表：三步提取法
以下方法适用于任何业务领域，尤其适合分布式事务场景下的复杂流程梳理。
- 步骤一：绘制流程泳道 —— 将参与方（用户、前端、订单服务、支付服务、库存服务等）按泳道排列，画出主流程和异常分支。
- 步骤二：标记状态变化点 —— 在每个泳道中，找到业务对象（订单、支付单、库存记录）发生状态变更的位置，这些位置就是事件的候选点。
- 步骤三：用橙色便签写出事件 —— 将每个状态变化点用“过去时态”短语写在橙色便签上，贴在对应泳道的时序位置。
实战案例： 以“电商下单”流程为例，从“用户点击提交”到“订单完成”，我们按三步法提取出以下候选事件：
订单已提交 → 库存已预占 → 支付已发起 → 支付已成功 → 订单已确认 → 库存已扣减 → 订单已完成
4.3 分布式事务场景下的关键事件分类
在分布式事务环境中，领域事件需要额外关注事务边界和补偿逻辑。我们将事件分为三类：
| 事件类型 | 作用 | 典型示例 | 事务语义 |
|---|---|---|---|
| 正向事件 | 推进主流程前进 | 订单已提交、支付已成功 | Try / Confirm 阶段 |
| 补偿事件 | 回滚或撤销已发生的正向操作 | 库存预占已释放、支付已退款 | Cancel 阶段 |
| 超时/异常事件 | 标记流程超时或系统异常 | 支付超时已触发、库存预占失败 | 异常处理阶段 |
在事件风暴画布上，建议使用不同颜色的便签区分这三类事件：
- 橙色 —— 正向事件（标准领域事件）
- 粉色/红色 —— 补偿事件
- 黄色 —— 超时/异常事件
4.4 事件提取实战：分布式事务下单流程
以下是一个典型的 TCC（Try-Confirm-Cancel）分布式事务场景，我们从中提取完整的领域事件列表。
上图展示了从“订单已提交”到“订单已完成”的完整事件链。注意：支付已成功 和 库存已扣减 使用绿色标记，表示它们是确认阶段的关键事件，一旦发生即不可回滚。
4.5 补偿事件与异常事件识别
在分布式事务中，补偿事件与正向事件同等重要。以下表格展示了上述流程中可能出现的补偿/异常事件：
| 触发条件 | 补偿/异常事件 | 类型 | 影响 |
|---|---|---|---|
| 库存预占失败 | 库存预占已失败 | 异常事件 | 订单进入“待补货”或“已取消” |
| 支付超时 | 支付超时已触发 | 异常事件 | 触发库存预占释放 |
| 支付失败后回滚 | 库存预占已释放 | 补偿事件 | 库存恢复可用数量 |
| 订单取消 | 订单已取消 | 补偿事件 | 触发支付退款 + 库存释放 |
| 支付退款完成 | 支付已退款 | 补偿事件 | 资金返回用户账户 |
关键原则： 每个正向事件都应该有对应的补偿事件，除非该事件已经进入不可逆的终态（如“支付已成功”）。补偿事件的设计直接决定了分布式事务的回滚能力，是 Saga 和 TCC 模式的核心。
4.6 事件风暴画布上的事件组织
在事件风暴工作坊中，提取出的事件需要按照时间顺序从左到右排列在画布上。以下是组织建议：
- 时间轴：从左到右表示时间推进，越靠右的事件发生时间越晚。
- 泳道对齐：事件贴在对应服务/参与方的泳道内，便于识别事件归属。
- 分组标记：使用虚线框将一组相关事件圈起来，表示一个事务边界（Saga 或 TCC 阶段）。
- 颜色编码：严格遵循正向（橙色）、补偿（粉色/红色）、异常（黄色）的颜色规则，便于视觉扫描。
上图展示了事件在画布上的组织方式：Try 阶段（蓝色虚线框）包含正向事件，Confirm 阶段（绿色虚线框）包含确认事件，Cancel 阶段（红色虚线框）包含补偿事件。这种分组方式让事务边界一目了然。
4.7 事件提取检查清单
完成事件提取后，使用以下清单进行质量检查：
- ✅ 所有事件名称使用过去时态
- ✅ 每个事件都有明确的触发者（用户、定时器、其他事件）
- ✅ 每个事件都有至少一个订阅者（后续动作）
- ✅ 正向事件与补偿事件成对出现（终态事件除外）
- ✅ 异常事件覆盖了超时、失败、拒绝等场景
- ✅ 事件在画布上按时间顺序从左到右排列
- ✅ 事件颜色编码与类型一致
- ✅ 事务边界（Try/Confirm/Cancel）已用虚线框标记