design-patterns - 如何在CQRS +事件源架构中管理ViewModel更改

Question

我们目前正在评估CQRS和事件源架构。我试图了解使用这种设计对维护的影响。我努力寻找答案的两个问题是:

1)
如果在应用程序启动并运行了一段时间后，有新的要求向ReadModel数据库上的ViewModel添加一个附加字段，会发生什么情况？比如说，CustomerList ViewModel上不需要提供客户邮政编码。因此，可以将多余的列轻松添加到ViewModel数据库中，但是如何填充呢？据我所知，唯一的方法是清除读取的数据库，并从头开始重播所有事件，以建立ReadModel Datbase的备份。但是，如果该应用程序已经启动并运行了几个月或几年(我们希望如此)，该怎么办。这可能是要重播的数百万个事件，只是为邮政编码列添加数据。

如果出于某种技术原因，ReadModel数据库不同步，或者我们想添加一个新的ReadModel数据库，我也有同样的担忧。看来应用程序越旧，使用的次数越多，那么更新最新的readmodel就会变得更加困难和昂贵。还是我在某个地方错过了把戏？像ReadModel快照一样？

2)
如果在重放了数百万个事件以构建读取数据库后，某些数据与预期的数据不一致(即看起来不对)，会发生什么情况。人们认为，可能是事件存储中某处的错误或例程的非规范化导致了此错误(而且似乎在编码中可以依靠的一件事就是错误)。如何进行调试!这似乎是不可能完成的任务。又或者，也许我又错过了一个把戏。

我很想听到一直运行这样的系统的任何人的维护和升级途径是如何为您解决的。

感谢您的任何时间和投入。

Answer 1

如前所述，将事件源与CQRS一起使用的好处是能够销毁读取模型并从头开始重建它。由于某些原因，人们有这样的想法:在您遇到一些任意数量的事件之后，这将需要很长时间。如果将关系数据库用于读取模型(很可能是这样)，则很容易打开事务，通过处理程序读取所有事件，然后提交事务。只有在事务提交后，我们才真正接触磁盘。其他所有操作都在内存中执行，因此可以很快实现。实际上，如果您看到系统在短短几分钟内完成了数百万个事件，我不会感到惊讶。

从头开始重建读取模型应该显示与将事件非正规化到读取模型中的日常方法完全相同的方法。如果没有，则您的读取模型非规范化代码中存在错误。伟大的事情是，从消息处理程序的 Angular 来看，在常规/生产场景中以及在读取模型重建场景中，接收到的事件和将其非规范化到读取模型中的事件之间没有区别。

如果确实遇到错误，则可以通过以下方式轻松调试:将生产事件流式传输/复制到本地工作站，在处理程序中设置断点，然后通过读取的模型处理代码运行这些事件。