事件风暴工作坊：构建清晰领域模型与合理微服务拆分的指南

目录

一、事件风暴：把业务讲成一串已经发生的事实

（一）一卷纸上的方法

1、以“事件”而不是“名词”为起点

2、所有人同时在场

3、用空间代替文字

（二）事件风暴的三个层次

1、大图景探索

2、流程建模

3、软件设计

（三）便利贴的颜色与语法

1、八种元素

2、一条完整的语法

3、为什么坚持用过去式

（四）事件风暴在领域驱动设计中的位置

二、事件风暴的准备工作

（一）事件风暴的参与者

1、该请哪些人

2、人数与分组

3、引导者的职责

4、警惕“一锤定音”的人

（二）事件风暴要准备的材料

1、纸卷与便利贴

2、笔、胶带与其他小物件

3、远程工作坊的替代方案

（三）事件风暴的场地

1、一面足够长的墙

2、撤掉椅子

3、留出“停车场”

（四）事件风暴分析的关注点

1、明确范围与目标

2、时间盒与议程

3、会前访谈与预读

4、关注什么，不关注什么

三、利用事件风暴构建领域模型

（一）产品愿景

1、为什么从愿景开始

2、愿景板怎么写

3、愿景如何指导后续取舍

（二）业务场景分析

1、混乱探索

2、强制排序与关键事件

3、逆向叙事：补齐命令、角色与策略

4、外部系统与读模型

5、热点收敛

6、墙面体检

（三）领域建模

1、第一步：从命令和事件中提取实体

1.1 圈出命令与事件背后的名词

1.2 实体还是值对象

1.3 同一个名词，不同的身份

2、第二步：寻找聚合根，组合聚合

2.1 聚合是一致性边界

2.2 聚合设计的四条规则

2.3 邻里鲜的聚合清单

2.4 实测：聚合边界就是一致性边界

3、第三步：划定限界上下文

3.1 划界的五条线索

3.2 邻里鲜的九个上下文与子域分类

3.3 上下文映射

（四）微服务拆分与设计

1、限界上下文是逻辑边界，不等于部署边界

2、四种拆分方案的量化比较

2.1 按使用端拆踩中了红线

2.2 拆得最细不等于最好

2.3 粗粒度看起来最省事，代价在后面

2.4 推荐的折中

3、服务内部：分层与端口

4、服务之间：事件契约与发件箱

5、渐进演进：从模块化单体开始

四、事件风暴常见问题分析

（一）事件的粒度如何判定？

1、太粗与太细

2、四个判定问题

3、先求覆盖，再求精确

（二）对某个事件有歧义如何处理？

1、歧义的两种形态

2、五步处理法

3、歧义往往是边界在说话

（三）领域模型周围的事件过多怎么办？

1、聚合是不是太大了

2、是不是混进了两个上下文

3、是不是把查询和通知当成了事件

（四）成员完全不熟悉业务怎么办？

1、会前：预读与亲身体验

2、会中：让一线讲故事，从结果倒推

3、混编小组，降低门槛

（五）没有领域专家怎么办？

1、寻找代理专家

2、把猜测写成假设

3、用访谈与数据闭环验证

五、工作坊之后：让墙上的模型活下去

（一）当天收尾

（二）数字化与事件目录

（三）上下文画布

（四）让模型进入代码，并持续校准

六、总结

参考链接

干货分享，感谢您的阅读！

一个做社区团购的团队，需求评审会开了整整一下午：六十页的需求文档逐页过，产品讲、开发听、测试记，大家都点了头。三周以后联调，问题一个接一个冒出来——截团那一刻还有人在付款，这单算不算参团？成团失败后谁来发起退款，是订单系统、支付系统，还是那个谁都不想认领的定时任务？“订单已完成”这个状态，财务、客服和团长理解的根本不是同一件事。代码已经写了一大半，这些问题才第一次被摆到桌面上。

这样的场景并不少见。复杂业务里的知识分散在不同人的脑子里：团长运营知道团长怎么想，采购主管知道几点截单最划算，客服主管知道哪些售后最难缠，而开发手里只有一份经过层层转述的文档。真正上线运行的，不是领域专家的知识，而是开发对这些知识的理解。理解偏了，代码就偏了。

事件风暴（EventStorming）要解决的正是这个问题。它不靠写更厚的文档，而是把所有相关的人请到一面墙前，用一卷白纸和几种颜色的便利贴，把业务讲成一串按时间排开的“已经发生的事实”。在这个过程里，误解会被当场看见，分歧会被当场贴出来，领域模型和服务边界会从墙上自己“长”出来。

本文以一个虚构但足够真实的社区团购平台「邻里鲜」为线索，完整推演一场两天的事件风暴工作坊：从准备工作（人、物、场地、焦点），到产品愿景与业务场景分析，再到实体、聚合、限界上下文的领域建模，最后落到微服务拆分与演进。为了让结论不只停留在“经验之谈”，文中配了两个可运行的 Java 程序：一个把墙面记录成数据，对初稿做“体检”、对四种拆分方案做量化比较；另一个用虚拟时间仿真 300 人争抢 100 份限量商品，检验“聚合边界就是一致性边界”这句话到底意味着