事件风暴实战：六步法快速对齐业务理解，输出可落地的领域驱动设计方案

产品口中的“下单”，开发脑海里的“插入order表”，测试用例中的“验证状态流转”——他们描述的是同一件事吗？这种认知偏差，正是许多软件项目沟通成本高昂、频繁返工的根源。

一、需求沟通的三大困局

困局1：各说各话 产品经理评估需求“很简单”，但开发评审后发现需要联动修改4个Service，测试执行后报出一堆边界Bug，上线后运维监控到CPU使用率飙升30%。

困局2：反复返工 一个看似明确的需求，经过3轮沟通，开发出来的功能仍不符合预期，测试用例覆盖的也并非用户真实的使用场景。

困局3：新人难懂 新入职的工程师花了两个月时间，仍在通过阅读代码片段来反向推测业务逻辑，面对修改需求时不敢轻易动手。

这些问题的根本原因在于，团队中的不同角色使用着不同的“语言”描述同一件业务事实。

二、事件风暴：跨职能团队的通用语言

什么是事件风暴？ 它是一种高度协作的领域建模工作坊，通过可视化工具（如贴纸或在线白板），让业务专家、产品经理和研发团队快速对齐对业务的理解，建立统一的业务语言。

真实案例：医疗系统重构 一个拥有8年历史、涉及患者、医生、药品、医保等多方角色的复杂系统，面临的问题是：没有人能完整说清端到端的业务流程。通过组织一场事件风暴工作坊，团队在1天内发现了3处长期存在的错误业务规则，理清了7个子系统间的协作关系，并让所有参与者对核心流程达成了共识。

三、六步法实战操作指南

第一步：准备工作（30分钟）

• 物资准备：一面足够大的墙面，或使用Miro、Mural等在线协作工具。
• 五种颜色贴纸：
  • 🟠 橙色：领域事件（已发生的事实）
  • 🔵 蓝色：命令（触发事件的动作）
  • 🟡 黄色：聚合（有生命周期的业务对象）
  • 🟣 粉色：策略（业务规则或策略）
  • 🟢 绿色：视图（用户或系统需要查看的信息）
• 人员要求：业务专家和产品经理必须参加；核心开发、架构师、测试建议参加；并需一名有经验的主持人协调流程。

第二步：探索领域事件（60分钟） 核心问题是：“在我们的业务中，发生了哪些重要的事情？”

• 书写规范：使用过去时（例如：“商品已加入购物车”），避免进行时或命令式。
• 操作规则：
  1. 畅所欲言，想到什么写什么，先不考虑顺序。
  2. 一张贴纸只记录一个事件。
  3. 确保字迹够大，3米外清晰可辨。
  4. 暂不争论，对有疑问的事件先贴出来。

第三步：排序与梳理（30分钟） 将所有“橙色事件贴纸”按时间顺序排列，形成一条清晰的业务时间线。此过程常能暴露出：

• 缺失环节：两个事件之间缺少必要的中间步骤。
• 重复事件：不同描述实质上指向同一件事。
• 矛盾事件：业务逻辑上存在冲突。

实战案例：库存扣减时机

• 原有理解：订单创建 → 支付完成 → 扣减库存。
• 风暴后发现：订单创建 → 预留库存 → 支付完成 → 扣减/释放库存。 这一发现明确了库存预留机制，有效避免了超卖风险。

第四步：识别命令与角色（30分钟） 为每个“领域事件”寻找其触发者——“命令”。

• 命令格式：动词+名词（例如：“用户_加入_购物车”、“系统_创建_订单”）。
• 识别执行者：可能是用户、系统、管理员或第三方系统。

第五步：识别聚合与策略（45分钟）

• 识别聚合（黄色）：找出拥有生命周期和唯一标识的核心业务对象，如订单、用户、商品。
• 识别策略（粉色）：明确业务执行的规则或条件，如“VIP用户享受折扣”、“库存不足时无法下单”。

第六步：划分限界上下文（60分钟） 根据高内聚、低耦合的原则，将相关的聚合、事件、命令分组，形成独立的业务边界（限界上下文），这是后续进行微服务划分与架构设计的关键输入。

四、外卖平台实战推演

1. 探索核心领域事件

用户侧：餐厅已浏览 -> 菜品已加入购物车 -> 订单已创建 -> 支付已完成 -> 订单已取消 -> 订单已评价
餐厅侧：订单已接单 -> 菜品已开始制作 -> 订单已出餐
配送侧：骑手已接单 -> 骑手已到店 -> 骑手已取餐 -> 骑手已送达

2. 暴露关键问题

• 状态混乱：“用户取消”与“系统超时取消”未区分。
• 流程缺失：缺少“骑手已分配”关键事件。
• 异常不完整：未考虑“骑手取消配送”的异常流程。

3. 识别核心聚合

• 订单聚合：负责订单生命周期的状态管理与规则。
• 餐厅聚合：管理接单、菜品制作与出餐流程。
• 配送聚合：处理骑手调度、取送餐追踪。
• 用户聚合：维护用户信息、等级与权益。

4. 划分限界上下文

• 订单上下文：核心职责为订单创建、状态管理与支付。
• 餐厅上下文：负责接单决策、菜单管理与出餐。
• 配送上下文：专注于骑手调度、路径规划与配送追踪。
• 用户上下文：统一管理用户档案、地址与会员体系。

五、进阶技巧与常见问题

处理复杂业务规则：使用粉色“策略”贴纸明确记录业务规则，例如：“高峰时段配送费 = 基础费 × 1.5”、“距离超3公里每公里加2元”。

保证工作坊效率：

• 业务人员不参与：会前强调其“业务权威”的核心价值，鼓励他们只描述“是什么”，由其他人协助记录。
• 陷入技术细节：主持人需及时干预，引导大家聚焦业务事实，将技术方案放入“停车位”稍后讨论。
• 产出无法落地：明确产出物为“统一语言词典”、“事件列表”、“上下文映射图”及“待办事项”，并指定负责人与检查点。

六、核心产出与价值

一场成功的事件风暴工作坊，将直接产出以下可落地的成果：

1. 统一语言词典：明确定义“下单”、“支付成功”等核心术语的业务内涵。
2. 领域事件列表：梳理出完整的、按时间排序的业务事实流。
3. 上下文映射图：清晰地描绘出不同业务边界之间的协作关系。
4. 架构设计输入：为微服务拆分、数据库设计、API与消息契约定义提供坚实依据。

核心价值总结：

• 打破壁垒：建立跨角色的统一业务语言。
• 暴露真相：让隐藏的业务规则和流程矛盾提前浮出水面。
• 加速对齐：用数小时的高效协作替代数周反复的需求评审。
• 指导落地：直接从业务分析平滑过渡到可执行的系统设计。

最关键的是，它促使技术团队从被动的“需求实现者”转变为主动的“业务合作伙伴”。