Event Sourcing领域事件拆分咨询：产品事件如何合理拆分？

核心原则：事件要语义化，而非按字段数量拆分 #

事件的本质是记录业务动作，而非单纯的字段变更。拆分的关键是让每个事件对应一个明确的业务操作，而不是为每个字段单独创建事件（除非字段的变更本身就是独立的业务动作）。

针对你的产品聚合场景的具体方案 #

1. 注册阶段：拆分核心事件与补充事件

原有的ProductRegistered携带全量字段的问题在于，一旦聚合属性新增/移除，旧事件的结构与新聚合类不兼容，导致恢复时抛出异常。正确的做法是：

• 保留ProductRegistered，但只包含注册动作必须的核心字段（比如productId、必填的name），用于初始化聚合的基础状态。
• 注册时的可选字段（description、image link等），如果是注册流程中明确的操作，生成对应的补充事件，比如ProductDescriptionSet、ProductImageLinkAdded。
• 这些事件需要原子性提交到事件存储，确保注册流程的完整性。

示例事件序列（注册时）：

ProductRegistered { productId: "prod-123", name: "无线耳机" }
ProductDescriptionSet { productId: "prod-123", description: "蓝牙5.3，续航24小时" }
ProductImageLinkAdded { productId: "prod-123", imageLink: "https://example.com/prod-123.jpg" }

2. 更新阶段：废弃通用ProductUpdated，改用语义化事件

通用的ProductUpdated会模糊业务动作，且同样面临结构变更的兼容性问题。应该为每个独立的业务更新动作创建专属事件：

• 修改名称 → ProductNameChanged（含productId、newName）
• 更新描述 → ProductDescriptionUpdated（含productId、newDescription）
• 更换图片链接 → ProductImageLinkUpdated（含productId、newImageLink）
• 新增属性（比如sku） → ProductSkuSet（含productId、sku）
• 移除属性（比如不再维护image link） → 废弃ProductImageLinkUpdated事件，聚合中对应字段设为默认值即可

为什么要这么做？ #

• 避免兼容性问题：当聚合属性变化时，只需新增/废弃对应的事件类型，旧事件依然能正常反序列化和应用，不会影响聚合恢复。
• 提升可读性与可维护性：语义化事件能直接体现业务操作，无需解析事件内容就能知道发生了什么，便于团队协作和后续维护。
• 便于溯源与调试：每个业务变更都有独立事件，能清晰追踪聚合状态的演变过程，定位问题更高效。

关于“是否为每个字段单独创建事件”的疑问 #

不是强制为每个字段创建事件，而是看字段的变更是否对应独立的业务动作：

• 如果description和image link是在同一个业务操作中设置的（比如“批量完善产品信息”），可以合并为ProductMetadataSet事件包含这两个字段。
• 如果两个字段的更新是独立的（比如单独改描述、单独换图片），则拆分单独事件更合理。

内容的提问来源于stack exchange，提问作者Splitsan