5.1 事件风暴工作坊全程实录

5.1 事件风暴工作坊全程实录

本节摘要：事件风暴（Event Storming）是一场让业务专家与开发围着白板共同铺陈"业务里发生过什么"的协作工作坊。本节完整还原青柚商城第一次事件风暴：会前怎么选人备料定题、四个阶段各做什么、两次冷场与一次跑偏怎么处理、最后产出什么。它是全册唯一一篇以"会议纪要"形态写成的章节——因为工作坊这种东西，看一遍别人的全过程比自己读十遍定义有用。

一场工作坊的完整记录

14:00，三楼大会议室。 墙上贴了一整面长纸（没有长纸就拼三张白板），桌上三摞便利贴：橙色一大摞（写领域事件）、淡紫色一小摞（写命令）、黄色一摞（写角色与疑问）。到场十四人：运营主管、两位资深客服、一位财务专员、交易组四人、仓储组两人、架构师与技术负责人。手机统一进筐——这是主持人事先说明的唯一纪律。

为什么是这些人：工作坊的成败七成押在名单上。原则有三条——每个相关上下文必须有"每天摸这个业务"的人（两位客服比客服总监有用）；必须有能当场拍板规则的人（运营主管）；开发者以听与问为主，不负责表演技术方案。上次兄弟团队的工作坊失败复盘就一条：来了八个开发一个业务，铺了三小时"系统应该有什么功能"，没铺出一条"业务发生过什么"。

工作坊墙面布局与推进方向

第一阶段：铺事件（14:00–14:50）

主持人开场只用了一分钟："我们不放幻灯片。规则一条：往墙上贴便利贴，每张写一件业务里已经发生完的事，过去时，比如'订单已创建'。随便贴，不用管顺序，看不懂别人贴的就直接问。"然后是十分钟的安静——每次工作坊都有这个阶段，别慌。

第一个开口的是资深客服小陈："退款里有一种情况，货还没退回来，钱就先退了，叫先行赔付，这个贴什么？"主持人把笔递过去："你写。"小陈贴上"赔付已先行"，顺手补了一句"不过要运营审批过才行"。这句话值回整场票价——"先审批后赔付"这条前置规则，系统里的实现一直是错的：代码把审批放在赔付后，靠人肉不触发来兜底。铺事件的本质就是这样：不问系统做什么，问世界发生了什么，系统做错的地方会自己撞出来。

五十分钟里墙上贴了六十七张橙色便签，包括五张重复的（"支付已到账"贴了三次，三种叫法：收款成功、已支付、到账——2.1 的词汇表当场多了一条整改项）。

第二阶段：理时间线（14:50–15:20）

第二阶段把便签按时间排序，左端是业务起点。排序本身就是建模：两张"库存已预留"与"支付已到账"谁先谁后，当场引发交易组与仓储组的第一场争论——系统里实际是"先扣库存再等支付"，客服们的直觉是"钱到了才算交易成立"。争论没有胜负，但暴露的事实进了红色疑问贴："支付超时后预留的库存谁释放？多快释放？" 这个问题后来演化成 6.4 里 Saga 补偿的主案例。

阶段推进流程

第三阶段：找命令与角色（15:20–15:50）

淡紫色的命令贴这一阶段才发——命令是"什么触发了事件"："提交结算"触发"订单已创建"，"拣货完成"触发"已出库交接"。每个命令旁边贴黄色角色贴：用户、客服、系统定时器、仓储员。这一步的价值在 5.2 会兑现：命令是聚合方法名的直系来源（提交结算变 submit，拣货完成变 complete），角色是命令权限的来源。

本阶段的经典时刻来自财务专员："你们的'支付已到账'跟我记的账对不上，你们算到账的时点是什么？"——交易组答"支付渠道回调"，财务说"我按银行流水日切"。又一条 2.1 式的定义域分歧当场显形，两句话谈定：财务订阅事件按自己的日切口径记账，不强求同一步调，跨上下文一致性的议题又添一条。

第四阶段：标痛点与圈边界（15:50–16:30）

最后半小时做两件事。标痛点：把全场冒出的红色疑问贴归类，当天归出九个，其中"优惠叠加口径""库存释放时限""报文时点"三个被评定为"每次需求都吵架"级别。圈边界：主持人拿粗笔在时间线上试着画圈——语言分岔的地方（订单的三种含义）就是圈的边界候选。当天画了四条圈线，与 2.2 后来定稿的地图已经八九不离十。要强调：工作坊不产出最终地图，产出的是边界候选与待谈判清单——谈判在会后一节一节继续，别指望三小时解决一切。

两次冷场的处理：第一次在开场十分钟，靠"递笔"破解（把写便利贴的主动权交给业务方，而不是请开发念系统设计）；第二次在理时间线中段，靠主持人抛具体案例破解（"上个月那笔砍价单走哪条线？"具体案例比抽象提问更能唤醒记忆）。

一次跑偏的拉回：第三阶段交易组一位工程师开始争论"表结构该怎么设计"，主持人把话题钉回便签墙："今天的墙只回答业务发生过什么，表结构是墙的下游。"工作坊的刹车时机有三：开始评审具体技术方案（拉回便签）、变成需求排期会（宣布另开）、来了拍不了板的人导致规则悬而不决（记红贴收场，别硬谈）。

收场后的七十二小时

工作坊的价值有一半取决于收场后三天内的动作，这条纪律常被忽略。当天晚上：主持人把墙面拍照归档，按时间线整理成电子便签文档——拖过三天，便签墙会被下一场会议拆掉，记忆也随之过期。第二天：把九条红贴与四个边界候选圈群发给全体与会者确认，重点请业务方纠错——"我没说过这话"比遗漏更伤信任。第三天内：召开一小时的后续谈判排期会，只做一件事——给每条红贴指定谈判时间与谈判双方。红贴没有去处，工作坊就会退化成一次性的团建；红贴全部排上了期，这场会才算真正结束。青柚九条红贴里，"优惠叠加口径"与"库存释放时限"排进了下周，它们后来分别长成了 3.5 的聚合争议与 6.4 的 Saga 补偿——工作坊的产出物是种子，七十二小时决定种子落在土里还是落在桌上。

带走的判断

• 名单决定成败：每个上下文带"每天摸业务"的人，带拍板的人，开发只带耳朵和问题。
• 事件用过去时、写事实不写功能——系统做错的地方会在"世界发生了什么"面前自己撞出来。
• 工作坊产出三样：时间线、命令角色清单、痛点与边界候选；最终地图与最终规则都在会后谈判里，别贪一场定音。
• 冷场靠递笔、靠具体案例；跑偏靠钉回便签墙；涉及排期与技术方案一律另开会。

便利贴下墙之后怎么活进代码？5.2 讲模型与代码之间的双向反馈——那才是模型驱动设计的正身。