使用CQRS读取侧实现方法

Question

我已经转移到积极使用CQRS +事件采购的项目.从第一眼就看出它是按照所有这些书籍和博客实现的,但最后我意识到实施中究竟是什么样的暴躁.

这是CQRS架构:

本来我从这里拍了这张照片.

正如我们在图片中看到的那样,读取端从队列接收事件并将其逐个传递到不同的投影集(非规范化器)中,然后通过AddOrUpdate方法将结果的ViewModel保存到DB中.因此我从图片中了解到,denormalizer只能依赖事件本身加上来自读取端db的数据.例如:

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

另一个案例(计算一些项目的数量,说订单):

1. OrderCreated事件到来
2. 我们读取了ViewModel,它表示NumberOf以前到达的订单
3. 增加并保存.

我们在项目中拥有的内容:我们仅将所有这些事件用作域模型中某些内容发生变化的通知程序.因此,我们做了什么:

1. 我们使用域存储库并读取所有必需的聚合.这样做我们得到了它们的最新状态.
2. 我们只是从头开始构建ViewModel对象
3. 将新创建的对象保存到Db中

我们在项目中使用的方法对我来说有点奇怪,但我看不出它的所有缺点.如果我们需要重建我们的读取端,我们添加"active"denormalizer,并在下次收到特定事件时,重新创建新的viewmodel.

如果我们使用书中的方法,我将不得不在我的系统之外的某个地方有一个单独的utils逻辑用于重建.我们需要什么:

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

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

Answer 1

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

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

对于从事件存储库重建,您描述的方法是普遍接受的方法.这里描述的方法利用专用于重建投影的事件日志.这可用于解决重建时的性能问题.另请参阅云中和DDD/CQRS邮件列表中的可扩展和简单CQRS视图.