一条时间轴上的商品供给：商品供给域事件全景、八大子域事件清单与事件契约规范的工程推演
目录
一、商品供给为什么需要一张事件地图
（一）商品供给体系里的四类典型冲突
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 万个