20

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

这是CQRS架构：CQRS 设计

最初我从这里拍了这张照片。

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

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

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

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

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

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

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

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

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

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

4

1 回答 1

6

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

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

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

于 2013-04-16T23:48:37.270 回答