何时使用CQRS设计模式？

Question

何时使用CQRS设计模式？

Eri*_*ric 53 architecture design-patterns cqrs

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

我们还没有看到CQRS在该领域的足够用途,但仍然有信心我们理解其优缺点

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

Answer 1

Den*_*aub 55

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

它是一个基于域驱动设计(DDD)的概念.DDD的一个重要战略概念就是所谓的有界背景.

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

用户管理 - > CRUD
开票 - > CRUD
保险政策管理(核心领域) - > CQRS
...

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

@DennisTraub实际上我认为你的句子是恰当的,而且Grigori Melnik以错误的方式解释它. (19认同)
@GrigoriMelnik也许我答案的第一句话没有明确表达(我也不是母语人士).据我所知,我说的和你一样.CQRS应该在有限的上下文中应用,而不是在整个应用程序中应用. (7认同)
不同意CQRS不是模式的说法,一旦您决定使用它,通常会包含整个应用程序.CQRS是一种架构模式,而不是顶级架构.因此,您必须评估是否将其应用于每个特定的有界上下文.请参阅http://cqrsjourney.github.com并阅读第二篇参考章节. (4认同)

Answer 2

Mai*_*kov 30

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

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

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

我不太确定在考虑CQRS时会有一个分布式团队.*任何*分层/多层应用程序都可以分解出很好的隔离任务. (8认同)

Answer 3

Hen*_*rik 13

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

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

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

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

或者您有可扩展性要求:

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

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

例如,您需要将您的架构迁移到事件驱动的架构 - 作为模式的CQRS是一个很好的垫脚石.

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

例如,你团队的一部分在另一个国家
或者很难进行面对面的交流,所以你想要将读取的模型从事物的写入方面解耦(传说,域名,CRUD)

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

Answer 4

Fre*_*ald 9

何时使用CQRS设计模式？

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

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

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

总结一下:当难以从存储库中查询数据用户需要查看时使用CQRS,这往往会发生您的域越复杂.

Answer 5

Mar*_*zak 7

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

在这种情况下，您可能会考虑创建单独的读取模型，该模型的开发速度更快，并且执行时间可能更快。

Answer 6

Gle*_*enn 5

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

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

没有示例的“极端扩展能力”并没有说太多，“对于分散的团队来说非常有用。” - 怎么样？不是一个真正的答案 (2认同)

Answer 7

小智 5

以下是使用 CQRS 的原因：

可扩展性（读取超过写入，因此每个不同的扩展要求也不同，并且可以更好地解决）
灵活性（单独的读/写模型）
降低复杂性（将复杂性转移到单独的关注点）
专注于领域/业务
有助于设计直观的基于任务的 UI

Answer 8

cry*_*KTM 5

好吧，你的问题没有直接的答案，但我想给你一些 关于如何实现 CRQS 的真实示例，这可以帮助你弄清楚如何在你的应用程序中使用它，

1.Instagram

我们经常看到 Instagram 的故事/卷轴等。这些商店是读取密集型的，最好为此类数据建立一个单独的只读数据库。外部世界只能处理特定的数据库来渲染朋友时间线中的故事，这样做系统不需要打扰存储主要业务密集型信息的主数据库。

2.亚马逊

当下订单时，订单服务会发出一个事件，该事件由其他服务订阅，其中可以更新非规范化只读数据库，而其他服务（比如说消息服务）可以简单地获取规范化信息，例如 userId，从只读数据库订购等，并继续进行电子邮件处理以确认订单

归档时间：	14 年前
查看次数：	30043 次
最近记录：	6 年，2 月前