领域驱动的设计、事件来源和不断发展的模型

Question

Eric Evans在DDD中谈了很多关于模型进化的话题，所以重构似乎对DDD是必不可少的。当一个人拥有世界的关系持久化状态时，可以通过迁移来处理模型更改，从而更改数据库模式。

使用事件源时，如何应对模型更改？如果对聚合有不兼容的更改，这将阻止事件的重播，是否有某种最佳实践？还是只是不要？

Answer 1

事件只是DTO。只要你还有一个对象，如果事件本身没有改变，模型如何改变并不重要。如果需要更改事件，可以使用所需属性对其进行“升级”。Apply方法将知道如何处理它。不知道细节，我就想不出具体的东西。

如果模型变化太大，基本上现在有2个聚合根（AR）而不是前一个，这意味着您有了新的不同聚合，不再使用旧事件。基本上，您从旧AR开始，创建新AR，并生成特定于这些AR的相应事件。因此，在这种情况下，您实际上没有兼容性问题。

使用事件并不像“经典”OOP和RDBMS模式那样简单，但如果您从业务角度考虑，并将对象视为域概念，它们会更加灵活。更改模型意味着业务概念的定义或用法也发生了更改，因此现在您要处理一个不同的（就持久性而言是新的）概念。

Answer 2

我自己也没有多少经验。但我看到了一个叫逆行的概念

最初是一个面向对象编程的概念，其中：“一个子类在需要时自动转换为它的超类”，上转换的概念也可以应用于事件来源。向上投射事件意味着将其从原始结构转换为新结构。与OOP上播不同，事件上播不能完全自动化，因为旧事件不知道新事件的结构。必须提供手动编写的上脚轮来指定如何将旧结构上脚轮到新结构上脚轮。

你可以参考Axon的医生了解更多细节

Answer 3

如果对聚合进行了不兼容的更改，将阻止事件的重播

在这种情况下，您基本上有两种选择：

• 以使旧事件兼容的方式修补旧事件，并且事件可以从头开始重播。这里的好处是你不会失去历史，但缺点是你必须花费一些精力来修补旧的事件。
• 在模式更改点获取聚合的快照/纪念品，并从这一点开始重新设置事件流的基。这里的好处是您不必花费任何精力（通过事件源，您很可能已经有了一个快照机制）。缺点是你失去了从快照之前重播事件的能力。

作为一般的经验法则，我认为默认为第二个选项，除非您确定需要能够在模式更改之前返回并编辑历史。