商品供给域完整事件风暴（Event Storming）清单

目录

[一、Event Storming 的组织方式说明](#一、Event Storming 的组织方式说明)

[二、商品供给域的事件全景地图（Big Picture）](#二、商品供给域的事件全景地图（Big Picture）)

（一）什么是"事件全景地图"

[（二）为什么商品供给域需要 Big Picture 级 Event Storming](#（二）为什么商品供给域需要 Big Picture 级 Event Storming)

[（三）商品供给域 Big Picture 的组织方式](#（三）商品供给域 Big Picture 的组织方式)

（四）按子域划分的事件来源视角

[（五）Big Picture 中的"事件时间轴"视角](#（五）Big Picture 中的“事件时间轴”视角)

[（六）Big Picture 对架构设计的直接指导意义](#（六）Big Picture 对架构设计的直接指导意义)

[（七）Big Picture 与后续细化 Event Storming 的关系](#（七）Big Picture 与后续细化 Event Storming 的关系)

三、核心域事件清单

[（一）总店商品管理子域（Product Domain）](#（一）总店商品管理子域（Product Domain）)

领域聚合

核心领域事件

[典型命令 → 事件](#典型命令 → 事件)

[（二）门店商品管理子域（Store Product Domain）](#（二）门店商品管理子域（Store Product Domain）)

领域聚合

核心领域事件

典型策略（Policy）

[（三）价格子域（Pricing Domain）](#（三）价格子域（Pricing Domain）)

领域聚合

核心领域事件

典型策略

[（四）库存子域（Inventory Domain）](#（四）库存子域（Inventory Domain）)

领域聚合

核心领域事件

典型策略

四、支撑域事件清单

[（一）质量子域（Quality Domain）](#（一）质量子域（Quality Domain）)

领域聚合

领域事件

典型策略

[（二）标签子域（Tag Domain）](#（二）标签子域（Tag Domain）)

领域聚合

领域事件

五、通用域事件清单

[（一）变更通知子域（Notification Domain）](#（一）变更通知子域（Notification Domain）)

事件类型

[（二）操作日志子域（Audit Domain）](#（二）操作日志子域（Audit Domain）)

领域事件

六、事件设计的统一规范（强烈建议）

（一）事件命名规范

（二）事件结构建议

[七、如何用这份清单做 Event Storming 工作坊](#七、如何用这份清单做 Event Storming 工作坊)

九、总结：这份清单的真正价值

---

干货分享，感谢您的阅读！

在商品供给体系中，绝大多数系统问题并不是技术能力不足，而是业务认知不一致被直接固化进了代码和数据结构。

在实际项目中，常见的冲突包括：

• 商品"发布"在不同系统中含义不同

• 上架 / 下架 / 禁售的边界模糊

• 价格、库存、门店商品之间存在隐式依赖

• 一个字段的变更，会引发多个系统"被动兜底"

这些问题在早期可能并不明显，但随着业务复杂度提升，会逐渐演化为：

• 大量 if / else 规则

• 难以回溯的数据状态

• 不敢改、不敢删、不敢重构的核心逻辑

Event Storming 的价值，正是在系统设计早期，将"业务事实"从实现细节中剥离出来，用统一的领域语言，把商品供给域中真实发生的事情完整呈现出来。

对于商品供给域而言，Event Storming 并不是"锦上添花"的建模手段，而是：

一种将"商品是如何被创建、发布、售卖、治理"的业务运行方式

以事件时间线的形式彻底摊开、对齐、固化的核心方法。

我们尝试将基于 Event Storming 方法，对商品供给域进行完整的事件全景拆解，并明确每一类事件在系统中的位置、边界与协作方式。

一、Event Storming 的组织方式说明

在商品供给域中，我们采用 Big Picture + Process Level Event Storming 的结合方式，事件按以下层级展开：

• 领域事件（Domain Event） ------ 已发生的业务事实

• 命令（Command） ------ 触发行为的意图

• 聚合（Aggregate） ------ 事件的产生者

• 策略 / 反应（Policy / Saga） ------ 跨子域协作逻辑

• 外部系统事件（Integration Event）

本文以领域事件为主线，辅以命令和策略说明。

二、商品供给域的事件全景地图（Big Picture）

（一）什么是"事件全景地图"

在 Event Storming 中，Big Picture 并不是事件清单的简单汇总，而是一张回答以下问题的全局地图：

• 商品供给域中，哪些事情是真正重要的业务事实？

• 这些事实按什么时间顺序发生？

• 它们由谁产生，又影响了谁？

对于商品供给域来说，这张地图的核心价值在于：

把"商品供给是如何运转的"从系统视角，转化为业务视角下的一条完整事件时间轴。

（二）为什么商品供给域需要 Big Picture 级 Event Storming

商品供给域具有几个天然特性，使其非常不适合直接从数据模型或接口设计入手：

1. 跨子域协作极多

   商品、门店、价格、库存、质量、标签并非线性流程，而是网状协作。

2. 状态变化远多于实体数量

   同一个商品，在生命周期内可能经历数十次状态变更。

3. 下游系统极其敏感

   任何一次商品变更，都可能影响交易、搜索、营销、风控等系统。

在这种背景下，如果没有一张 Big Picture 事件图：

• 各子域只能"各自为政"

• 事件会被设计成"技术事件"而非"业务事实"

• 最终形成以接口为中心、而非以业务为中心的系统

（三）商品供给域 Big Picture 的组织方式

在商品供给域中，我们按子域 + 事件流向的方式组织 Big Picture，而不是按系统或服务。

整体结构如下：

这五个阶段不是严格的业务流程，而是从事件时间线上抽象出的认知分层。

（四）按子域划分的事件来源视角

从 DDD 边界 看，商品供给域的 Big Picture 事件分布如下：

这里非常关键的一点是：

没有任何一个子域"主导"整个商品生命周期，它们只是各自在时间线上贡献事件。

（五）Big Picture 中的"事件时间轴"视角

如果将所有子域的事件放到同一条时间轴上，商品供给域的运转方式可以被抽象为：

这里要特别强调：

• 事件不是流程节点

• 事件是已经发生的事实

• 流程是事后从事件中"读"出来的，而不是反过来

（六）Big Picture 对架构设计的直接指导意义

这张事件全景地图，会直接影响以下设计决策：

• 微服务 / 子域拆分边界：哪些事件必须在同一个聚合内产生，哪些事件天然是跨子域协作点
• 数据一致性策略：哪些事件需要强一致，哪些事件允许最终一致
• 下游系统接入方式：搜索 / 推荐订阅哪些事件，营销系统监听哪些状态变化
• 演进与重构成本：新业务场景 = 新事件，而不是改老表，新系统 = 订阅事件，而不是侵入核心域

（七）Big Picture 与后续细化 Event Storming 的关系

在实际落地中，Big Picture 通常用于：

• 架构级共识建立

• 子域边界确认

• 事件命名统一

在此基础上，才进入：

• Process Level Event Storming（某个具体业务场景）

• Design Level Event Storming（聚合、命令、约束）

换句话说：

Big Picture 是"全域地图"，后续是"局部战术图"。

原则：

• 一个子域 = 一组事件源

• 事件命名统一采用 过去时 + 领域语言

三、核心域事件清单

（一）总店商品管理子域（Product Domain）

领域聚合

• Product

• SKU

核心领域事件

事件名称	含义
ProductCreated	商品已创建
ProductUpdated	商品基础信息已变更
ProductPublished	商品已发布
ProductUnpublished	商品已下架
ProductDeleted	商品已删除
SKUCreated	SKU 已创建
SKUUpdated	SKU 已更新
SKUEnabled	SKU 已启用
SKUDisabled	SKU 已禁用
ProductCategoryChanged	商品分类已变更
ProductRelationChanged	商品关联关系已变更

典型命令 → 事件

• CreateProduct → ProductCreated

• PublishProduct → ProductPublished

（二）门店商品管理子域（Store Product Domain）

领域聚合

• StoreProduct

• StoreSKU

核心领域事件

事件名称	含义
StoreProductCreated	门店商品已生成
StoreProductActivated	门店商品已上架
StoreProductDeactivated	门店商品已下架
StoreProductBlocked	门店商品已禁售
StoreProductInfoUpdated	门店商品信息已更新
StoreSKUActivated	门店 SKU 已启用
StoreSKUDeactivated	门店 SKU 已停用
StoreProductCategoryChanged	门店商品分类已调整

典型策略（Policy）

• 当 ProductPublished 发生时

  → 触发 CreateStoreProduct

  → 产生 StoreProductCreated

（三）价格子域（Pricing Domain）

领域聚合

• PriceConfig

• PricePublish

核心领域事件

事件名称	含义
PriceConfigured	价格已配置
PriceUpdated	价格已调整
PricePublished	价格已生效
PriceExpired	价格已失效
PriceFollowed	跟价规则已生效
PriceCalculationFailed	价格计算失败

典型策略

• SKUEnabled → 初始化价格配置

• StoreProductActivated → 校验价格是否生效

（四）库存子域（Inventory Domain）

领域聚合

• Inventory

• InventoryReservation

核心领域事件

事件名称	含义
InventoryInitialized	库存已初始化
InventoryIncreased	库存已增加
InventoryDecreased	库存已扣减
InventoryReserved	库存已锁定
InventoryReleased	库存已释放
InventoryFrozen	库存已冻结
InventoryUnfrozen	库存已解冻
InventoryShortageDetected	库存不足已识别

典型策略

• StoreSKUActivated → InventoryInitialized

• InventoryShortageDetected → 触发补库存策略

四、支撑域事件清单

（一）质量子域（Quality Domain）

领域聚合

• QualityRule

• QualityResult

领域事件

事件名称	含义
QualityRuleConfigured	质量规则已配置
QualityRuleUpdated	质量规则已更新
ProductQualityCalculated	商品质量已计算
ProductQualityDegraded	商品质量评分下降
ProductQualityRecovered	商品质量评分恢复

典型策略

• ProductUpdated → 重新计算质量

• 质量下降 → 通知门店商品子域限制售卖

（二）标签子域（Tag Domain）

领域聚合

• Tag

• TagAssignment

领域事件

事件名称	含义
TagDefined	标签已定义
TagAssigned	标签已打标
TagRemoved	标签已移除
TagRuleExecuted	标签规则已执行
TagGoverned	标签已治理

五、通用域事件清单

（一）变更通知子域（Notification Domain）

该子域不生产业务事实，只消费并再分发事件

事件类型

事件名称	含义
DomainEventReceived	接收到领域事件
ChangeNotificationSent	变更通知已发送
NotificationFailed	通知失败

（二）操作日志子域（Audit Domain）

领域事件

事件名称	含义
OperationLogged	操作日志已记录
OperationLogQueried	操作日志被查询

六、事件设计的统一规范（强烈建议）

（一）事件命名规范

• 使用 过去时

• 使用 领域语言

• 不携带技术细节

✅ StoreProductActivated

❌ UpdateStoreProductStatus

（二）事件结构建议

{
  "eventId": "uuid",
  "eventType": "StoreProductActivated",
  "occurredAt": "2026-01-01T10:00:00Z",
  "aggregateType": "StoreProduct",
  "aggregateId": "SP123",
  "version": 3,
  "payload": {
    "storeId": "S001",
    "productId": "P1001"
  }
}

七、如何用这份清单做 Event Storming 工作坊

建议步骤

1. 先铺 领域事件（橙色）

2. 再补 命令（蓝色）

3. 明确 聚合（黄色）

4. 标注 策略 / Saga（紫色）

5. 标出 系统边界（虚线）

备注：请按自身实际内容进行排兵布阵即可。

九、总结：这份清单的真正价值

这份「商品供给域事件风暴清单」的价值在于：

• 把隐式业务规则显式化

• 把系统耦合转化为事件协作

• 为微服务拆分、异步架构、数据治理提供统一语言

它不是"事件列表"，而是商品供给域的业务运行说明书。