ES、CQRS消息流

ES,CQRS messaging flow

我试图了解可以使用 ES+CQRS 和技术堆栈。 根据我的理解,流程应该如下所示。

  1. UI 向控制器(HTTP 适配器)发送请求
  2. 控制器通过将请求对象作为参数传递来调用应用程序服务。
  3. 应用程序服务从控制器传递的请求对象创建命令。
  4. 应用程序服务将此命令传递给消息使用者。
  5. 消息消费者向消息代理(RabbitMQ)发布命令
  6. 两个订阅者将监听以上命令 一种。一个订阅者将使用命令从 eventStore 生成聚合 并将应用命令而不是生成的事件将存储在事件存储中。 b.另一个订阅者将在 VIEW 端,它将在视图 database/cache 中填充数据。

请指出我的理解是正确的。

Kindly suggest my understanding is correct

我认为您对中间件有点纠结。

通常,CQRS 意味着写入发生在一种数据模型中,而读取发生在另一种数据模型中。所以浏览量不是在看命令,而是在看记录簿。

所以在实际处理命令的订阅者中,命令处理程序会将当前状态从记录簿加载到内存中,根据领域模型更新内存中的副本,然后替换簿中的状态更新版本的记录。

更新记录簿后,我们现在可以触发支持视图的数据模型的刷新; 运行 这里没有业务逻辑,这纯粹是将数据从我们用于写入的模型转换为我们用于读取的模型。

当我们添加事件溯源时,这种模式是相同的——区别在于我们用于写入的数据模型是事件的历史。

How atomicity is achieved in writing data in event store and writing data in VIEW Model?

不是——我们不会尝试使这两个操作成为原子操作。

how do we handle if event is stored in EventStrore but System got crashed before we send event in Message Queue

关键思想是认识到我们通常通过从事件存储中读取事件来构建新视图; 不是 通过从消息队列中读取事件。队列中的事件只是告诉我们有更新可用。在消息队列中没有事件出现的情况下,我们仍然可以轮询事件存储以等待更新。

因此,如果无法访问事件存储,您只需将视图的陈旧副本留在原地,等待系统恢复。

如果事件存储可访问,但消息队列不可访问,则您可以按预定计划更新视图(如有必要)。

这就是 最终一致性 部分的用武之地。如果成功写入事件存储,我们承诺该写入的效果将在有限的范围内可见时间。