Events ES、CQRS消息传递流

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

UI向控制器（HTTP适配器）发送请求

控制器通过将请求对象作为参数传递来调用应用程序服务

应用程序服务从控制器传递的请求对象创建命令

应用程序服务将此命令传递给消息使用者

消息使用者向消息代理发布命令（RabbitMQ）

两个用户将监听上述命令 A.一个订阅服务器将使用命令从eventStore生成聚合 并将应用命令，生成的事件将存储在事件存储中。 B另一个订阅服务器将位于视图端，它将填充视图数据库/缓存中的数据 请告知我的理解是正确的

请告知我的理解是正确的

我觉得你的中间件有点纠结

通常，CQRS意味着写入发生在一个数据模型上，而读取发生在另一个数据模型上。因此，视图不是在监视命令，而是在监视记录簿

因此，在实际处理命令的订阅服务器中，命令处理程序将把当前状态从记录簿加载到内存中，根据域模型更新内存中的副本，然后用更新的版本替换记录簿中的状态

更新了记录簿之后，我们现在可以触发对支持视图的数据模型的刷新；这里不运行任何业务逻辑，这纯粹是将数据从用于写入的模型转换为用于读取的模型

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

在事件存储中写入数据和在视图模型中写入数据时如何实现原子性

我们不想把这两个动作变成原子

若事件存储在EventStrore中，但在将事件发送到消息队列之前系统崩溃了，我们该如何处理

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

因此，如果无法访问事件存储，只需保留视图的旧副本，然后等待系统恢复

如果事件存储是可访问的，但消息队列是不可访问的，那么您可以按照预定的时间表更新视图（如果需要）

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

请告知我的理解是正确的

我觉得你的中间件有点纠结

通常，CQRS意味着写入发生在一个数据模型上，而读取发生在另一个数据模型上。因此，视图不是在监视命令，而是在监视记录簿

因此，在实际处理命令的订阅服务器中，命令处理程序将把当前状态从记录簿加载到内存中，根据域模型更新内存中的副本，然后用更新的版本替换记录簿中的状态

更新了记录簿之后，我们现在可以触发对支持视图的数据模型的刷新；这里不运行任何业务逻辑，这纯粹是将数据从用于写入的模型转换为用于读取的模型

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

在事件存储中写入数据和在视图模型中写入数据时如何实现原子性

我们不想把这两个动作变成原子

若事件存储在EventStrore中，但在将事件发送到消息队列之前系统崩溃了，我们该如何处理

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

因此，如果无法访问事件存储，只需保留视图的旧副本，然后等待系统恢复

如果事件存储是可访问的，但消息队列是不可访问的，那么您可以按照预定的时间表更新视图（如果需要）

---

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

我仍然不确定。在事件存储中写入数据和在视图模型中写入数据是如何实现原子性的。我在Write Model CommandHanders的博客/文章中看到的内容是执行以下步骤。1.根据命令2从事件存储中获取事件。使用事件3创建聚合。Apply命令，该命令为该聚合4生成事件。这些事件都是一场灾难。保存在事件存储b中。事件被发送到消息队列中以供读取模型使用现在a、b步骤不是原子的，如果事件存储在EventStrore中，但系统在发送消息队列中的事件之前崩溃，我们该如何处理。从事件被持久化到它被添加到队列中的时间在大多数情况下是以低毫秒为单位测量的。因此，这种情况极不可能发生。但如果是这样的话，聚合和读取模型的版本号将被删除。只需重播自上次读取模型更新以来的事件。你可能会发现我的文章概述了一个典型的CQS ES体系结构，这很有帮助：@Nishat some event