我已经转移到积极使用CQRS事件采购的项目 . 从第一眼就看出它是按照所有这些书籍和博客实现的,但最后我意识到实施中究竟是什么样的暴躁 .
这是CQRS架构:
最初我从here拍了这张照片 .
正如我们在图片中看到的那样,读取端从队列接收事件并将其逐个传递到不同的投影集(非规范化器)中,然后通过AddOrUpdate方法将结果的ViewModel保存到DB中 . 因此我从图片中了解到,denormalizer只能依赖事件本身加上来自读取端db的数据 . 例如:
-
帐户视图已存储在数据库中 .
-
EmailChanged事件到来
-
我们从数据库中读取了帐户视图
-
对其应用电子邮件更改
-
我们将帐户保存回DB .
另一个案例(计算一些项目的数量,说订单):
-
OrderCreated事件到来
-
我们读取了ViewModel,它表示NumberOf以前到达的订单
-
递增并保存 .
我们在项目中拥有的内容:我们仅将所有这些事件用作域模型中某些内容发生变化的通知程序 . 因此,我们做了什么:
-
我们使用域存储库并读取所有必需的聚合 . 这样做我们得到了它们的最新状态 .
-
我们只是从头开始构建ViewModel对象
-
将新创建的对象保存到Db中
我们在项目中使用的方法对我来说有点奇怪,但我看不出它的所有缺点 . 如果我们需要重建我们的读取端,我们添加“active”denormalizer,并在下次收到特定事件时,重新创建新的viewmodel .
如果我们使用书中的方法,我将不得不在我的系统之外的某个地方有一个单独的utils逻辑用于重建 . 我们需要什么:
-
放下阅读面
-
从头开始读取事件存储中的所有事件
-
将它们穿过投影
So my question is:
这里的正确方法是什么?
1 回答
一个突出的缺点是,在收到事件后,您必须额外调用相应聚合的存储库 . 这意味着必须直接或作为服务公开此存储库 . 除了增加依赖性之外还有额外的IO .
对于从事件存储库重建,您描述的方法是普遍接受的方法 . 描述的方法here使用专用于重建投影的事件日志 . 这可用于解决重建时的性能问题 . 另请查看Scalable and Simple CQRS Views in the Cloud和DDD/CQRS mailing list .