何时使用 CQRS 设计模式? [英] When to use the CQRS design pattern?

问题描述

我和我的团队一直在讨论使用 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 使用，但我们对此充满信心我们了解它的优缺点

we haven't seen enough uses of CQRS in the field yet to be confident that we understand its pros and cons

那么你们认为什么时候出现问题需要使用 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 设计模式?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！