Domain driven design 在CQRS-won'中同步查询端数据；难道还没有争论吗？

我有一个关于CQRS范式的一般性问题

我知道CommandBus和EventBus将使域模型与我们的查询端数据存储分离，具有最终一致性的优点，并且能够对查询端的存储进行非规范化以优化读取，等等。所有这些听起来都很棒

但是当我开始扩展负责更新查询数据存储的查询端组件的数量时，我想知道它们是否会开始互相竞争来执行更新

换句话说，如果我们尝试为EventBus使用发布/订阅模型，并且对于特定的事件类型有许多不同的订阅者，那么他们就不能开始在更新不同的非规范化数据位方面相互竞争吗？这难道不会让我们与CQR之前的处境相同吗

---

正如我所听到的解释，听起来CQRS应该一起消除这种争论，但这只是一种理想，实际上我们只是在最小化它？我觉得我可能在这里遗漏了一些东西，但我不能对此指手画脚。

这取决于您是如何设计基础设施的。严格地说，CQR本身并没有说明查询模型是如何更新的。使用事件只是您拥有的选项之一。CQRS也没有说任何关于处理争用的内容。它只是一种架构模式，让您有更多的选项和选择来处理并发性之类的事情。在“常规”体系结构中，例如分层体系结构，您通常根本没有这些选项

如果已在多台计算机上扩展了命令处理组件，则可以假定它们可以生成比单个事件处理组件可以处理的事件更多的事件。这不一定是件坏事。这可能只是意味着查询模型将在高峰时间以稍大的延迟进行更新。如果对你来说是个问题，那么你也应该考虑扩展查询模型。

事件处理程序组件本身不会相互竞争。它们可以安全地并行处理事件。但是，如果您将系统设计为使它们都更新相同的数据存储，那么您的数据存储可能会成为瓶颈。设置一个集群或将查询模型划分到不同的数据源上可能是问题的解决方案

不过，要注意不要过早地进行优化。在你有数据证明它对你的具体情况有帮助之前，不要扩大规模。基于CQRS的体系结构允许您做出许多选择。你所需要做的就是在正确的时间做出正确的选择

---

到目前为止，在我参与的应用程序中，我还没有遇到查询模型成为瓶颈的情况。其中一些应用程序每天产生超过100mln的事件。

只是想知道，你是不是想在你的问题中添加标记“Axon”而不是“Axiom”？谢谢你指出错误，我没有密切关注autocomplete。也谢谢你的回答！