使用CQRS读取侧实现方法

Question

我已经转移到积极使用CQRS +事件采购的项目。从第一眼开始，它就是根据所有这些书籍和博客实现的，但最后我意识到实施中究竟是什么样的。

这是CQRS架构：

最初我从here拍摄了这张照片。

正如我们在图片中看到的那样，读取端从队列接收事件并将其逐个传递到不同的投影集（非规范化器）中，然后通过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。

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