问何时使用CQRS设计模式？

EN

CQRS不是包含整个应用程序的模式。

它是一个建立在领域驱动设计(DDD)之上的概念。DDD的一个重要的战略概念是所谓的有界上下文.

在一个典型的应用程序中，有多个有界的上下文，其中任何一个都可以以合理的方式实现。例如

• 用户管理-> CRUD
• -> CRUD发票
• 保险单管理(核心领域) -> CQRS
• ..。

这可能没有回答你的问题，但它可能会让你对这个话题有更深入的了解。老实说，我认为如果不考虑项目的具体情况，就无法回答这个问题，即使这样，也很少有明确的最佳实践。

那么，CQRL的批评者可能会说CQRS是复杂的，这可能是真的。

当然，它增加了开发CQRS风格的简单CRUD应用程序的开销，所以我只考虑在以下情况下使用CQRS：

1. 大型团队-如果您选择了CQRS体系结构，您可以轻松地在人员之间拆分开发任务。您的高层人员可以在领域逻辑上工作，将通常的工作留给技能较低的开发人员。
2. 困难的业务逻辑- CQRS迫使您避免将域逻辑和基础设施操作混合在一起。
3. 可伸缩性关系到--使用CQRS，您可以获得很好的读写性能，可以在多个节点上扩展命令处理，并且当查询是只读操作时，可以对其进行优化以执行快速读取操作。

当您有一个复杂或困难的业务领域时，并且：

• 使用事件源；您需要一种很好的测试逻辑的方法。
• 使用事件源；您希望通过测试和推理来证明您的行为。
• 您有多个域服务的客户端或使用者(而不仅仅是单个web服务器)。

或者您的用户需要对公共数据采取行动：

• 您希望将域的数据合并概念正式化。
• 或者要将逻辑应用于合并事件。

或者您有可伸缩性要求：

• 您可以将该模式应用为消除瓶颈的反规范化模式。
• 您想要水平而不是垂直地缩放。

或者您有性能问题(可伸缩性的另一面)：

• 例如，您需要将您的体系结构迁移到事件驱动的体系结构-- CQRS作为模式是一个很好的垫脚石。

或者你有一个团队在身体上是分开的：

• 你的团队的一部分在另一个国家
• 或者是很难进行面对面的交流，所以您想要将读取模型从事情的写端(sagas、域、CRUD)中分离出来。

并不是CQRS过于复杂，而是计算机。