首页
学习
活动
专区
工具
TVP
发布
社区首页 >问答首页 >如何在CQRS +事件采购架构中管理ViewModel更改

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

Stack Overflow用户
提问于 2011-04-07 21:43:44
回答 4查看 3.8K关注 0票数 20

我们目前正在评估CQRS和事件采购架构。我正在尝试理解使用这种设计的维护含义是什么。我正在努力寻找答案的两个问题是:

1)如果在应用程序启动并运行了一段时间后,需要向ReadModel数据库上的ViewModel添加一个额外的字段,会发生什么情况?比方说,客户邮政编码在CustomerList ViewModel上是必需的,而以前没有。因此,可以很容易地将额外的列添加到ViewModel数据库,但是如何填充这些列呢?据我所知,唯一的方法是清除读取的数据库,并从头开始重放所有事件以构建ReadModel数据库。但是,如果应用程序已经启动并运行了几个月或几年(正如我们希望的那样),该怎么办?这可能是数百万个要重放的事件,仅仅是为了添加zipcode列的数据。

无论出于何种技术原因,如果ReadModel数据库不同步,或者我们想要添加一个新的ReadModel数据库,我也有同样的担忧。似乎应用程序越旧,使用得越多,就越难和昂贵地重新获得最新的readmodel。或者我错过了什么把戏?像ReadModel快照这样的东西?

2)如果在重播了数百万个事件以构建读取数据库后,某些数据与预期不符(即看起来是错误的),会发生什么情况?人们认为,可能是事件存储或反规范化例程中的某个bug导致了这种情况(似乎在编码中有一件事可以依靠,那就是bug)。如何去调试这个!这似乎是一项不可能完成的任务。或者,再一次,我错过了一个小把戏。

我很有兴趣听到任何人谁已经运行了这样的系统一段时间,如何维护和升级路径为您工作。

感谢您的宝贵时间和投入。

EN

回答 4

Stack Overflow用户

回答已采纳

发布于 2011-04-08 04:55:30

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

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

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

票数 15
EN

Stack Overflow用户

发布于 2011-04-08 03:18:27

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

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

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

票数 2
EN

Stack Overflow用户

发布于 2011-04-08 04:03:09

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

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

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

票数 1
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/5582089

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档