使用 CQRS 的读取端实现方法

Question

我已经转移到积极使用 CQRS + 事件溯源的项目。乍一看，它是按照所有那些书籍和博客来实现的，但最后我才意识到实现中到底有什么令人讨厌的地方。

这里是CQRS架构：

原来这张照片是我从here拍的。

正如我们在图片中看到的，读取端从队列中接收事件并将其逐个传递到不同的投影集（反规范化器）中，然后通过 AddOrUpdate 方法将生成的 ViewModel 保存到例如 DB 中。因此，据我所知，图片反规范化器只能依赖事件本身加上来自读取端数据库的数据。 例如：

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

另一种情况（计算一些物品的数量，比如订单）：

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

我们在项目中拥有的东西： 我们仅将所有这些事件用作域模型中发生更改的通知器。因此，我们做什么：

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

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

如果我们使用书中的方法，我将不得不在我的系统之外的某个地方有一个单独的实用程序逻辑来进行重建。为此我们需要什么：

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

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

Answer 1

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

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

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