🧩 一、事件风暴结果的典型构成
一次完整的事件风暴通常会产出以下几类信息：
| 类型 | 示例 | 含义 |
|---|---|---|
| 领域事件 (Domain Event) | 订单已创建、支付完成 | 系统中发生的业务事实 |
| 命令 (Command) | 创建订单、确认支付 | 用户或系统的行为意图 |
| 聚合 (Aggregate) | 订单、用户、商品 | 管理业务状态与规则的核心模型 |
| 外部系统 / 参与者 (Actor/System) | 支付网关、库存系统 | 与本系统交互的外部要素 |
| 策略/流程 (Policy/Process) | “支付完成后触发发货” | 事件响应逻辑或业务规则 |
事件风暴的核心价值是：让事件流串联起各领域边界。
🧭 二、从事件风暴到架构的映射步骤
1️⃣ 步骤一：识别领域边界与限界上下文 (Bounded Context)
每个“领域聚集”的事件序列，可归入一个上下文（Context）。
例如在一个电商事件风暴中：
- 用户注册、登录相关事件 →
用户上下文 - 订单创建、支付、发货等事件 →
订单上下文 - 积分计算、优惠券使用 →
营销上下文
这些上下文将成为架构中的服务单元（可能是微服务、模块或限界组件）。
2️⃣ 步骤二：定义上下文间的交互
交互通常体现为 事件流或命令调用，对应系统中的：
- 异步事件总线（Kafka、RabbitMQ 等）
- RESTful API / gRPC 调用
- Saga / Event-Driven Orchestration 流程
例如：
订单上下文(Order Context)
↓ 触发事件 → [支付完成事件]
支付上下文(Payment Context)
↓ 响应事件 → [发货指令]
物流上下文(Shipping Context)
通过这些交互，可以逐步显现系统架构中的依赖关系。
3️⃣ 步骤三：映射到技术架构层级
将业务上下文映射到常见的三层或微服务架构中：
| 层级 | 内容 | 技术实现 |
|---|---|---|
| 接口层 (API Layer) | 接收命令 | Spring Boot Controller、NestJS Controller |
| 应用层 (Application Layer) | 协调业务用例 | Service、CommandHandler |
| 领域层 (Domain Layer) | 封装领域逻辑 | Entity、Aggregate、Repository |
| 基础设施层 (Infrastructure Layer) | 外部依赖 | DB、消息队列、远程调用 |
这些定义帮助从“业务语言”过渡到“工程实现语言”。
4️⃣ 步骤四：绘制架构图
以下是一个示意图，将事件风暴结果映射为服务及事件流：
graph LR
U[用户上下文] -->|创建订单| O[订单服务]
O -->|发布事件: 订单已创建| P[支付服务]
P -->|触发事件: 支付完成| L[物流服务]
O -->|监听事件: 支付完成| L
L -->|更新订单状态| O
subgraph MessageBus[事件总线]
end
O -.-> MessageBus
P -.-> MessageBus
L -.-> MessageBus
🧠 解读：
- 各上下文（用户、订单、支付、物流）对应微服务。
- 它们之间通过 事件总线 异步通信。
- 事件名称直接继承自事件风暴的便利贴结果，语义一致。
5️⃣ 步骤五：补充系统视角（非功能需求）
事件风暴主要关注业务，但架构转化时还要考虑：
| 维度 | 示例 | 对应设计 |
|---|---|---|
| 数据持久化 | 订单表、事件溯源表 | MongoDB / PostgreSQL / Event Store |
| 通信模式 | 异步事件 → Kafka；同步接口 → REST/gRPC |
