CQRS 代表命令查询职责分离。这是我第一次听到Greg Young描述的模式。其核心概念是，您可以使用与用于读取信息的模型不同的模型来更新信息。在某些情况下，这种分离可能很有价值，但请注意，对于大多数系统，CQRS 会增加风险的复杂性。
人们用于与信息系统交互的主流方法是将其视为 CRUD 数据存储。我的意思是，我们有一些记录结构，我们可以心智模式 ç reate新纪录，[R EAD记录，ü PDATE现有记录，并ð elete记录时，我们与他们所做的。在最简单的情况下，我们的交互都是关于存储和检索这些记录。
随着我们的需求变得更加复杂，我们逐渐摆脱了这种模式。我们可能希望以不同于记录存储的方式查看信息，可能将多个记录合并为一个，或者通过组合不同位置的信息来形成虚拟记录。在更新方面，我们可能会发现验证规则只允许存储某些数据组合，甚至可能推断要存储的数据与我们提供的数据不同。
当这种情况发生时，我们开始看到信息的多种表示。当用户与信息交互时，他们使用此信息的各种表示形式，每一种表示形式都不同。开发人员通常会构建自己的概念模型，用于操作模型的核心元素。如果您使用域模型，那么这通常是域的概念表示。您通常还会使持久存储尽可能接近概念模型。
这种多层表示的结构可能会变得非常复杂，但是当人们这样做时，他们仍然将其分解为单个概念表示，作为所有表示之间的概念整合点。
CQRS 引入的更改是将该概念模型拆分为单独的模型以进行更新和显示，在CommandQuerySeparation词汇表之后分别将其称为 Command 和 Query 。基本原理是，对于许多问题，尤其是在更复杂的领域中，具有相同的命令和查询概念模型会导致更复杂的模型两者都做不好。
分离模型通常是指不同的对象模型，可能运行在不同的逻辑进程中，也可能运行在不同的硬件上。Web 示例将看到用户查看使用查询模型呈现的网页。如果他们发起更改，将更改路由到单独的命令模型进行处理，则将产生的更改传达给查询模型以呈现更新的状态。
这里有相当大的变化空间。内存模型可能共享同一个数据库，在这种情况下，数据库充当两个模型之间的通信。然而，它们也可能使用单独的数据库，有效地使查询端的数据库成为实时ReportingDatabase。在这种情况下，两个模型或其数据库之间需要某种通信机制。
这两个模型可能不是单独的对象模型，可能是相同的对象在其命令端和查询端具有不同的接口，就像关系数据库中的视图一样。但通常当我听到 CQRS 时，它们显然是独立的模型。
CQRS 自然适合其他一些架构模式。
- 当我们远离通过 CRUD 与之交互的单一表示时，我们可以轻松地转向基于任务的 UI。
- CQRS 非常适合基于事件的编程模型。通常会看到 CQRS 系统拆分为与Event Collaboration通信的单独服务。这允许这些服务轻松利用事件溯源。
- 拥有单独的模型会引发关于保持这些模型一致性有多难的问题，这增加了使用最终一致性的可能性 。
- 对于许多域，更新时需要很多逻辑，因此使用EagerReadDerivation来简化查询端模型可能是有意义的 。
- 如果写入模型为所有更新生成事件，您可以将读取模型构建为EventPosters，允许它们成为MemoryImages从而避免大量数据库交互。
- CQRS 适用于复杂的领域，也可以从领域驱动设计中受益。
何时使用
与任何模式一样，CQRS 在某些地方很有用，但在其他地方则不然。许多系统确实适合 CRUD 心智模型，因此应该以这种方式完成。CQRS 对所有相关人员来说都是一次重大的精神飞跃，因此除非带来的好处值得一试，否则不应解决。虽然我遇到了 CQRS 的成功使用，但到目前为止，我遇到的大多数情况都不是很好，CQRS 被视为使软件系统陷入严重困境的重要力量。
特别是 CQRS 应该只用于系统的特定部分（DDD 术语中的BoundedContext）而不是整个系统。按照这种思维方式，每个有界上下文都需要自己决定如何对其进行建模。
到目前为止，我看到了两个方向的好处。首先，使用 CQRS 可能更容易处理一些复杂的域。然而，我必须强调，CQRS 的这种适用性在很大程度上是少数情况。通常在命令和查询端之间有足够的重叠，共享模型更容易。在不匹配的域上使用 CQRS 会增加复杂性，从而降低生产力并增加风险。
另一个主要好处是处理高性能应用程序。CQRS 允许您将负载与读取和写入分开，从而允许您独立扩展每个负载。如果您的应用程序发现读取和写入之间存在很大差异，这非常方便。即使没有，您也可以对两端应用不同的优化策略。这方面的一个示例是使用不同的数据库访问技术进行读取和更新。
如果您的域不适合 CQRS，但您有要求增加复杂性或性能问题的查询，请记住您仍然可以使用ReportingDatabase。CQRS 对所有查询使用单独的模型。使用报告数据库，您仍然使用主系统进行大多数查询，但将要求更高的查询卸载到报告数据库。
尽管有这些好处，但您在使用 CQRS 时应该非常谨慎。许多信息系统非常符合信息库的概念，信息库的更新方式与读取方式相同，向此类系统添加 CQRS 会显着增加复杂性。我当然见过这样的案例，它严重拖累了生产力，给项目增加了不必要的风险，即使是在一个有能力的团队手中。因此，虽然 CQRS 是一种很好的工具箱模式，但请注意，它很难很好地使用，如果处理不当，很容易砍掉重要的部分。
-摘自 https://martinfowler.com/bliki/CQRS.html