事件溯源：多事件与单一StatusChanged事件的方案抉择

我更倾向于保留带操作语义的独立事件方案（OrderCreated、OrderPicked、OrderPacked、OrderShipped），核心原因如下：

• 事件的本质是记录领域中发生的真实业务行为，独立事件直接映射业务操作，能清晰还原订单的完整生命周期。比如看到OrderShipped，所有人都能立刻知道是执行了发货操作导致状态变更；而单一StatusChanged事件只能告诉你状态变了，却无法说明"为什么变"，时间久了无论是排查问题、做业务审计，还是新成员理解业务，都会额外增加成本。

• 针对你提到的逻辑重复问题，完全不需要用牺牲语义的方式解决，抽离共享逻辑即可：

  • 封装一个独立的OrderStateRule类，把所有"操作事件→目标状态"的映射规则集中在这里
  • 聚合根的apply方法和投影器都调用这个类的方法来更新状态，各自只负责事件消费和状态设置，核心转换逻辑只维护一次
  • 这种方式既保留了事件的语义清晰度，又彻底消除了代码重复

• 从扩展性角度看，独立事件方案容错性更强。哪怕现在这些事件只变更状态，未来一旦某类操作需要携带额外属性（比如OrderShipped要加物流单号），直接给对应事件加字段即可，不会影响其他事件的处理逻辑；而单一StatusChanged事件要扩展的话，要么加可选字段导致结构臃肿，要么不得不新增事件，反而更麻烦。

当然，如果你的业务场景极端简单，状态转换永远不会扩展，且团队完全不在意事件的可读性，单一StatusChanged事件确实能省点初期开发时间，但这种情况在实际业务中几乎不存在。

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