如何管理CQRS+事件源体系结构中的视图模型更改

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (17)

我们目前正在评估CQRS和事件源架构。我试图了解使用这种设计的维护含义是什么。我很难找到答案的两个问题是:

1)如果在应用程序启动并运行了一段时间之后,需要在ReadModel数据库上添加一个额外的字段,会发生什么?比方说,CustomerList视图模型需要CustomerList视图模型中的CustomerZip代码,而它以前并不是这样的。可以很容易地将额外的列添加到ViewModel数据库中,但是如何填充该列呢?唯一的方法是清除Read数据库,并从头开始重播所有事件,以构建ReadModel数据库。

如果由于任何技术原因,ReadModel数据库不同步,或者我们想要添加一个新的ReadModel数据库,我也会有同样的担心。

2)如果在所有的数百万事件都被重播以重建读取数据库之后,一些数据与预期的不一致(即看起来不对),会发生什么?人们认为,事件存储中的某个地方可能是一个bug,或者反错例程可能导致了这种情况(而且,如果在编码中有一件事可以依赖,那么它就是bug)。如何进行调试!这似乎是一项不可能的任务。

提问于
用户回答回答于

与CQRS一起使用事件源的好处在于能够摧毁读取模型并从头开始重建它,正如前面提到的。

使用关系数据库进行读取模型--很可能是这样--那么打开事务很容易,通过处理程序读取所有事件,然后提交事务。只有当事务提交时,我们才实际接触到磁盘。其他的一切都是在记忆中完成的,所以它可以闪电般的进行。

从零开始重新构建读取模型时,应该以与每天将事件去还原为读模型的方法完全相同的方式显示。如果不是,那么读取模型反正规化代码中就有一个bug。这里最棒的一点是,从消息处理程序的角度来看,在常规/生产场景中接收的事件和非规范化的读模型与读取模型重建场景之间没有区别。

如果确实遇到错误,可以通过流/复制生产事件到本地工作站,在处理程序中设置断点,然后通过读取模型处理代码运行这些事件来进行调试。

用户回答回答于

我对CQRS有点陌生,所以这可能不是最可取的路由(但是iirc我从CQRS/DDDD邮件列表中获得了它)。

我们创建一个特定于预期运行一次的命令和相应的处理程序,然后取消推荐。

在处理程序中,我们使用任何方便的机制,因此在添加邮政编码字段的情况下,我们可以运行一个一次性查询,该查询从另一个视图模型中提取邮政编码并填充新列。

扫码关注云+社区