Eric Evans 经常谈到 DDD 中的模型演化，因此重构似乎对 DDD 至关重要。当一个世界具有关系持久状态时，您可以通过更改数据库架构的迁移来处理模型更改。
在使用事件溯源时如何应对模型更改？如果对聚合有不兼容的更改会阻止事件重播，是否有某种最佳实践？还是只是不要？
【问题讨论】：
标签： domain-driven-design event-sourcing
我自己没有太多经验。但是我看到了一个叫Upcasting的概念
最初是面向对象编程的概念，其中：“子类在需要时自动转换为它的超类”，向上转换的概念也可以应用于事件溯源。向上转换事件意味着将其从其原始结构转变为新结构。与 OOP 向上转换不同，事件向上转换不能完全自动化完成，因为旧事件不知道新事件的结构。必须提供手动编写的 Upcasters 来指定如何将旧结构向上转换为新结构。
您可以参考Axon's doc了解更多详情
【讨论】：
如果对聚合有不兼容的更改会阻止事件重放
在这种情况下，您基本上有两种选择：
作为一般经验法则，我会说默认为第二个选项，除非您确定需要能够在架构更改之前返回并编辑历史记录。
【讨论】：
事件只是 DTO。只要您仍然拥有一个对象，如果事件本身没有改变，模型如何改变都没有关系。如果您需要更改事件，您可以使用所需的属性“升级”它。 Apply 方法将知道如何处理它。在不了解细节的情况下，我无法提出具体的建议。
如果模型变化如此之大，以至于基本上现在您有 2 个聚合根 (AR) 而不是之前的一个，这意味着您有新的不同聚合，它们不会使用旧事件。基本上，您从旧的 AR 开始，创建新的 AR 并生成特定于这些 AR 的相应事件。因此，在这种情况下，您并没有真正遇到兼容性问题。
使用事件不像“经典”OOP 和 RDBMS 模式那样简单，但如果您从业务角度考虑并将对象视为域概念，它们会更加灵活。更改模型意味着业务概念的定义或用法也发生了变化，因此现在您正在处理一个不同的（就持久性而言是新的）概念。
【讨论】：