4. 识别领域事件（下）：事件风暴工作坊实操——从核心业务流程开始，逐步覆盖支撑子域，使用不同颜色便签区分事件类型
在上一节中，我们建立了领域事件的理论基础与识别原则。本节将进入实战环节：通过事件风暴工作坊，从核心业务流程切入，逐步向支撑子域扩展，并利用不同颜色的便签（或数字白板中的色块）对事件类型进行视觉化区分。
4.1 工作坊准备：角色、物料与空间布局
一次成功的事件风暴工作坊需要明确的角色分工与充足的物理/数字物料。建议按以下标准配置团队与工具：
| 角色 | 人数建议 | 职责 |
|---|---|---|
| 领域专家 | 2-4 人 | 提供核心业务知识，验证事件真实性 |
| 技术架构师 | 1-2 人 | 引导技术可行性讨论，记录边界上下文 |
| 产品经理 | 1-2 人 | 澄清需求优先级，确认事件触发条件 |
| 记录员 | 1 人 | 拍照、整理便签、维护在线白板 |
| 引导师 | 1 人 | 控制节奏，提问“然后发生了什么？” |
物料清单： 橙色便签（领域事件）、蓝色便签（命令/触发动作）、绿色便签（外部系统/角色）、红色便签（热点/问题）、黄色便签（聚合/实体）。准备一面至少 4 米长的空白墙或数字白板（如 Miro、Mural）。
4.2 从核心业务流程开始：时间线风暴
工作坊的第一步是聚焦于核心域。以电商订单系统为例，引导师带领团队从“用户下单”这个起点开始，沿着时间线向右推进，每发生一个业务状态变化就贴一张橙色便签。
核心流程事件识别步骤：
- 定义起点： 用户提交购物车（触发命令）。
- 识别第一个事件： “订单已创建”。
- 追问“然后呢？”： 系统校验库存 → “库存已锁定”。
- 继续推进： 支付网关回调 → “支付已确认”。
- 直到终点： 物流发货 → “订单已签收”。
以下 SVG 展示了核心流程中事件与命令的交互关系：
4.3 逐步覆盖支撑子域
核心流程的事件识别完成后，团队需要将视野扩展到支撑子域。支撑子域通常包括：通知服务、积分系统、审计日志、推荐引擎等。这些子域的事件往往由核心域事件间接触发。
扩展策略：
- 事件传播： 核心域事件“支付已确认”会触发支撑子域事件“积分已累计”。
- 异步响应： “订单已签收”触发“满意度调查已发送”。
- 补偿事件： 当核心流程失败时，支撑子域产生“库存已释放”事件。
实践要点： 在支撑子域的事件识别中，使用紫色便签表示外部系统集成事件（如“物流单号已回传”），使用绿色便签表示定时触发事件（如“每30分钟同步一次对账文件”）。这有助于在后续微服务拆分时明确事件来源。
4.4 颜色便签分类标准
为了在视觉上快速区分事件类型，我们建立以下便签颜色编码体系。该体系将在整个工作坊中严格执行：
| 便签颜色 | 事件类型 | 示例 | 微服务影响 |
|---|---|---|---|
| 橙色 | 核心领域事件 | 订单已支付、库存已锁定 | 通常对应聚合根状态变更 |
| 紫色 | 外部集成事件 | 物流轨迹已更新、银行回执已接收 | 需要定义防腐层（ACL） |
| 绿色 | 定时/批处理事件 | 每日对账文件已生成、会话超时 | 可能引入调度微服务 |
| 红色 | 异常/补偿事件 | 支付超时已触发、库存回滚 | 需要 Saga 或流程管理器 |
| 黄色 | 用户行为事件 | 用户已浏览商品、评论已提交 | 通常用于 CQRS 的读模型 |
4.5 实操案例：从核心到支撑的事件覆盖
以下 SVG 展示了在一个电商系统中，核心流程事件如何向支撑子域辐射，并形成完整的事件网络：
4.6 工作坊产出物与后续步骤
经过 2-4 小时的工作坊，团队应产出以下关键交付物：
- 事件时间线： 覆盖核心域与至少 3 个支撑子域的完整事件流。
- 事件分类矩阵： 按颜色分类的事件清单，标注触发命令与响应动作。
- 热点/问题列表： 红色便签记录的不确定点或技术债务。
常见陷阱： 避免过早陷入技术细节（如数据库字段设计）。工作坊的目标是发现“发生了什么”，而不是“如何实现”。如果团队开始讨论 API 参数或表结构，引导师应立即拉回时间线。
完成事件识别后，下一阶段将进入聚合与限界上下文的划分。届时，这些带有颜色标记的事件便签将成为确定微服务边界的主要依据。