问题描述
我和我的团队一直在讨论使用 CQRS(命令查询职责分离)设计模式,我们仍在尝试评估使用它的利弊.根据:http://martinfowler.com/bliki/CQRS.html
My team and I have been discussing using the CQRS (Command Query Responsibility Segregation) design pattern and we are still trying to asses the pros and cons of using it. According to: http://martinfowler.com/bliki/CQRS.html
我们在该领域还没有看到足够多的 CQRS 使用,但我们对此充满信心我们了解它的优缺点
那么你们认为什么时候出现问题需要使用 CQRS?
So what do you guys think, when does a problem call for using CQRS?
推荐答案
CQRS 不是一个包含整个应用程序的模式.
CQRS is not a pattern that encompasses the whole application.
这是一个建立在领域驱动设计 (DDD) 之上的概念.DDD 的一个重要战略概念是所谓的有界上下文.
It is a concept that builds on Domain Driven Design (DDD). And an important strategic concept of DDD is the so-called Bounded Context.
在典型的应用程序中,有多个有界上下文,其中任何一个都可以按照有意义的方式实现.例如
In a typical application there are multiple bounded contexts, any of which can be implemented the way it makes sense. For instance
- 用户管理 -> CRUD
- 发票 -> CRUD
- 保险单管理(核心领域)-> CQRS
- ...
这可能无法回答您的问题,但它可能会让您更深入地了解该主题.老实说,如果不考虑项目的具体情况,我认为根本无法回答这个问题,即便如此,也很少有明确的最佳实践.
This probably doesn't answer your question but it might give a little more insight into the topic. To be honest, I don't think it can be answered at all without considering a project's specifics, and even then there is rarely something like a definite best practice.
这篇关于何时使用 CQRS 设计模式?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!