Appearance
Day 05 - 事件风暴工作坊
📖 今日目标
- 理解事件风暴（Event Storming）的概念
- 掌握事件风暴的工作坊流程
- 学会用事件风暴发现领域模型
核心概念
什么是事件风暴？
事件风暴（Event Storming） 是由Alberto Brandolini发明的一种团队协作式领域建模方法，通过可视化方式探索复杂业务系统。
核心思想：
- 用"领域事件"作为发现业务逻辑的主线
- 快速发现模型、流程和边界
- 让业务专家和技术人员共同参与
关键要点
1. 事件风暴的参与者
| 角色 | 职责 |
|---|---|
| 业务专家 | 提供业务知识，验证事件准确性 |
| 开发者 | 技术实现可行性和模型设计 |
| 领域专家/DDD教练 | 引导讨论，记录模型 |
2. 事件风暴的步骤
第一步：发现领域事件
- 用橙色贴纸表示领域事件
- 格式：动词过去式（已下单、已支付、已发货）
- 让业务专家列举系统中的所有重要事件
第二步：识别命令
- 用蓝色贴纸表示触发事件的用户动作
- 格式：动词（下单、支付、取消订单）
- 连接命令到相应的事件
第三步：发现聚合
- 用黄色贴纸表示处理命令的实体
- 聚合是命令和事件的逻辑处理单元
第四步：识别限界上下文
- 用彩色边界线划分不同限界上下文
- 识别上下文之间的集成点
第五步：添加策略和规则
- 用紫色贴纸表示业务规则和约束
- 补充在事件和命令上的政策说明
3. 事件风暴的颜色约定
| 颜色 | 含义 |
|---|---|
| 橙色 | 领域事件 |
| 蓝色 | 用户命令 |
| 黄色 | 聚合 |
| 紫色 | 业务规则/策略 |
| 粉色 | 读模型/视图 |
| 绿色 | 外部系统 |
| 红色 | 问题/异常 |
4. 事件风暴的好处
- 快速：几个小时的研讨会可以得到完整领域图
- 包容：不需要技术背景，任何人都能参与
- 可视化：所有人看到同一张图
- 发现：自然暴露业务中的复杂点和问题
5. 事件风暴的输出
- 领域事件清单
- 命令与事件的对应关系
- 聚合和聚合根
- 限界上下文边界
- 关键业务规则
面试考点
问题1：事件风暴相比传统建模方法的优势是什么？
答案：
参与度高：
- 传统建模只有分析师参与
- 事件风暴让所有相关方共同参与
速度快：
- 传统OOA可能需要数周分析
- 事件风暴可以在几天内完成
可视化强：
- 所有人看到同一张大图
- 便于讨论和发现
自然发现边界：
- 通过事件和聚合自然识别限界上下文
- 而不是先入为主假设边界
暴露业务复杂性：
- 通过并行事件和冲突暴露业务复杂度
- 提前发现难以处理的场景
问题2：事件风暴中的领域事件应该如何命名？
答案：
领域事件命名的原则：
使用过去式：
OrderPlaced（订单已下单）PaymentReceived（支付已接收）ShipmentDelivered（货物已送达）
反映业务事实：
- 不是技术操作：
UserUpdatedProfile - 而是业务含义：
UserProfileChanged
- 不是技术操作：
包含关键信息：
OrderPaidWithCreditCard（携带支付方式）OrderCancelledDueToTimeout（携带取消原因）
避免动词歧义：
- ❌
OrderModified（修改了什么？） - ✅
OrderShippingAddressUpdated
- ❌
一个事件描述一个业务事实：
- 避免在一个事件中包含多个变化
实践思考
🎯 思考题：
以电商退货场景为例：
- 列出所有可能发生的领域事件
- 识别触发这些事件的命令
- 找出涉及的聚合
- 识别业务规则（如：超过30天不能退货）
📚 扩展阅读
- EventStorming.com
- 《事件风暴》- Alberto Brandolini
- Introducing Event Storming - Luca Marrone
📅 学习进度
| Day | 主题 | 状态 |
|---|---|---|
| 01 | DDD初识：什么是领域驱动设计 | ✅ |
| 02 | 战略设计：限界上下文与上下文映射 | ✅ |
| 03 | 战略设计：通用语言与领域建模 | ✅ |
| 04 | 战略设计：子域划分与核心域识别 | ✅ |
| 05 | 事件风暴工作坊 | ✅ |
| 06 | 实体（Entity）与标识 | ⬜ |
| ... | ... | ... |
| 30 | 复习与总结 | ⬜ |