问如何在CQRS +事件采购架构中管理ViewModel更改

EN

在CQRS中使用事件源的美妙之处在于能够销毁读取模型，并从头开始重新构建它，如前所述。出于某种原因，人们会有这样的想法，即在超过某个任意数量的事件后，将需要很长时间。如果您正在为您的读取模型使用关系数据库，那么打开一个事务，通过处理程序读取所有事件，然后提交该事务是很容易的。只有当事务提交时，我们才真正接触到磁盘。其他的一切都是在内存中执行的，所以它可以闪电般的快。事实上，如果你的系统在短短几分钟内处理了几百万个事件，我也不会感到惊讶。

从头开始重新构建读取模型的方式应该与将事件反规范化到读取模型的日常方法完全相同。如果没有，那么您的读取模型反规格化代码中就有一个bug。这里最棒的事情是，从您的消息处理程序的角度来看，在常规/生产场景和读取模型重建场景中，事件被接收和反规范化到读取模型之间没有区别。

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

我对CQRS有些陌生，所以这可能不是最好的路线(但iirc我是从CQRS/DDDD邮件列表中选择的)。

我们创建一个命令和相应的处理程序，该命令和相应的处理程序特定于预期运行一次，然后被弃用的目的。

在处理程序中，我们使用任何方便的机制，因此在您添加邮政编码字段的情况下，我们可能会运行一次性查询，从另一个视图模型中提取邮政编码，并填充新列。在这些场景中，我们并不太担心架构的纯洁性，因为它预计是一次性的操作(Rob Conery's Massive已经在这些场景中成功使用)。

我还没有准备好使用cqrs和事件采购的生产应用程序，所以这里只是我尝试构建一个的经验。

1) Read Model rebuild。是的，一旦其中的某些东西发生变化，你基本上必须重新构建整个Read Model DB。如果有很多事件，这可能需要很长时间。因此，Read Model rebuilding必须进行高度优化(使用事件批处理等)。我觉得事件源最适合读写比率较高的情况。因此，对于一些非常不稳定的数据，明智的做法是不将其存储为域事件。但是，关于存储容量的问题也不是那么遥远。在任何情况下，您都可以将cqrs应用于系统的一部分，最适合的部分(例如，我可能不会将图形图像存储为事件的一部分)。

2) Debugging。事件存储中出现错误的可能性很高(这应该是一个框架所关注的问题)，而且检查存储中有哪些事件总是很容易的。至于生成预期事件的命令，您应该在这里进行测试，这些测试可能是系统中最有价值的测试。对于非正规化程序，你也可以进行测试，但我不会费心为琐碎的非正规化程序编写测试，如果它们的正确性可以用肉眼看到的话。话虽如此，我还是多次使用调试器来查找一些更复杂的反正规化程序中的问题；尝试确定哪个事件导致错误并不是那么有趣。