领域驱动设计，事件采购和不断发展的模型

Question

埃里克·埃文斯谈论了很多关于DDD中演化模型的内容，因此重构似乎对DDD至关重要。当一个人具有世界的关系持久状态时，您可以通过更改数据库模式的迁移来处理模型更改。

使用事件采购时，如何处理模型更改？如果对聚合的不兼容更改会阻止事件的重放，那么是否存在某种最佳实践？或者它只是 - 不是吗？

Answer 1

我自己没有太多的表现。但我看到了一个名为Upcasting的概念

  

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

您可以参考Axon's doc了解更多详情

Answer 2

  

如果聚合上存在不兼容的更改，则会阻止重播事件

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

• 以这样的方式修补旧事件，使它们兼容，并且可以从头开始重放事件。这里的好处是你不会失去历史，但缺点是你必须花费一些精力来修补旧事件。
• 在架构更改时获取聚合的快照/纪念品，并从此时开始“重新定位”事件流。这里的好处是您不必花费任何精力（通过事件采购，您很可能已经建立了快照机制）。缺点是您无法在快照之前重播事件。

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

Answer 3

事件只是DTO。如果事件本身没有改变，只要你还有一个对象，模型如何改变也无关紧要。如果您需要更改事件，可以使用所需的属性“升级”它。 Apply方法将知道如何处理它。在不知道细节的情况下，我无法想出具体的东西。

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

使用事件并不像“经典”OOP和RDBMS架构那样简单，但如果您考虑业务术语并将对象视为域概念，则它们会更灵活。更改模型意味着业务概念定义或用法也已更改，因此现在您正在处理不同的（就持久性而言是新的）概念。