使用CQRS的Read Side实现方法

Question

我已经加入了一个正在积极使用CQRS + 事件溯源的项目。乍一看，它按照所有那些书籍和博客的要求实施，但最终我意识到实现中有什么问题。

这是CQRS架构：

最初我从这里获取了这张图片。

如我们所见，读取端从队列接收事件，并将其逐个传递到不同的投影（去规范化）集合中，然后通过AddOrUpdate方法将结果ViewModel保存到，比如，数据库中。因此，根据图片，我理解的是去规范化器只能依赖于事件本身以及来自读取端数据库的数据。 例如：

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

另一个例子（计算某些项目的数量，比如订单）：

1. 创建订单事件到达。
2. 我们读取表示之前到达的订单数量的ViewModel。
3. 对其进行递增并保存此信息。

我们在项目中所使用的方式：我们仅使用所有这些事件作为某些内容在领域模型中发生更改的通知程序。因此，我们做的是：

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

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

如果我们采用书中所述的方法，我就必须在系统之外单独拥有一个工具逻辑来进行重建。这需要以下步骤：

1. 放弃读取端
2. 从头开始读取事件存储中的所有事件
3. 通过投影对它们进行处理

所以我的问题是:
在这种情况下什么是正确的方法呢？

- Max

Answer 1

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

其中一个显著的缺点是，在接收事件时，您必须对相应聚合的存储库进行额外的调用。这意味着这个存储库必须被公开，可以直接访问或作为服务。除了增加依赖关系，还会增加额外的IO。

对于从事件存储库重建，您描述的方法是通常被接受的方法。在此处描述的方法利用了专门用于重建投影的事件日志。这可以用来解决在重建期间的性能问题。还可以查看Scalable and Simple CQRS Views in the Cloud和DDD/CQRS邮件列表。

- eulerfx

---

投影文章的链接已移至：http://abdullin.com/post/event-sourcing-projections/。 - Masood Khaari

图表中服务代表的是什么？ - Ashwani Tiwari