事件溯源电商应用中CRUD类操作的困境与求解

兄弟，太懂你的纠结了！我在电商领域落地事件溯源的时候，一开始也对着标题、商品图片这类修改犯愁——总觉得为这些小事加个TitleChangedEvent、ImageUpdatedEvent既啰嗦又污染核心聚合的事件模型，但直接改投影又怕丢数据，甚至怀疑是不是选错了架构。

其实这完全不是事件溯源的问题，而是我们没搞清楚事件溯源的适用边界：它是用来记录有业务意义的状态变更，而非所有数据的修改。针对你说的场景，分享几个我实际用过的解决方案：

1. 拆分核心聚合与附属实体 #

把商品拆成两个独立部分：

• 核心聚合根Product：只处理真正影响业务逻辑的事件，比如PriceIncreasedEvent、ProductDeactivatedEvent、OutOfStockEvent，这些事件直接关联库存、价格、售卖状态等核心业务规则。
• 附属实体ProductPresentation：专门负责标题、商品图片、描述这类展示类数据。这个实体可以用传统CRUD模式存储（比如直接用关系型数据库），或者也用事件溯源但只记录PresentationFieldUpdatedEvent这类通用事件——它的事件流完全独立于核心Product，不会污染核心领域模型。

这样做的好处是，核心聚合保持纯净，附属数据的修改不用牵扯到核心业务逻辑，投影构建的时候，只需要把两个实体的数据合并即可。

2. 用通用元事件处理非核心字段 #

如果不想拆分聚合，那可以给核心Product加一个通用的ProductMetadataUpdatedEvent，事件里包含修改的字段名、旧值和新值，比如：

public class ProductMetadataUpdatedEvent {
    private String productId;
    private String fieldName; // 比如"title"、"imageUrl"
    private String oldValue;
    private String newValue;
}

注意：这个事件不能触发任何核心业务逻辑，它的唯一作用就是给投影提供更新依据。这样既保留了溯源能力（你能查到什么时候改了哪个字段），又不用为每个小字段单独创建事件。

当然，这种方式要控制使用范围——只用于真正无业务意义的字段，别把核心业务变更也塞进这个事件里。

3. 接受“部分数据无需事件溯源” #

事件溯源不是银弹，不是所有数据都需要通过事件流来记录。对于那些纯展示、不影响任何业务规则的字段（比如商品图片路径、非关键的标题修改），你可以：

• 把这些数据存在专门的“补充存储”里（比如一个ProductDetails表）；
• 当投影需要重建时，先从事件流恢复Product的核心状态（库存、价格等），再从补充存储里加载这些附属字段。

这种方式的关键是，补充存储的数据只作为投影的“补充”，核心业务状态永远以事件流为准。即使补充存储的数据丢了，最多是展示层暂时没标题/图片，但核心业务不受影响，你可以从用户的操作记录里恢复（或者让用户重新上传）。

4. 再仔细审视“非核心字段”的业务意义 #

有时候我们觉得某个字段是“非核心”，但其实藏着业务逻辑。比如电商里的标题：

• 如果标题修改需要审核，那TitleChangedEvent就有意义——它可以触发审核流程；
• 如果标题会影响搜索、推荐系统的索引，那这个事件可以通知搜索服务更新索引。

如果有这类隐藏的业务逻辑，那创建专门的事件反而更合理，这不是代码坏味道，而是正确的领域建模。

总之，选择事件溯源绝对不是错误的决定——它帮你把核心业务的状态变更记录得清清楚楚，而对于非核心的CRUD操作，我们只需要灵活搭配其他存储方式，不用硬套事件溯源的模式。

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