使用 CQRS 的读取端实现方法

我已经转移到积极使用 CQRS + 事件源的项目。乍一看它是按照所有这些书籍和博客来实现的，但最后我意识到实现中到底有什么问题。

Here is CQRS architecture:

这张照片最初是我从here http://cre8ivethought.com/blog/2009/11/12/cqrs--la-greg-young.

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

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

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

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

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

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

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

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

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

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

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

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

对于从事件存储重建，您描述的方法是普遍接受的方法。描述的方法here https://abdullin.com/post/event-sourcing-projections/利用专用于重建投影的事件日志。这可用于解决重建时的性能问题。还看一下云中可扩展且简单的 CQRS 视图 http://abdullin.com/journal/2011/1/19/scalable-and-simple-cqrs-views-in-the-cloud.html and on DDD/CQRS 邮件列表 https://groups.google.com/forum/#!topic/dddcqrs/Tn080Iu0zqI.