ES，CQRS消息传递流程

Question

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

1. UI向控制器（HTTP适配器）发送请求
2. 控制器通过将请求对象作为参数来调用应用程序服务。
3. 应用程序服务根据从控制器传递的请求对象创建命令。
4. 应用程序服务将此命令传递给消息使用者。
5. 消息使用者将命令发布到消息代理（RabbitMQ）
6. 两个订户将监听上面的命令a。一个订户将使用命令从eventStore生成Aggregate，并将应用命令，而不是将生成的事件存储在事件存储中。b。另一个订户将在VIEW端，这将在View数据库/缓存中填充数据。

请暗示我的理解是正确的。

Answer 1

请暗示我的理解是正确的

我认为您的中间件有些混乱。

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

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

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

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

如何在事件存储中写入数据和在VIEW Model中写入数据如何实现原子性？

不是-我们不会尝试使这两个动作具有原子性。

我们如何处理事件存储在EventStrore中但系统崩溃的情况，然后才在Message Queue中发送事件

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

因此，如果无法访问事件存储，则只需将视图的陈旧副本保留在适当的位置，然后等待系统恢复。

如果事件存储可访问，但消息队列不可达，则可以按预定的时间表更新视图（如有必要）。

这就是最终一致性部分的用处。成功写入事件存储后，我们保证该写入的效果将在有限的时间内可见。