何时使用CQRS设计模式?

时间:2012-01-11 14:14:52

标签: design-patterns architecture cqrs

我和我的团队一直在讨论使用CQRS(Command Query Responsibility Segregation)设计模式,我们仍在努力评估使用它的优缺点。根据:http://martinfowler.com/bliki/CQRS.html

  

我们还没有看到CQRS在该领域的足够用途尚未确信   我们理解它的优点和缺点

那么你们怎么想?问题什么时候需要使用CQRS?

10 个答案:

答案 0 :(得分:50)

CQRS不是涵盖整个应用程序的模式。

这是一个基于域驱动设计(DDD)的概念。 DDD的一个重要战略概念是所谓的 Bounded Context

在典型的应用程序中,有多个有界上下文,其中任何一个都可以按照它的意义实现。例如

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

这可能无法解答您的问题,但可能会更深入地了解该主题。老实说,如果不考虑项目的具体细节,我认为根本不能回答,即便如此,很少有像最佳实践这样的东西。

答案 1 :(得分:28)

CQRL评论家可能会说CQRS很复杂,可能也是如此。

当然,它增加了开发CQRS样式的简单CRUD应用程序的开销,所以我考虑仅在以下情况下使用CQRS:

  1. 大型团队 - 如果您选择了CQRS架构,则可以轻松地在人与人之间拆分开发任务。您的顶级人员可以处理域逻辑,将通常的东西留给技能较低的开发人员。
  2. 困难的业务逻辑 - CQRS迫使您避免混淆域逻辑和基础架构操作。
  3. 可伸缩性很重要 - 使用CQRS可以实现出色的读写性能,命令处理可以在多个节点上扩展,并且查询是只读操作,可以对它们进行优化以执行快速读取操作

答案 2 :(得分:13)

当您拥有复杂或艰难的业务领域时:

  • 通过活动采购;你想要一种很好的测试逻辑方法
  • 通过活动采购;你想通过测试和推理来证明你的行为
  • 您拥有域服务的多个客户端或消费者(不仅仅是单个Web服务器)

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

  • 并且您想要正式化您的域的数据合并概念
  • 或者您想应用合并事件的逻辑

或者您有可扩展性要求:

  • 您将模式应用为消除瓶颈的非规范化模式
  • 您希望水平缩放而不是垂直缩放

或者你有性能问题(可扩展性的另一面):

  • e.g。您需要将您的架构迁移到事件驱动的架构 - CQRS作为一种模式是一个很好的垫脚石。

或者你有一个物理分离的团队:

  • e.g。你团队的一部分在另一个国家
  • 或者很难进行面对面的交流,所以你想要将读取的模型与事物的写入方面分离(传奇,域名,CRUD)

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

答案 3 :(得分:8)

  

何时使用CQRS设计模式?

当难以从存储库查询用户需要查看的所有数据时,可以使用CQRS体系结构模式。当UX设计创建跨越多个聚合类型和实例的数据视图时尤其如此。您的域越复杂,这就越真实。

当它不适合在UX设计上妥协时,使用CQRS会尝试减轻与其他解决方案相关的问题,例如:

  • 要求客户端使用多个存储库来检索所有聚合实例;或
  • 在各种存储库上设计专门的查找程序,以使用单个查询收集脱节数据。

总结:使用CQRS时难以从用户需要查看的数据库查询,这往往会发生您的域名越复杂。

答案 4 :(得分:5)

从我的观点来看,它增加了两个主要的好处。(与很多其他人一样)

  1. 极端缩放能力
  2. 当它来到分散的团队时非常有用。

答案 5 :(得分:1)

以下是使用CQRS的原因:

  1. 可伸缩性(读取超出了写入,每个扩展要求也不同,可以更好地解决)
  2. 灵活性(单独的读/写模型)
  3. 降低复杂性(将复杂性转移到单独的问题中)
  4. 专注于域名/业务
  5. 促进设计直观的基于任务的UI

答案 6 :(得分:1)

在现实世界中,如果您的前端/ Web服务客户端需要来自多个域的大量数据并且从数据库中检索这些数据需要很长时间,那么CQRS可能会很有用。

在这种情况下,您可以考虑创建单独的读取模型,这种模型的开发速度更快,执行时间也更快。

答案 7 :(得分:0)

如果您发现问题域不太适合更通用的体系结构,或者您正在尝试域驱动设计,那么建议您尝试一下CQRS。

这是一个强大的模式,它可以使您充分了解问题领域,并解决一些技术和基础设施挑战。但是需要记住的是,它的价格会随之而来,并且由于与其他架构的概念差异,它需要进行思维模式的转变。

CQRS: Intro

答案 8 :(得分:0)

在以下情况下使用它:

  1. 具有复杂的域,需要通过命令来了解域
  2. 读取和写入的应用程序负载不同
  3. 想在任何时间扩展读取操作

https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs#when-to-use-this-pattern

答案 9 :(得分:-1)

关于实现CQRS,当您有一个前端/ Web服务客户端需要来自多个域的大量数据时,我喜欢分离读取模型的想法,我想尝试一下。我想尝试的主要原因是由于开发和执行过程中的“缓慢”问题。特别是在处理大型数据集或“大数据”时。我正在研究可用于降低复杂性,为混合体系结构增加可伸缩性,弹性和灵活性的所有可用选项。