O padrão de arquitetura CQRS

Fala pessoal tudo tranquilo? Desta vez trago um assunto mais voltado para a arquitetura de soluções, entenderemos o padrão CQRS. Vamos lá?

O CQRS (Command Query Responsibility Segregation) é um padrão de arquitetura definido pelo Greg Young e, que longo do tempo vem atraindo á atenção dos desenvolvedores e arquitetos em todo mundo.

Para um melhor entendimento deste padrão vamos revisitar primeiro outro padrão o CQS (Command Query Separation) que foi mencionado por Bertrand Meyer em seu livro Object-Oriented Software Construction.

A ideia que Meyer traz é basicamente identificar o propósito de cada método que escrevemos. Segundo ele o método pode ser um Command ou uma Query. O método é um Command sempre que realizamos uma ação em que alteramos o estado de um objeto ou em casos onde é gerado um efeito colateral no sistema. Por outro lado, um método se caracteriza como Query sempre que ele retorna algum valor, Meyer prega que o método deve ser um comando ou uma consulta e nunca as duas coisas ao mesmo tempo.

Para exemplificar melhor o conceito observe a classe CqsRepository na qual temos dois métodos, o método getCpf, que é uma consulta, ou seja, não altera o estado da aplicação e não gera nenhum efeito colateral caracterizando assim uma Query, e também o método save que realiza a persistência dos dados no banco gerando um efeito colateral sendo assim caracterizado como um método Command.

Quando Greg Young propôs o CQRS a ideia foi seguir o mesmo conceito do CQS, porém, pensando em requisições para o servidor, onde o Command são as operações que vão alterar o estado no servidor ou gerar um efeito colateral. Realizado um paralelo os verbos HTTP, são verbos como POST, PUT e DELETE. No caso da Query, elas as requisições que realizam uma consulta no servidor, e, fazendo novamente um paralelo com os verbos HTTP neste caso o verbo GET se caracterizaria como Query,, pois em tese seriam operações onde não realizam alterações no servidor. O conceito é o mesmo que no CQS, porém a proposta de Young vai um pouco além de apenas segregar Command e Query. Observe o diagrama abaixo.

No diagrama podemos observar uma camada de “interface” realizando as requisições para o servidor, isso é realizado de forma segregada entre Query e Command, assim como havíamos mencionado anteriormente. Porém podemos observar que a segregação também se dar por aplicações, formando assim uma stack para as operações do tipo Query e uma stack para as operações do tipo Command, o que permite realizar um processamento diferente para cada stack, podendo realizar também uma melhor otimização para cada operação. Por exemplo, nas operações do tipo Query é possível realizar a consulta a fonte de dados mais leve sem a necessidade de recorrer ao domínio para isso, já no caso das operações do tipo Command poderíamos recorrer ao uso de mensageria de modo a termos mais escalabilidade. Young defende também a segregação de banco de dados, uma para as operações de Command e outro para as operações de Query.

CQRS junto com Event Sourcing

Event Sourcing é outro padrão de arquitetura que postula que devemos guardar os estados de uma entidade desde a sua criação. Para cada Command relacionado a entidade guardaríamos o seu estado, gerando assim uma lista de evento executado ao longo do tempo para esta entidade. Greg Young prega a utilização deste padrão em conjunto como o CQRS guardando os eventos da stack de Command.

O CQRS se encaixa bem com modelos de programação baseados em eventos . É comum ver o sistema CQRS dividido em serviços separados que se comunicam com a Colaboração de Eventos . Isso permite que esses serviços tirem proveito facilmente do Event Sourcing. — Martin Fowler

Embora Young recomende o uso do CQRS em conjunto com Event Sourcing, existe uma grande discussão na comunidade sobre que, não necessariamente os dois padrões devem ser implementados juntos, e sim deve ser avaliada a ocasião, sendo possível a implementação do CQRS sem o Event Sourcing de forma separada dependendo do caso.

Vantagens

Utilizar o CQRS possibilita customizar o pipeline de Consultas e de Alterações separadamente, e isso traz algumas vantagens, como:

• Dimensionamento independente: A atividade de leitura tende a ser mais frequente do que a gravação, portanto, você pode reduzir a latência de resposta usando diferentes técnicas de acesso ao banco de dados para leitura e atualização. Por exemplo: usar um banco de dados relacional para o lado da gravação e usar o banco de dados NoSQL para o lado da leitura.
• Orientação por domínio: O CQRS é adequado para domínios complexos e se encaixa nos modelos que usam DDD (Domain driven design).

Desvantagens

Embora o CQRS seja um bom padrão de arquitetura ele também tem desvantagens. Uma delas é o Aumento da complexidade, ao usar vários bancos de dados para um mesmo serviço, já os dados precisarão de algum tipo de sincronismo.

Muitos sistemas de informação se encaixam bem com a noção de uma base de informações que é atualizada da mesma forma que é lida, adicionar CQRS a tal sistema pode adicionar complexidade significativa. — Martin Fowler

Considerações

O CQRS é um padrão de arquitetura, e assim como qualquer outro padrão de “software”, pode se enquadrar em algumas situações e em outras nem tanto assim. Portando é necessário avaliar qual é o problema que você deseja solucionar ao adicionar este padrão de arquitetura em seu projeto. Caso queria se aprofundar mais no assunto, irei deixar aqui o link de um documento escrito pelo próprio Greg Young, no qual ele apresenta todos os detalhes do CQRS, Grande abraço e até a próxima.

https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf