事件风暴怎么做？用预约业务把领域事件、命令和争议画清楚

事件风暴适合解决一种常见分歧：业务人员讲“预约已成功”，研发理解为“申请已入库”，行政却认为“只有收到确认才算占用会议室”。先把业务中已经发生的事实按时间铺开，再讨论谁触发、依据什么规则、哪里仍有争议，比直接画接口或数据库表更容易发现语言错位。

可以用 Boardmix 的在线便签协作画布把这些不同说法放到同一处。下面围绕共享会议室预约，做出一条事件线、一段命令与规则关系，以及一份可继续追查的问题清单。

先约定讨论边界：从申请到会议结束

EventStorming 官方将其定义为共同探索复杂业务领域的灵活工作坊。它可以服务于业务梳理或软件设计；一次会议不必同时完成所有层次。第一次讨论预约业务，先回答“现在会发生什么”，不要急着决定“应该拆几个服务”。

本例邀请经常预约会议室的员工、行政管理者，以及了解预约系统的产品和研发人员。拿一笔普通预约、一笔取消预约、一笔预约成功却未到场的记录作材料；移除姓名和会议内容，只保留时间、房间、动作和结果。把“会议室设备采购”“办公楼门禁”先放在范围外，避免一条预约线扩成整个行政系统。

画布顶部写明边界：“某会议室从收到预约申请，到会议结束或预约失效。”右侧留一个暂存区，收下超出范围但有价值的问题。主持人负责让不同角色都能发言，不替业务角色直接裁定规则。

先贴事件，避免把意图写成结果

一张便签只写一个已经发生的业务事实。名称尽量让业务人员能判断其真伪，例如“预约申请已提交”“时段已确认”“预约已取消”。“确认预约”是想做的动作，“预约管理”是功能名称，都不能直接替代事件。

原说法	问题	可讨论的写法
预约成功	成功指申请收到，还是房间已锁定？	拆成“申请已提交”和“时段已确认”
取消预约	还没有说明动作是否生效	动作写“取消预约”，结果另写“预约已取消”
发送提醒	任务执行不等于接收成功	根据讨论目的区分“提醒已发出”和“提醒已送达”
会议室没人	观察来源和判断时点不清楚	暂记“未检测到签到”，再核查是否足以判定未到场

先让参与者分别补事件，再一起排序。正常路径可从“申请已提交→时段已确认→人员已签到→会议已结束”开始；取消、冲突和未签到不是必须发生的下一步，应放在相应位置的下方作为分支。事件名称相同但含义不同，先保留两张并写上各自解释，别为了整齐提前合并。

沿预约时间线讲一遍，找出真正的热点

请预约者从左到右讲述一笔预约。行政人员在自己开始介入的位置补充，研发指出系统实际记录的状态。每当出现“通常”“应该”“我们那边不是这样”，就把具体分歧记成热点：问题、已有说法、需要谁确认。热点的价值在于留下待查事项，不是把不同意见标成错误。

例如，申请人说“我取消后又决定开会，所以还是去签到”；行政说“取消就释放时段”；研发发现签到入口只检查预约编号。此时不要直接画出“签到成功”。在“预约已取消”和“人员已签到”之间标记热点：“取消后的预约能否签到？若时段已被别人占用，谁有权恢复？”这会引出当前规则和系统行为之间的差异。

同样，“未到场已释放”需要至少补两项条件：系统在何时判断未到场，用何种证据判断。本例先记录“预约开始后未签到”这一观察，至于宽限多久、是否允许行政延长，交由规则负责人确认。讨论结果不应凭空变成通用的十分钟释放规则。

选一段展开命令、执行者和规则

大图把主要事实讲通后，再选择“提交预约到确认时段”这一段深入。颜色只是辅助，图例必须写出类型，黑白打印后也要能辨别。下面是本次工作坊采用的卡片类型；配色可由团队约定，但应保留文字图例。

• 事件便签：写已经发生的事实，例如“时段已确认”。
• 命令卡：写请求执行的动作，例如“提交预约”“取消预约”；命令可能被拒绝，不能保证产生期望事件。
• 执行者标签：说明谁发起命令，例如申请人、行政人员或定时检查。
• 规则卡：写触发条件和后续动作，例如“预约有效且未签到时，进入到场检查”。
• 热点卡：记录尚未达成一致的规则或例外，并指定核查人。

一个可走读的局部是：申请人发出“提交预约”；系统依据“房间开放且时段可用”处理请求；符合条件产生“时段已确认”，不符合条件则产生可解释的拒绝结果。把规则写在命令与结果之间，读者才能看出为什么同一个动作会得到不同结果。

不要把每个事件都连成一条单线。有些行为独立发生，例如会议资料发送和设备准备未必互为前置条件。若要核查单个预约对象允许哪些状态变化，再另画状态转换与非法操作关系；事件风暴的大图不需要承担所有状态约束。

把争议带走：规则决定、待查证据与验收例子

结束前不以“贴满一面墙”为完成标准。至少选一处重要热点，写清谁查、查什么、什么结果可以关闭。事件风暴官网的验收例子提取方法也强调：在流程形成后，可用具体输入和预期行为继续消除歧义。

热点	要补的依据	可执行的下一步
取消后是否允许签到	行政规则、取消后重新分配记录	行政确认规则；研发补“取消后签到”的验收例子
两个人同时申请同一时段	实际冲突处理方式和反馈内容	产品定义一人确认、一人拒绝时各自看到什么
未签到能否自动释放	签到可靠性、人工例外处理	行政确认判断条件；先补日志再讨论自动化

对“取消后签到”可写出这样的验收讨论稿：给定预约已取消且该时段已分配给另一申请人，当原申请人提交签到时，不应恢复原预约，并应得到明确原因。它仍需业务负责人确认；图上的连线本身不能替代规则批准或测试执行。

最后保留事件线、图例和热点负责人，把已确认规则与待确认规则分开。下一次讨论从未关闭的热点继续。等业务语言稳定，再据此整理流程、接口或边界，避免把第一次工作坊中尚在争论的便签直接固化成系统设计。