O padrão de arquitetura CQRS (Command Query Responsibility Segregation) vem recebendo destaque em vários blogs importantes, incluindo os de Martin Fowler e Udi Dahan. Além de rever os conceitos do padrão, esses autores analisam a sua aplicabilidade em várias situações e sua evolução ao longo do tempo.
O padrão CQRS foi documentado originalmente por Greg Young, durante a implementação de projetos utilizando os conceitos de Domain Driven Design (veja um resumo do funcionamento do padrão na figura abaixo). Em seu blog, Udi Dahan já tinha analisado em detalhes o padrão e recentemente publicou opiniões sobre quando utilizá-lo. O blog de Martin Fowler também abordou o padrão focando em sua aplicabilidade .
O padrão CQRS descreve como separar as operações de leitura e escrita em diferentes modelos, conforme mostra a figura abaixo, extraída do artigo de Fowler. No cenário ilustrado, há uma interface gráfica ("UI") que dependendo da ação do usuário e pode executar opções de leitura ou escrita de dados. Para cada operação, o serviço (Service Interfaces) pode interagir com modelos diferentes, um para operações de leitura (Query Model) e outro para Comandos (Command Model), que por sua vez compartilham uma base de dados em comum.
Segundo Fowler, conforme o modelo de domínio de um sistema torna-se mais sofisticado, é natural acrescentar novos comportamentos aos objetos, perdendo-se o foco no modelo proposto. Fowler diz:
Com a adição de novas regras de leitura ou escrita, começamos a ver múltiplas representações das informações. Quando os usuários interagem com as informações, utilizam várias representações diferentes. Desenvolvedores geralmente constroem seu próprio modelo conceitual e o utilizam para manipular os elementos principais do modelo. Se você está utilizando um modelo de domínio, então ele é geralmente uma representação conceitual do negócio e tipicamente define a estrutura de dados mais próxima possível do modelo conceitual.
Essa estrutura com múltiplas camadas de representação pode se tornar bastante complexa, mas quando os modelos evoluem dessa maneira o problema pode ser resolvido criando-se uma representação conceitual única, que funcione como um ponto de integração entre todas as apresentações.
Udi Dahan explica que o padrão CQRS não deve ser utilizado em qualquer ocasião e que tem visto muitos usos indevidos. Ele separa as arquiteturas em dois grupos e sugere um novo termo para melhorar o entendimento do padrão:
Se você esta na área de Domain-Driven Design, então estamos falando de Contextos Limitados (Bounded Contexts). Se está na área de SOA Orientado a Eventos, estamos falando de serviços. [...] O problema está na nomenclatura, pois as pessoas de DDD usam tipos diferentes de serviços, que não se enquadram na definição de serviço da abordagem de SOA Orientado a Eventos. Proponho o termo Componente Autônomo de Negócio (ABC) [...], cujo objetivo atende tanto ao Contexto Limitado do DDD como aos Serviços Autônomos do SOA.
Dahan relaciona o uso do ABC com o Princípio de Responsabilidade Única (SRP) da orientação a objetos, segundo o qual cada componente deve ser responsável por apenas uma funcionalidade e que ela seja a única origem de mudanças nesse componente. Quando há mais de um motivo para se alterar um componente de negócio, isso indica que o componente tem mais responsabilidades do que deveria. Neste caso, deve-se considerar a separação dessas responsabilidades em dois ou mais componentes. Assim, quando alguma regra mudar, saberemos exatamente onde fazer as alterações.
Ao relacionar o Princípio de Responsabilidade Única com ABC, Dahan diz:
Se um Componente Autônomo de Negócio (ABC) é responsável por um conjunto de dados, ele tem essa mesma responsabilidade onde quer que esteja e para sempre. Nenhum outro ABC deve ver estes dados e os dados não devem trafegar entre ABCs, seja através de chamadas de procedimentos remotos (RPC) ou via publish/subscribe. O ABC é o último nível de encapsulamento; podemos dizer que é o Princípio de Responsabilidade Única aplicado ao nível mais alto de granularidade.
Isto gera sistemas cujo resultado é a implantação no mesmo local físico de componentes compostos de múltiplos ABCs. Um ABC responsável pelo nome do cliente deve ter o código necessário para apresentar esta informação, tanto em um sistema de comércio eletrônico quanto na impressão de etiquetas para transporte em um sistema logístico.
O autor destaca que o CQRS não deve ser utilizado como um padrão arquitetural no nível mais alto, e sim em um nível mais baixo de abstração, no nível de componentes. Dessa maneira, é possível separar a responsabilidade de comandos e consultas, ou criar de maneira efetiva dois caminhos através dos ABCs. Dahan conclui:
O CQRS é um abordagem, uma forma de pensar; não uma receita pronta. Frameworks que guiam você para aplicar o CQRS exatamente da mesma maneira em qualquer situação estão levando as pessoas na direção errada. O fato é que você provavelmente não saberia quais são as Aggregate Roots do seu modelo antes de saber como desmembrar seu sistema em ABCs. Tentar criar comandos e eventos para tudo irá tornar sua solução mais complicada do que o necessário.
Como foi apresentado, o CQRS é aplicável a grandes sistemas distribuídos e permite construir um aplicações mais escaláveis em termos de arquitetura. Para quem quiser se aprofundar mais no assunto, Greg Young criou um site com vários artigos e recursos sobre o CQRS.