BT
x Por favor preencha a pesquisa do InfoQ !

Padrão de arquitetura CQRS: quando utilizar?

por Wagner Santos em 28 Nov 2011 |

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.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

Percebemos que você está utilizando um bloqueador de propagandas

Nós entendemos porquê utilizar um bloqueador de propagandas. No entanto, nós precisamos da sua ajuda para manter o InfoQ gratuito. O InfoQ não compartilhará seus dados com nenhum terceiro sem que você autorize. Procuramos trabalhar com anúncios de empresas e produtos que sejam relevantes para nossos leitores. Por favor, considere adicionar o InfoQ como uma exceção no seu bloqueador de propagandas.