Event Sourcing(事件溯源)可封装多个不同时间发生的业务事件吗？

这种把多个不同时间发生的变更封装到单个SomethingHappened事件的建模方式仅在极有限的特定场景下合理，绝大多数情况不符合事件溯源的核心设计原则。

仅有的合理场景是：事件中包含的prop1、prop2变更属于同一次原子业务操作的结果，比如用户在一次表单提交中同时修改了两个属性的内容，即使两个属性本身自带的历史更新时间不同，本次操作触发的变更打包到同一个事件中是符合要求的。

如果该事件是将多次独立业务操作产生的变更合并打包生成的，那么该建模方式不合理，后续会引发以下典型问题：

• 丢失业务上下文：事件是业务操作的直接映射，合并后的事件无法对应到具体的用户操作意图，后续排查业务问题、做操作审计、统计用户行为时，无法追溯每个属性变更的触发原因，完全丧失了事件溯源最核心的可回溯优势。
• 多设备同步冲突处理失效：你们的场景是离线端侧执行业务逻辑、同组多设备同步，多设备同时修改不同属性是高频场景，合并后的大事件无法支持细粒度的冲突消解。比如A设备修改了prop1、B设备修改了prop2，本来两个变更不存在冲突可以直接合并，打包成大事件后只能选择其中一个事件生效，会导致用户侧出现修改内容莫名丢失的异常。
• 存储与同步成本飙升：每次仅修改一个属性就要全量序列化存储所有关联属性，会导致组流的体积增长速度远快于细粒度事件，不仅占用更多端侧和服务端存储，同步时也会消耗更多流量，同时事件重放的效率会随数据量增长快速下降，端侧冷启动加载全量事件时的卡顿会越来越明显。
• 后续扩展能力受限：如果后续需要新增基于特定属性变更的触发逻辑（比如prop1更新后要刷新对应UI、prop2更新不需要），只能先把整个大事件完全反序列化后才能判断是否要触发对应逻辑，无端增加端侧算力消耗。
• 时间线追溯失真：事件自带的created_date是打包时间而非每个属性的实际变更时间，后续如果要做时间点回溯、合规审计等功能，无法获取准确的操作时间线。

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