1. 事件风暴概述
1.1 事件风暴的起源
事件风暴（Event Storming）是由 Alberto Brandolini 于 2013 年提出的一种协作式、基于工作坊的建模技术。它最初诞生于对传统需求分析会议低效、文档驱动、业务与技术脱节等痛点的反思。Brandolini 观察到，当领域专家与开发团队围坐在大量便签纸前，共同“风暴”出系统行为时，知识传递的损耗被降到最低，模型的质量和共识度显著提升。
核心理念： 事件风暴不是一种建模语言，而是一种 建模仪式。它通过时间线、事件流和角色扮演，让隐性的业务知识显性化，从而快速捕获领域全景。
1.2 核心概念
事件风暴工作坊围绕五个核心构建块展开，它们构成了领域建模的通用语言。下表总结了每个概念的定义、符号（便签颜色）及在微服务设计中的角色：
| 概念 | 便签颜色 | 定义 | 微服务设计中的角色 |
|---|---|---|---|
| 事件（Event） | 橙色 | 发生在过去、不可改变的事实。例如：“订单已支付”、“库存已扣减”。 | 微服务间异步通信的核心载体；定义服务边界和最终一致性契约。 |
| 命令（Command） | 蓝色 | 用户或系统发起的一个意图或请求，可能导致事件发生。例如：“提交订单”、“支付订单”。 | 定义微服务的 API 接口（输入）；触发聚合状态变更的入口。 |
| 聚合（Aggregate） | 黄色 | 一组具有内聚关联的实体和值对象的集合，通过聚合根保证数据一致性。例如：“订单聚合”包含订单、订单项、支付信息。 | 微服务内部的最小业务单元；一个微服务通常包含多个聚合，但事务边界在聚合内。 |
| 限界上下文（Bounded Context） | 大框/边界线 | 一个显式的语义边界，内部有统一的领域模型和通用语言。例如：“订单上下文”与“库存上下文”使用不同的“商品”模型。 | 微服务划分的直接依据；一个限界上下文对应一个或多个微服务。 |
| 角色（Actor） | 小黄人/粉色 | 触发命令的人或外部系统。例如：顾客、支付网关、管理员。 | 识别微服务的用户角色和外部依赖。 |
关键原则： 事件风暴强调“事件优先”。先找出所有业务事件，再反向推导出触发事件的命令、执行命令的角色以及维护状态的聚合。这种逆向思维能有效避免过早陷入实现细节。
1.3 事件风暴在微服务设计中的价值
事件风暴为微服务架构设计提供了从业务到技术的完整映射路径，其核心价值体现在以下四个维度：
- 快速发现业务全景： 通过 2-4 小时的工作坊，团队可以覆盖核心业务流程的完整事件流，避免遗漏关键业务场景。
- 精准划分服务边界： 限界上下文是微服务划分的最优粒度。事件风暴通过识别事件流中的“断裂带”（即上下文切换点），自然导出微服务边界。
- 建立通用语言（Ubiquitous Language）： 业务专家与开发团队共同命名事件、命令和聚合，消除沟通中的术语歧义，确保代码与业务模型一致。
- 驱动事件驱动架构（EDA）： 橙色事件直接映射为消息队列中的领域事件，为微服务间的异步解耦提供蓝图。
下图展示了事件风暴核心概念如何映射到微服务架构的典型分层：
常见误区： 不要试图在事件风暴工作坊中直接设计数据库表或 API 接口。事件风暴的目标是 探索业务，而非 设计技术方案。技术细节应在后续的“聚合设计”和“服务契约”阶段完成。
1.4 事件风暴工作坊的典型流程
一个标准的事件风暴工作坊通常遵循以下步骤，团队规模建议为 6-12 人：
- Step 1 - 混沌探索： 在时间线上贴出所有橙色事件，不讨论对错，只求全面。
- Step 2 - 时间线排序： 将事件按业务发生的时间顺序排列，识别出“事件流”的主干。
- Step 3 - 添加命令与角色： 为每个事件贴上触发它的蓝色命令和粉色角色。
- Step 4 - 识别聚合： 在命令和事件之间，用黄色便签标出维护状态的聚合。
- Step 5 - 划定限界上下文： 用粗笔画出边界线，将紧密关联的事件、命令、聚合圈在一起，形成上下文。
- Step 6 - 识别热点与问题： 用红色或紫色便签标记业务痛点、约束或待决策项。
下图展示了事件风暴工作坊中便签的典型布局与协作关系：
实践建议： 第一次开展事件风暴时，建议使用物理便签和墙面。物理交互的触感、移动便签的灵活性以及面对面的讨论氛围，是远程数字白板难以完全替代的。当团队成熟后，可迁移到 Miro、MURAL 等工具进行分布式协作。