目录一、商品供给为什么需要一张事件地图（一）商品供给体系里的四类典型冲突1、同一个词，几种意思2、状态边界模糊3、看不见的依赖4、被动兜底（二）分歧是怎样一步步固化进系统的（三）从名词模型转向事件时间轴（四）这份清单的组织方式二、商品供给域的事件全景地图（一）什么是事件全景地图（二）为什么商品供给域需要全景级的事件风暴（三）全景地图的组织方式：时间轴、泳道与关键事件（四）按子域划分的事件来源：一个事件只有一个户口（五）事件时间轴视角：商品一生的七个阶段（六）全景地图对架构设计的直接指导意义1、泳道就是候选的服务边界2、跨泳道的箭头就是异步消息3、一个聚合内强一致，跨泳道最终一致4、跨子域的查询交给读模型（七）全景地图与后续细化事件风暴的关系三、核心域事件清单（一）总店商品管理子域1、领域聚合2、核心领域事件3、典型命令到事件4、“发布”一词的消歧4.1 四种“发布”4.2 收敛方案（二）门店商品管理子域1、领域聚合2、核心领域事件3、上架、下架与禁售的状态机4、典型策略（三）价格子域1、领域聚合2、核心领域事件3、价格的两条时间线4、典型策略（四）库存子域1、领域聚合2、核心领域事件3、售罄不等于下架4、典型策略四、支撑域事件清单（一）质量子域1、领域聚合2、领域事件3、一次召回会传导到哪里4、典型策略（二）标签子域1、领域聚合2、领域事件3、两种来源与一个陷阱五、通用域事件清单（一）变更通知子域1、三种“事件”的分工2、事件类型与投递链（二）操作日志子域1、操作日志不是领域事件2、领域事件与高危告警六、事件设计的统一规范（一）事件命名规范1、四条命名规则2、常见反例与改法（二）事件结构建议1、信封与载荷2、携带状态，而不只是增量（三）顺序、幂等与版本号1、消息通道不保证你以为的顺序2、仿真：五种视图更新策略3、从数字里读出的四个结论4、落到代码上的消费端模板（四）事件的演进与兼容七、用这份清单开一场事件风暴工作坊（一）清单是种子，不是答案（二）四轮工作坊的节奏（三）跨域走查的四个剧本1、新品引入2、全国调价3、批次召回4、门店闭店（四）产出物与验收：给事件目录做一次体检八、总结：这份清单的真正价值参考链接干货分享，感谢您的阅读！在零售、电商和本地生活这几类业务里，商品是几乎所有系统都绕不开的锚点：交易要用它下单，营销要拿它算券，供应链要按它补货，履约要靠它拣货。也正因为人人都要用，商品供给体系往往是最早长成“大泥球”的地方。一个常见的误判是把这归因于技术——表设计不够灵活、缓存没用好、消息中间件选得不对。可只要把几次线上事故的复盘记录摊开来看，就会发现大多数问题与技术能力关系不大，真正的病根是：业务认知不一致，被直接固化进了代码和数据结构。商品“发布”在商品中心、门店系统和渠道系统里各有各的含义；上架、下架、禁售的边界说不清；门店商品能不能卖，悄悄依赖着价格、库存和质量，却没人把这层依赖写下来；改一个字段，五个系统连夜打补丁。这些问题在业务量小的时候看不出来，规模一上来就会长成大段的 if/else、追不回来的数据状态，以及一套谁都不敢动的核心逻辑。在同一系列里，我们已经用领域驱动设计把商品供给域拆成了核心域、支撑域和通用域三类、八个子域，回答了“边界在哪里”。这篇文章接着往下走一步，回答“边界之内到底发生了什么，边界之间又靠什么协作”。抓手就是事件风暴（Event Storming）：先在一条时间轴上铺出商品供给的事件全景，再按八个子域逐一整理聚合、事件、命令和策略，然后把事件的命名、结构、版本与幂等收敛成统一规范，最后说明怎样用这份清单去组织一场工作坊，又怎样用程序给清单做体检。为了让讨论落在实处，我们用一个虚构的连锁零售企业“青禾鲜市”作为贯穿案例：一个总店（总部商品中心），320 家门店，约 3 万个