Eric Evans 谈了很多关于 DDD 中模型的演进，因此重构对于 DDD 来说似乎是必不可少的。当一个人具有世界的关系持久状态时，您可以通过更改数据库模式的迁移来处理模型更改。
使用事件溯源时如何应对模型更改？如果对聚合有不兼容的更改会阻止事件重播，是否有某种最佳实践？还是只是-不要？
问问题
2395 次
3 回答
4
如果对聚合有不兼容的更改会阻止事件重播
在这种情况下，您基本上有两个选择：
- 修补旧事件，使其兼容并且可以从头开始重播事件。这里的好处是您不会丢失历史记录，但缺点是您必须花费一些精力来修补旧事件。
- 在架构更改时拍摄聚合的快照/备忘录，并从此时开始“重新定位”事件流。这样做的好处是您不必花费任何精力（通过事件溯源，您很可能拥有一个快照机制）。缺点是您失去了从快照之前重播事件的能力。
作为一般经验法则，我会说默认为第二个选项，除非您确定需要能够在架构更改之前返回并编辑历史记录。
于 2013-08-03T08:30:42.403 回答
3
我自己没有太多经验。但是我看到了一个叫Upcasting的概念
最初是面向对象编程的概念，其中：“子类在需要时自动转换为它的超类”，向上转换的概念也可以应用于事件溯源。向上转换事件意味着将其从其原始结构转变为新结构。与 OOP 向上转换不同，事件向上转换不能完全自动化完成，因为旧事件不知道新事件的结构。必须提供手动编写的 Upcasters 来指定如何将旧结构向上转换为新结构。
您可以参考Axon 的文档以获取更多详细信息
于 2013-08-03T02:51:43.213 回答
2
事件只是 DTO。只要您仍然拥有一个对象，如果事件本身没有改变，模型如何改变都没有关系。如果您需要更改事件，您可以使用所需的属性“升级”它。Apply 方法将知道如何处理它。在不了解细节的情况下，我无法提出具体的建议。
如果模型变化如此之大以至于基本上现在您有 2 个聚合根 (AR) 而不是以前的一个，这意味着您有新的不同聚合，它们不会使用旧事件。基本上，您从旧的 AR 开始，创建新的 AR 并生成特定于这些 AR 的相应事件。所以在这种情况下你真的没有兼容性问题。
使用事件不像“经典”OOP 和 RDBMS 模式那样简单，但是如果您从业务术语中思考并将对象视为域概念，它们会更加灵活。更改模型意味着业务概念定义或使用也发生了变化，因此现在您正在处理一个不同的（就持久性而言是新的）概念。
于 2013-08-03T09:23:55.200 回答