使用CQRS读取端实现方法

Question

我已经转移到正在积极使用CQRS +事件采购的项目。从乍一看，它是根据所有这些书籍和博客实施的，但最终我意识到实施过程中究竟有什么不好的地方。

这里是CQRS架构：

本来我把这张照片从here。

正如我们在图片中看到的那样，读取端从队列中接收事件，并将其逐个传递到不同的投影集合（反规范化器），然后通过AddOrUpdate方法将结果ViewModel保存到DB中。所以我从图片中了解到，denormalizer只能依赖事件本身加上来自read-side db的数据。 例如：

1. 帐户视图已存储在数据库中。
2. EmailChanged事件到达
3. 我们从DB
4. 读取帐户查看电子邮件应用改变它
5. 我们保存的帐户回DB。

的情况下（计数的一些项目数，说订单）：

1. OrderCreated事件到达
2. 我们读它代表NumberOf视图模型之前已经到达订单
3. 增量并保存此。

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

1. 我们采取域存储库，并阅读所有必要的聚合。这样做，我们得到他们的最新状态。
2. 我们只是从头
3. 保存新创建的对象建立视图模型对象到数据库

我们在我们的项目中使用这种方法看起来有点怪我，我不能看到这一切的缺点虽然。如果我们需要重建读取方，我们添加“活动”denormalizer并且下一次它接收到特定的事件时，它会重新创建新的视图模型。

如果我们使用书中的方法，我将不得不在我的系统之外有一个独立的utils逻辑用于重建。我们需要为这个什么：

1. 下降读取端
2. 从头阅读从事件存储中的所有事件
3. 通过他们通过投影

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

Answer 1

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

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

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