Jam*_*mes 19 architecture design-patterns cqrs event-sourcing
我们目前正在评估CQRS和事件采购架构.我试图了解使用这种设计的维护含义是什么.我正在努力寻找答案的两个问题是:
1)如果在应用程序启动并运行一段时间后,有新的要求在ReadModel数据库上向ViewModel添加其他字段会发生什么？比如,CustomerList ViewModel上需要Customer Zip Code,而以前不是.因此,可以轻松地将额外列添加到ViewModel数据库,但是如何填充这些列？据我所知,唯一的方法是清除读取数据库,并从头开始重放所有事件以构建备份ReadModel数据库.但是,如果应用程序已启动并运行数月或数年(我们希望如此),该怎么办？这可能是数百万个要重播的事件,只是为了添加zipcode列的数据.
如果由于任何技术原因,ReadModel数据库不同步,或者我们想要添加新的ReadModel数据库,我也会有同样的担忧.看起来应用程序的版本越旧,使用的越多,更难和更昂贵的是获得最新的readmodel.或者我在某个地方错过了一招？像ReadModel快照一样？
2)如果在重放所有数百万个事件以构建备份读取数据库之后会发生什么,一些数据与预期不符(即看起来不对).据认为,在事件存储或非规范化例程中某处可能存在错误可能导致这种情况(似乎如果在编码中有一件事可以依赖,那就是错误).怎么去调试这个!这似乎是一项不可能的任务.或许,再次,我错过了一个技巧.
我有兴趣听到任何一直在运行这样的系统的人,以及维护和升级路径如何为您解决.
感谢您的任何时间和意见.
Jon*_*ver 15
如上所述,使用CQRS进行事件采购的美妙之处在于能够破坏读取模型并从头开始重建.出于某种原因,人们有这样的想法,即在你超过一些任意数量的事件之后需要很长时间.如果您正在为读取模型使用关系数据库 - 而且很可能是 - 那么打开事务很容易,通过处理程序读入所有事件然后提交事务.只有在事务提交时才会实际触及磁盘.其他所有内容都在内存中执行,因此它可以快速闪电.事实上,如果你看到你的系统在短短几分钟内完成了几百万个事件,我就不会感到惊讶了.
从头开始重建您的读模型应该显示与将事件非规范化为读取模型的日常方法完全相同的方式.如果没有,您的读取模型非规范化代码中存在错误.这里的好处是,从您的消息处理程序的角度来看,在常规/生产场景和读取模型重建场景中,正在接收和非规范化为读取模型的事件之间没有区别.
如果遇到错误,可以通过将生产事件流式传输/复制到本地工作站,在处理程序中设置断点,然后通过读取模型处理代码运行这些事件来轻松调试.