我和我的团队一直在讨论使用CQRS(Command Query Responsibility Segregation)设计模式,我们仍在努力评估使用它的优缺点。根据:http://martinfowler.com/bliki/CQRS.html
我们还没有看到CQRS在该领域的足够用途尚未确信 我们理解它的优点和缺点
那么你们怎么想?问题什么时候需要使用CQRS?
答案 0 :(得分:50)
CQRS不是涵盖整个应用程序的模式。
这是一个基于域驱动设计(DDD)的概念。 DDD的一个重要战略概念是所谓的 Bounded Context 。
在典型的应用程序中,有多个有界上下文,其中任何一个都可以按照它的意义实现。例如
这可能无法解答您的问题,但可能会更深入地了解该主题。老实说,如果不考虑项目的具体细节,我认为根本不能回答,即便如此,很少有像最佳实践这样的东西。
答案 1 :(得分:28)
CQRL评论家可能会说CQRS很复杂,可能也是如此。
当然,它增加了开发CQRS样式的简单CRUD应用程序的开销,所以我考虑仅在以下情况下使用CQRS:
答案 2 :(得分:13)
当您拥有复杂或艰难的业务领域时:
或者您有需要对公共数据采取行动的用户:
或者您有可扩展性要求:
或者你有性能问题(可扩展性的另一面):
或者你有一个物理分离的团队:
CQRS不是过于复杂,而是计算机。
答案 3 :(得分:8)
何时使用CQRS设计模式?
当难以从存储库查询用户需要查看的所有数据时,可以使用CQRS体系结构模式。当UX设计创建跨越多个聚合类型和实例的数据视图时尤其如此。您的域越复杂,这就越真实。
当它不适合在UX设计上妥协时,使用CQRS会尝试减轻与其他解决方案相关的问题,例如:
总结:使用CQRS时难以从用户需要查看的数据库查询,这往往会发生您的域名越复杂。
答案 4 :(得分:5)
从我的观点来看,它增加了两个主要的好处。(与很多其他人一样)
答案 5 :(得分:1)
以下是使用CQRS的原因:
答案 6 :(得分:1)
在现实世界中,如果您的前端/ Web服务客户端需要来自多个域的大量数据并且从数据库中检索这些数据需要很长时间,那么CQRS可能会很有用。
在这种情况下,您可以考虑创建单独的读取模型,这种模型的开发速度更快,执行时间也更快。
答案 7 :(得分:0)
如果您发现问题域不太适合更通用的体系结构,或者您正在尝试域驱动设计,那么建议您尝试一下CQRS。
这是一个强大的模式,它可以使您充分了解问题领域,并解决一些技术和基础设施挑战。但是需要记住的是,它的价格会随之而来,并且由于与其他架构的概念差异,它需要进行思维模式的转变。
答案 8 :(得分:0)
在以下情况下使用它:
https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs#when-to-use-this-pattern
答案 9 :(得分:-1)
关于实现CQRS,当您有一个前端/ Web服务客户端需要来自多个域的大量数据时,我喜欢分离读取模型的想法,我想尝试一下。我想尝试的主要原因是由于开发和执行过程中的“缓慢”问题。特别是在处理大型数据集或“大数据”时。我正在研究可用于降低复杂性,为混合体系结构增加可伸缩性,弹性和灵活性的所有可用选项。