-
前言：为什么需求文档越写越乱？
- PM、后端、前端、测试对于“业务事件”的理解完全不同
- 大型系统需求复杂度不是写代码难，是“搞清楚到底发生了什么难”
- 事件风暴是“大型业务建模的终极武器”
-
事件风暴的核心思想
- Everything is an Event
- 不从功能开始，而从“发生了什么”开始
- 以事件驱动领域边界的识别
-
事件风暴全过程（实战版）
- 领域事件贴纸上墙（Event）
- 指令（Command）分析
- 聚合（Aggregate）识别
- 热点与瓶颈发现
- 系统边界（Bounded Context）划分
- 事件之间的因果链路
-
在复杂中国式业务中的实际作用
- 审批流
- 订单业务
- 财务结算业务
- 营销业务（优惠券、权益）
- 内容审核业务
-
事件风暴产出物
- 领域事件时间线
- 聚合根草图
- 边界上下文划分图
- 风险点清单
- 技术方案输入
-
实战案例：年中计划调整 / 项目申报流程事件风暴
- 从混乱需求 → 清晰 domain 视图
- 如何帮后端构建稳定的状态机模型
- 如何减少 if/else 地狱
-
总结
- 事件风暴不是技术，是沟通模型
- 它能让团队在复杂需求前保持统一认知
- 任何复杂系统的重构，都应该从事件风暴开始
