使用CQRS的读取端实现方法 [英] Read side implementation approaches using CQRS

问题描述

我已经转到积极使用CQRS +事件源的项目.乍一看，它是按照所有这些书籍和博客进行实现的，但是最后，我意识到实现的确切意义.

I've moved to the project which is actively using CQRS + event sourcing. From the first glance it's implemented in accordance with all those books and blogs, but finally I realized what exactly is peevish in the implementation.

这是CQRS架构:

最初，我是从此处拍摄的这张照片.

Originally I took this picture from here.

如图片所示，读取端从队列接收事件，并将事件逐一传递到不同的投影集(去规范化器)中，然后通过AddOrUpdate方法将生成的ViewModel保存到DB中.因此，据我所知，图片非规范化器只能依赖于事件本身以及来自读取侧db的数据. 例如:

As we can see in the picture, the read side receives events from the queue and passes it one by one into different sets of projections(denormalizers) and then resulting ViewModels are saved through AddOrUpdate method into, say, DB. So as I understand from the picture denormalizer can rely only on the event itself plus data from read-side db. For instance:

1. 帐户视图已存储在数据库中.
2. EmailChanged事件到来
3. 我们从数据库中读取了帐户视图
4. 对其应用电子邮件更改
5. 我们将帐户保存回数据库.

另一种情况(计算某些商品的数量，例如订单):

Another case(counting number of some items, say orders):

1. OrderCreated事件到达
2. 我们阅读了代表ModelOf先前到达的订单的ViewModel
3. 增加并保存.

我们的项目中有什么: 我们仅将所有这些事件用作域模型中某些更改的通知器.因此，我们的工作:

What we have in our project: We use all those events only as a notifier that something changed in the domain model. Hence, what we do:

1. 我们获取域存储库并阅读所有必要的汇总.这样做，我们可以获得它们的最新状态.
2. 我们只是从头开始构建ViewModel对象
3. 将新创建的对象保存到Db

我们在项目中使用的方法对我来说有点奇怪，尽管我看不到它的所有缺点.如果需要重建读取端，可以添加活动"反规范化器，并在下次接收到特定事件时，重新创建新的视图模型.

The approach we use in our project looks a bit strange to me, I can't see all the drawbacks of it though. If we need to rebuild our read side, we add "active" denormalizer and next time it receives a particular event, it recreates the new viewmodel.

如果我们使用书本中的方法，则必须在系统之外的某个地方使用单独的utils逻辑进行重建.我们需要什么:

If we use approach from the books, I will have to have a separate utils logic somewhere out of my system for rebuilding. What we need for this:

1. 丢下读取面
2. 从头开始读取事件存储中的所有事件
3. 让它们穿过投影

所以我的问题是:
在这里什么是正确的方法?

So my question is:
What is the right approach in here?

推荐答案

我们在项目中使用的方法对我来说有点奇怪，我不能 看到它的所有缺点.

The approach we use in our project looks a bit strange to me, I can't see all the drawbacks of it though.

一个显着的缺点是，在收到事件后，您必须对相应集合的存储库进行额外的调用.这意味着必须直接或作为服务公开此存储库.除了增加了依赖性之外，还增加了IO.

One prominent drawback is that upon receipt of the event, you have to make an additional call to the repository of the corresponding aggregate. This means that this repository must be exposed, either directly or as a service. In addition to increased dependencies is the additional IO.

要从事件存储区重建，您描述的方法是公认的方法. 此处所述的方法利用了专用于重建投影的事件日志.这可用于在重建时解决性能问题.另请参阅云中和 DDD/CQRS上的可伸缩和简单的CQRS视图邮件列表.

For rebuilding from an event store, the approach you describe is the generally accepted method. An approach described here makes use of an event log dedicated for rebuilding projections. This can be used to address performance issues while rebuilding. Also take a look at Scalable and Simple CQRS Views in the Cloud and on DDD/CQRS mailing list.

这篇关于使用CQRS的读取端实现方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！