首页 文章

使用CQRS读取侧实现方法

提问于
浏览
17

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

这是CQRS架构:
CQRS design

最初我从here拍了这张照片 .

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

  • 帐户视图已存储在数据库中 .

  • EmailChanged事件到来

  • 我们从数据库中读取了帐户视图

  • 对其应用电子邮件更改

  • 我们将帐户保存回DB .

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

  • OrderCreated事件到来

  • 我们读取了ViewModel,它表示NumberOf以前到达的订单

  • 递增并保存 .

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

  • 我们使用域存储库并读取所有必需的聚合 . 这样做我们得到了它们的最新状态 .

  • 我们只是从头开始构建ViewModel对象

  • 将新创建的对象保存到Db中

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

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

  • 放下阅读面

  • 从头开始读取事件存储中的所有事件

  • 将它们穿过投影

So my question is:
这里的正确方法是什么?

1 回答

  • 5

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

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

    对于从事件存储库重建,您描述的方法是普遍接受的方法 . 描述的方法here使用专用于重建投影的事件日志 . 这可用于解决重建时的性能问题 . 另请查看Scalable and Simple CQRS Views in the CloudDDD/CQRS mailing list .

相关问题