4. 事件风暴画布基础：起源、角色与工作坊流程
事件风暴（Event Storming）由 Alberto Brandolini 于 2013 年提出，是一种基于协作的、高度互动的建模方法。它通过将领域专家、开发人员、产品经理等角色聚集在同一面“墙”前，使用彩色便签纸快速探索业务全貌，识别核心领域事件、命令与聚合。在《OAuth2.0 集成下的分布式事务事件风暴画布安全架构》课程中，事件风暴是连接安全策略与分布式系统设计的核心桥梁。
4.1 事件风暴的起源与核心理念
事件风暴的诞生源于对传统需求分析“信息漏斗”的反思。Brandolini 观察到，从业务专家到开发人员的需求传递过程中，大量上下文与业务规则丢失。事件风暴通过以下原则解决该问题：
- 时间线驱动：以“事件”作为时间轴上的锚点，描述系统“发生了什么”。
- 大规模协作：所有利益相关者同时参与，消除信息孤岛。
- 物理空间优先：使用实体墙、便签纸和马克笔，降低建模门槛，提升参与感。
- 探索而非设计：初期不关注技术实现，只关注业务行为与规则。
课程提示： 在 OAuth2.0 集成场景中，事件风暴特别适合用来发现“令牌颁发”、“授权码交换”、“刷新令牌”等关键业务事件，以及这些事件触发的分布式事务边界。
4.2 核心角色与彩色便签语义
事件风暴使用不同颜色的便签纸代表不同的建模元素。下表总结了五种核心角色及其在安全架构上下文中的映射：
| 角色 | 便签颜色 | 定义 | OAuth2.0 安全上下文示例 |
|---|---|---|---|
| Domain Event | 橙色 | 发生在过去、不可改变的业务事实。通常使用过去时态命名。 | AccessTokenIssued、RefreshTokenRevoked、AuthorizationCodeExchanged |
| Command | 蓝色 | 用户或系统发起的意图，触发一个事件。通常使用祈使句命名。 | IssueAccessToken、ValidateClientCredentials、ExchangeAuthorizationCode |
| Aggregate | 黄色 | 一组领域对象的集合，保证业务不变量的执行边界。是事务一致性的最小单元。 | ClientApplication、UserSession、AuthorizationGrant |
| Policy | 紫色 | 当某个事件发生时，自动触发另一个命令或事件的业务规则。 | 当 RefreshTokenExpired 时，触发 RevokeRefreshToken 命令 |
| External System / Actor | 粉色 | 与系统交互的外部角色或系统，通常是人或第三方服务。 | 资源拥有者（用户）、授权服务器、资源服务器 |
关键区别： Command 是“想要做什么”，Domain Event 是“已经做了什么”。在分布式事务中，Command 可能失败，而 Domain Event 一旦发布，即代表不可变的事实。
4.3 事件风暴工作坊流程
一个标准的事件风暴工作坊通常分为四个阶段，每个阶段都有明确的产出物。以下流程适用于 OAuth2.0 集成场景的建模：
- 混沌探索（Chaotic Exploration）
- 目标：快速收集所有可能的 Domain Event，不讨论细节。
- 活动：参与者自由地在墙上贴橙色便签，描述“系统发生了什么”。
- 产出：一面贴满橙色便签的墙，覆盖从“用户发起登录”到“令牌过期”的完整生命周期。
- 时间线排序（Timeline Sorting）
- 目标：将混沌的事件按时间顺序排列，形成从左到右的时间线。
- 活动：集体讨论事件的前后依赖关系，移动便签位置。
- 产出：清晰的时间线，暴露出事件之间的因果链。
- 命令与聚合识别（Command & Aggregate Identification）
- 目标：为每个事件找到触发它的 Command，并定义执行 Command 的 Aggregate。
- 活动：在事件左侧贴上蓝色 Command，在事件上方贴上黄色 Aggregate。
- 产出：形成“Command → Aggregate → Event”的基本建模单元。
- 边界与策略发现（Boundary & Policy Discovery）
- 目标：识别聚合之间的边界（即分布式事务边界），并定义跨边界的 Policy。
- 活动：用紫色便签标记 Policy，用粗线画出聚合边界。
- 产出：包含聚合边界、事件流和自动触发规则的事件风暴画布。
4.4 事件风暴画布与分布式事务的映射
在分布式系统中，一个 Aggregate 对应一个事务边界。事件风暴画布上的每个黄色便签（Aggregate）都代表一个需要保证强一致性的数据范围。跨聚合的操作必须通过最终一致性（如事件驱动）来实现。下表总结了画布元素与分布式事务概念的对应关系：
| 事件风暴元素 | 分布式事务概念 | OAuth2.0 集成示例 |
|---|---|---|
| Aggregate | 本地事务边界 / 聚合根 | ClientApplication 聚合保证客户端凭证的唯一性 |
| Domain Event | 不可变消息 / 事件溯源日志 | AccessTokenIssued 事件记录令牌颁发事实 |
| Command | RPC 调用 / 服务请求 | ValidateToken 命令调用资源服务器验证接口 |
| Policy | Saga 协调器 / 事件处理器 | 当 RefreshTokenExpired 时，Policy 触发 NotifyUser 命令 |
| 聚合边界 | 微服务拆分边界 | 授权服务器与资源服务器之间的边界 |
安全架构注意： 在 OAuth2.0 集成中，
AuthorizationCode 的消费必须在一个 Aggregate 内完成（强一致性），而令牌的撤销通知可以跨聚合通过事件传播（最终一致性）。错误地将撤销逻辑放在同一个 Aggregate 内会导致不必要的锁竞争。
4.5 在 OAuth2.0 集成中的实践建议
- 从令牌生命周期开始：先列出所有与令牌相关的事件（颁发、刷新、撤销、过期），再补充客户端注册、用户授权等外围事件。
- 明确聚合边界：
AuthorizationGrant（授权码）和AccessToken（访问令牌）应作为独立的聚合，因为它们具有不同的生命周期和一致性要求。 - Policy 驱动自动化：使用 Policy 描述“令牌过期后自动刷新”或“授权码使用后自动失效”等规则，这些规则在分布式系统中通常由事件处理器或 Saga 协调器实现。
- 安全事件不可忽略：在事件风暴中，务必包含安全相关事件，如
InvalidClientCredentialsDetected、TokenReplayAttempted，这些事件是安全审计和威胁建模的基础。