先说个实在话很多团队做领域建模第一步就栽在“不知道从哪里开始”。业务人员讲的是“上架”“补货”“退货”这些日常词技术人员听到的是“商品表”“库存表”“状态字段”两边鸡同鸭讲。我经历过好几次这种拉锯之后才彻底倒向事件风暴Event Storming这套玩法。尤其是把范围圈定在“商品供给域”这种横跨商品、库存、采购、供应商多个环节的复杂业务域时事件风暴几乎是当前性价比最高的领域建模启动方式。这篇文章我就以“商品供给域完整事件风暴清单”为线索把我在实际项目中拆解供给域的全过程、完整事件清单、建模落地的关键经验以及踩过的坑一次讲清楚。不管你是准备带一场工作坊的架构师还是正在做商品系统重构的技术负责人这篇文章能帮你省掉至少一周的试错时间。1. 为什么选事件风暴来拆解商品供给域1.1 商品供给域的复杂性和事件风暴的适配性先聊一个本质问题商品供给域到底难在哪里。很多人以为难在“数据量大”“并发高”实际上这些都不是核心难点。真正让团队难受的是这个领域的业务概念在不同角色眼里是完全不同的东西。同样是“商品”运营口中的商品是SPU标准产品单元仓库眼中的商品是SKU库存量单位采购眼里的商品又是供应商的供货条目。同样是“库存”在ERP里是账面库存在电商前台是可售库存在仓库里又是实物库存三者之间的转换关系能把刚入行的开发绕晕。这就是典型的多限界上下文交织场景。而事件风暴恰好擅长处理这种“概念混乱”。它的核心逻辑很简单让所有干系人围着一面墙用橙色便签写“已经发生过的事实”把业务的全过程按时间顺序铺开。这个方法不讨论系统怎么实现只讨论业务真实发生了什么。当所有人在同一面墙上看到“商品已创建”“商品已审核”“商品已上架”这些事件时很多争论自然就消失了因为事实就是事实再怎么争货确实是通过这些步骤走到前台的。事件风暴尤其适合供给域还有另外一个原因这个域的事件驱动特征极其明显。商品状态流转、库存增减、采购单状态变化天然就是一串离散事件。把这些事件流梳理清楚领域模型的骨架就自动浮现了聚合怎么划、服务怎么拆、数据怎么放都有迹可循。相比之下传统的ER图建模或者用例分析法在供给域这种“状态多、动作多、角色多”的领域里模型建到一半往往就崩了因为讨论很容易滑入“这个字段放哪张表”的细节里。1.2 事件风暴能给项目带来什么实际产出在真正实操之前先给大家一个预期管理明确一场事件风暴做完你手里应该有哪些东西这样后面参与时就不会跑偏一张覆盖整个业务域的事件时间线上面有所有已经发生过的业务事实这是后续建模的地图一份规范的事件清单每个事件有标准命名、触发来源、携带的关键数据这是需求评审和开发排期的基础一组聚合与限界上下文的初步划分能直接指导微服务或者模块的拆分一张业务与系统之间的映射表哪些事件对应哪个命令、哪个外部系统边界清清楚楚。这里面事件清单是最容易被低估的产物。很多团队做完工作坊墙上的便签拍照存档就完事了后续开发时又回到拍脑袋模式。正确的做法是把墙上的事件沉淀成文档并且把事件命名、触发链路、数据载荷都标准化这份清单就是后续所有设计的锚点。我后面会用一整节给大家列一份商品供给域的完整事件清单可以直接抄作业。2. 事件风暴工作坊的完整准备与执行流程2.1 前置准备人员、物料、目标设定一场成功的事件风暴七分靠准备三分靠现场。很多人不重视前置准备拉一群人找个会议室就开始贴便签结果不是跑题就是吵成一锅粥。根据我做过的项目准备阶段有三件事必须做扎实。第一件事是确定工作坊的具体目标。注意目标不能是“梳理供给域业务”这种大而空的话必须拆到可交付的程度。比如“梳理商品从创建到下架全过程的事件流产出事件清单和聚合初稿”“理清库存域和商品域的边界确定库存快照的归属方”。目标越具体工作坊的范围越容易控制也不容易在某个技术方案上纠缠太久。第二件事是约对的人。商品供给域涉及的角色通常包括商品运营负责商品上下架和生命周期、采购或供应链人员负责采购和供应商协同、仓库管理人员负责入库出库、客服或售后了解异常情况、后端开发商品、库存、交易、采购各一个代表。有个很容易犯的错是把所有开发都叫过来其实开发代表一两个人就够反而业务角色不能缺席。有一回我组织工作坊商品运营临时请假结果现场讨论到“预售商品什么时候可售”时整个团队编了一套错误逻辑后来开发做完才知道和运营规则完全违背白白返工。第三件事是物料准备和空间布置。事件风暴的标准物料为长墙面或大块白板纸建议至少5到8米长时间线长了才知道墙大的好处、多种颜色的便签纸、粗头马克笔、美纹纸胶带。颜色约定建议提前打印贴出来避免现场反复解释。我常用的颜色规则是橙色代表领域事件已经发生的事实、蓝色代表命令用户或系统的动作请求、绿色代表读模型查询/展示、黄色代表角色或外部系统、粉色代表业务规则或问题点。空间上建议使用U型座位保证大家都能看到墙面而不是一排一排的教室型。2.2 五阶段引导从混沌到有序事件风暴的现场执行大体上分成五个阶段顺序很重要乱跳会破坏节奏感。第一阶段发散时间线。让业务人员自由地把橙色事件贴到墙上不用管顺序对错也不用讨论合理性。这个阶段的核心是“量”事件越全越好。我一般会限定时间比如60分钟内把大家知道的事件都贴出来。注意不要让技术人员在这个阶段发问“这个事件的数据结构是什么”这类问题会立刻冻结现场氛围。第二阶段整理事件顺序。所有人一起看墙上的橙色便签把散乱的事件按时间轴排好删掉重复的补充明显缺失的。操作上有一个小技巧先找几个“锚点事件”比如“商品首次上架”“采购单审核通过”“入库完成”这些是整个时间线的骨架其他事件围绕锚点前后排列。第三阶段添加命令和角色。围绕每个领域的橙色事件问一个问题“谁做了什么动作才导致了这个事件发生”答案写在蓝色便签上放在事件的左边。同时用黄色便签标注角色或系统。比如“商品已上架”的左边是蓝色命令“运营点击上架按钮”对应的黄色角色是“商品运营”。这一步做完事件与命令之间的触发关系就清晰了。第四阶段标注读模型和外部依赖。读模型是绿色便签代表某个业务环节需要看到什么数据。外部系统用黄色便签特别标注比如“ERP系统”“配送系统”。这个阶段能让团队意识到哪些事件其实是外部系统发来的哪些数据需要从别的系统同步。第五阶段识别聚合与问题点。这是最烧脑的阶段。团队需要对每个事件打上“唯一ID”的判断讨论哪些事件属于同一个聚合。同时把不确定、有争议的地方写粉色便签贴在对应位置作为后续专项会议的话题。多轮工作坊时粉色的最终会渐渐减少当绝大多数问题点被击破后领域模型自然清晰。2.3 现场引导技巧与时间控制做过引导的人都知道现场最容易失控的不是讨论激烈而是“沉默”。业务人员不习惯用便签表达或对技术和流程术语怯场现场就容易变成几个技术骨干的自嗨。我的做法是开场先做一个小练习让每个人匿名写一个自己负责环节的事件贴到墙上再一起看气氛一热后面就顺了。时间控制上可以使用番茄钟节奏。实际经验是一场3小时的工作坊前60分钟做发散和排序中间50分钟做命令和角色最后40分钟做聚合与问题点梳理剩余时间用于回顾和拍照归档。很多团队的第二个误区是做完一场就觉得完事了。商品供给域这么大一次性覆盖全部子域会严重超时。我的习惯是拆成3到4场按子域拆商品主数据一场、采购与供应商协同一场、库存与履约一场。各个场次之间留出间隔方便上一场的结果被消化也方便补充参会人员。3. 商品供给域核心事件清单完整事件流直接抄作业下面这份事件清单是我在多个供给域项目中沉淀整理出来的。它不是某个特定公司的产物而是一个相对通用参考版本适合大多数电商或零售类系统。实际使用时请以团队工作坊现场产出为准这里提供的是对照性参考。3.1 商品主数据生命周期的核心事件商品主数据是整个供给域的起点所有后续环节都围绕“商品”展开。这个子域的事件围绕“创建、审核、上架、下架、淘汰”展开并且要特别注意“SPU”“SKU”两级结构带来的事件层级问题。商品创建阶段的事件商品草稿已创建运营填写基础信息此时尚未提交审核商品资料已提交草稿提交至审核环节商品审核已通过审核人员确认信息无误商品可进入后续状态商品审核已驳回审核未通过通常需要附上驳回原因商品信息已修改基本信息变更可能触发重新审核商品销售状态相关事件商品已上架商品在前端可售商品已下架手动下架或活动结束自动下架商品已禁售因合规或资损风险紧急下架和普通下架是两套逻辑商品已删除逻辑删除通常有严格的资损校验前置条件这里有一个实操中的教训很多团队会把“商品已下架”和“商品已禁售”合并成一个事件用字段区分。这在系统实现上看着省事但领域模型会被慢慢拖垮因为下架和禁售的触发方、前置校验、后续处理差异很大。前者是经营决策后者通常是风控或合规触发强行用一个事件表达后续哪怕只是增加一个“禁售需通知审核员”的需求代码都无处安放。二级链路还有“商品库存已设置”或“库存模板已同步”这类事件用于连接商品域与库存域。注意这个事件在事件风暴里就该被识别为“系统间集成事件”后面落地时大概率会走MQ消息而不是直接改库。3.2 供给与入库环节的核心事件商品没货可卖一切都是空谈。供给域的核心动作是“采购→到货→入库→库存增加”这条链路。这里的事件要特别区分“采购业务事件”和“仓库执行事件”它们经常被混在一起是领域边界模糊的重灾区。采购与供应商协同相关事件采购需求已创建系统根据库存预警或运营手动发起采购单已提交正式发给供应商采购单已完成供应商确认供应商回传确认采购单已入库完结到货入库后采购单状态终结供应商已发货供应商侧通知往往通过外部系统对接商品到货已登记仓库收到货品后记录仓库入库执行相关事件到货预报已提交供应链通知仓库即将到货仓库提前准备库位商品已收货仓库实际收到商品件数核对通过质检已通过是否需要质检根据商品类目策略自动判断质检已驳回有问题的商品被拒收商品已上架到库位这一步完成后商品才真正“可销售”有件事务必在事件风暴中搞明白在上面的链路中“供应商已发货”是外部事件由供应商系统推送而“仓储已收货”是仓储系统内部事件。它们之间存在时间差和数量差。这个差异如果不在事件清单里显式表达后续做采购回告时就容易把“供应商说的发货数”当作“仓库实际收货数”对账就会永远对不平。3.3 库存与履约协同的核心事件库存子域是整个供给域中事件最密集、也最需要谨慎处理的区域。可售库存、物理库存、在途库存、锁定库存、占用库存各种口径的库存及其相互转换构成了一系列高频且关键的事件。宏观库存事件库存已增加入库完成后触发库存已扣减订单下发后扣减库存已锁定用户下单但未支付时的预占也可称为“预留”库存已释放超时未支付或用户主动取消导致锁定的库存释放库存已调整人工盘点修正或运营人工调整库存已同步库存数据同步到搜索、推荐等下游系统库存事件里最常见的一个坑就是“扣减时机”。在事件风暴时你要明确问清楚“锁库存”和“扣库存”是不是同一个动作。有的公司是下单锁库存、支付成功才正式扣减有的是下单直接扣。这个决策直接决定“库存已锁定”和“库存已扣减”两个事件在时间线上如何出现也决定中间态的库存数据如何展示给前端用户。要反复和业务确认不要想当然。另外库存子域的“实销与账面差值”的账实相符率也是一个经常涌现讨论的主题。盘点、报损等事件虽不频繁但在建模中不能缺否则库存数据出错就缺失了纠错链路。3.4 供应商与结算关联事件供给域的尾部是一系列与供应商相关的管理事件。许多团队在事件风暴时容易忽略这段导致后续结算模块和供应商管理系统各自为政。核心事件包括供应商入驻申请已提交供应商资质已审核通过供应商已签署合作协议供应商资质已过期供应商已暂停合作供应商已终止合作供应商结算单已生成供应商账单已确认供应商账单已支付一个容易被忽略的关联事件是“供应商绩效已评分”。这个事件通常会周期触发但许多人不会把它放进供给域的模型里。实际上它在后端的选品决策和采购策略中非常关键。如果事件风暴时漏掉它后续做智能选品或供应商分级时就会发现自己缺少一条完整的数据链路。3.5 系统间集成与外部依赖事件供给域不可能独立运转它必然与交易域、财务域、物流域等多个外部系统交互。事件风暴中建议用黄色贴纸单独标出“外部系统”相关的事件这对后续的集成设计和接口规划帮助极大。常见的外部依赖事件这些事件的命名最好加上来源系统前缀避免模糊订单创建消息已接收来自交易域支付成功消息已接收来自交易域出库单已同步至物流平台发往物流域物流轨迹已同步来自物流域用于库存或售后判断结算流水已推送至财务系统在事件风暴现场团队往往会发现某些外部事件从未被ping过。比如如果一个系统中“订单创建”只是通过直接调用订单服务接口实现而没有使用消息队列那“订单已创建”这个事件其实是隐式的并不存在真正意义上的事件。此时便需要业务和技术现场拍板是否补齐外部事件这一步的决策会影响后续系统的扩展性与可靠性值得花时间认真确认。4. 从事件清单到领域模型落地过程中的实操经验事件风暴做到“墙上贴满”只是第一步真正考验功力的是把这些产出落到代码和系统设计里。这一步做得不好事件风暴就成了“大型团建活动”。下面几个经验是踩过坑才总结出来的今天直接分享出来。4.1 事件命名的“动词过去式”规范与边界情形事件命名是事件风暴最容易忽略细节的地方而它恰恰是长期维护的核心痛点。规范是“动词过去式”例如“商品已上架”“库存已扣减”“采购单已审核通过”。这个规则能一秒钟区分“命令”和“事件”命令是祈使句“上架商品”“扣减库存”事件是完成时“商品已上架”“库存已扣减”。这不仅仅是语法洁癖当你在代码注解中检索事件名时过去式命名能帮你立刻确认“这件事已发生数据状态已变成这样”。边界情形有几个值得讨论。第一个是“已审核通过”这种复合状态事件尽量拆成“商品已提交审核”“审核已通过”等单点事件避免语义重叠。第二个是“人工介入类”事件例如“库存已人工调整”应该保留完整语义避免变成“库存已变更”这种无主事件。第三个是“系统异常事件”如“库存扣减失败”它不是业务事件而是系统事件建议单独分类不要在领域事件中混入技术术语。命名的一个实用检查原则是事件名应该是一个领域专家也认可的客观事实。如果你把事件名念给业务人员听对方一脸茫然说明这个名字更像是开发起的内部黑话需要重命名。4.2 聚合边界与限界上下文的划分思路聚合是事件风暴的高潮部分也是分歧最多的地方。一个常见争议是商品和库存是否属于同一个聚合答案几乎永远是“不属于”。商品主数据变更是低频事件库存变动是高频事件二者更新频率差着一两个数量级放同一个聚合会导致锁竞争和性能灾难。更合理的关系是商品聚合持有SKU定义库存聚合持有每个SKU的库存数量二者通过SKU ID关联通过消息事件通知变化。另一个容易出问题的聚合是“采购单”和“入库单”。很多ERP的失败设计就是这里出了问题。从业务一致性来看它们更像是两个聚合通过“到货批次”或“采购单号”关联。因为一个采购单可以分多次入库如果把入库记录挂在采购单聚合内部入库子项的独立生命周期就被锁死了后续做部分退货或部分对账时很快就会写出“一个聚合里塞了太多实体”的上帝聚合来。正确的做法是独立“入库单”聚合内部保存一个“sourceOrderId”字段指向采购单。限界上下文也需要在事件风暴之后认真梳理。实际操作中商品主数据、库存、采购、供应商管理可以分别看作独立的限界上下文。判断依据是语言是否通用、内部变化是否独立。比如“供应商”在采购上下文里是“供货主体”在财务上下文里是“结算主体”两边的属性和行为差异很大混在一起是两个上下文互相污染拆开反而清爽。4.3 把事件风暴产出映射到代码的实践路径事件风暴结束到写代码之间存在一道经典的裂缝。很多人墙上的事件和代码中的实现没有对应关系工具墙归工具墙代码归代码。要避免这种割裂有一个比较务实的落地顺序第一步把事件清单转为领域事件类。每个事件一个类建议继承同一个领域事件基类携带事件ID、发生时间、业务主键如SKU ID、JSON payload。事件命名保持与墙上的便签一致不要换英文就“自由发挥”。第二步把聚合划分落实为模块边界。一个限界上下文对应一个Java模块/maven模块/微服务。聚合在这个模块内以“实体值对象”实现聚合的对外暴露尽量只走应用层命令方法内部状态更新后apply领域事件。第三步建立事件与消息的映射。跨上下文的领域事件通过MQ发布同一个上下文内部领域事件可以通过Spring的DomainEventPublisher或Event Bus先行同步处理。这里建议把“领域事件发布”的代码放入独立的发布器不要和业务代码纠缠避免测试时难以剥离。第四步用事件风暴地图做回归验证。代码写完后再回到墙边对着事件时间线走一遍业务全流程。某一事件无法重现就说明代码中的触发链路没打通。这个过程对查漏补缺极其有效我称之为“事件风暴反向验收”能给团队带来极高的确定性提升。5. 常见问题与排查技巧实录事件风暴做了多场几乎所有团队都会踩到一些共性坑。这里整理成速查表并附上我的实际处理建议。5.1 高频问题速查表典型问题常见原因建议解决方案业务专家不开口氛围紧张、对流程不熟悉先做匿名写便签的破冰练习明确说明“活动中没有正确与错误答案”事件数量庞大时间线失控范围太大、目标不聚焦收窄目标或拆子域一场只做“商品生命周期”而非“整个供给域”技术细节跑偏开发追问底层数据结构、接口设计引导师充当“刹车角色”可把涉及技术的细节写入问题便签留待后续专项会聚合划分争论陷入僵持大家站在不同业务立场讨论引入“变化频率”视角高频与低频尽量避免在同一聚合中远程工作坊效果差协作工具使用不熟练、缺少现场感用支持多人便签协作的白板工具并安排主持人分区整理适当延长发散时间做完无后续产出被遗忘未指定产出物负责人工作坊结束当天就定事件清单owner明确整理录入和跟进计划事件命名不规范现场节奏太快大家随手写引导师注意抽查命名并用统一颜色贴纸予以标注事后集中规范化5.2 远程/异步事件风暴的注意事项远程场景下事件风暴的难度会明显提升最大的损失是现场那种“视线聚焦同一墙面”的共享注意氛围。但远程也有一个意外好处不同时区的业务专家可以参与异步协作这也是必要的补偿。远程工具推荐使用支持多人实时协作的白板个人体感较好的是Miro和Boardmix。关键技巧是必须把“颜色约定”做成图例放在画板右上方持续可见因为远程没有物理环境中的“那张打印纸”。另外远程发散阶段建议每个参会人先在个人区域贴便签然后汇总到共享区这样可以减少从众效应也能防止第一个说话的人带偏全场。远程事件风暴的时间节奏也略有不同。建议每场不超过2小时中间休息10分钟。因为远程持续盯屏比线下更累信息吸收效率下降得更快。如果事件量大可把发散和排序拆成两场进行中间留半天消化时间。5.3 后续演化从事件风暴到事件溯源/消息驱动当团队把供给域的事件清单梳理清晰后一个自然的诱惑是“要不要用事件溯源实现”这里我需要泼一盆冷水。事件溯源是一种存储模式事件风暴是一种需求分析方法两者没有必然绑定关系。大多数供给域业务并不需要事件溯源用传统的关系型数据库保存最新状态同时把重要事件通过MQ异步通知下游已经能覆盖绝大多数场景。真正值得考虑事件溯源的场景是审计要求极高、历史状态重建是刚需、聚合内事件数量可接受。比如库存操作记录和供应商结算记录如果需要完整审计链路事件溯源或至少事件日志保存是有价值的。如果只是普通电商系统即使事件风暴梳理出了清晰的事件流也不建议直接上ES架构复杂度和运维成本可能会超出预期。另外一个值得延伸的方向是消息驱动的改造。事件清单里标出的“系统间集成事件”就是后端进行去强依赖化改造的重要抓手。比如“商品已上架”这个域事件通过MQ发布后下游搜索服务和推荐服务各自订阅消费这就能将原先后台上架操作中的同步推送逻辑拆走。事件风暴的工作成果可以为这种架构演进提供非常精确的切入点。从我开始使用事件风暴到熟练应用于商品供给域最大的感受是这个方法并没有多玄乎它本质上是一种“让事实自己说话”的建模方式。只要你能控制住现场节奏把事件清单和聚合边界认真沉淀下来后面的设计和开发都会顺畅得多。如果你正准备在供给域做一次业务梳理或系统重构我建议你先在项目组里拉一场3小时的小范围事件风暴热身按本文的流程走一遍做完你就知道自己手里这张“完整事件清单”值多少钱了。