Conhecendo o padrão CQS
Já faz bastante tempo que não escrevo o intervalo entre um artigo e outro tem sido cada vez maior e estou tentando diminuir isso.
Hoje vou escrever sobre um padrão que não ouvimos falar com tanta frequência chamado CQS (Command Query Separation). A primeira pessoa a falar sobre esse padrão foi o francês Bertrand Meyer em seu livro Object-Oriented Software Construction em Março de 2000.
Antes de continuar lendo esse artigo, eu recomendo fortemente também a leitura do artigo escrito pelo Martin Fowler.
Introdução.
O CQS é um padrão extremamente simples em sua teoria porém muito poderoso e segue apenas dois princípios como base.
Todo método deve ser uma Command quando esse método executar alguma ação que cause uma mudança de estado em sua aplicação ou uma Query quando você precisar que informações sejam retornadas porém nunca os dois.
Para tentar clarear um pouco mais essa ideia, vamos olhar a interface abaixo
Olhando calmamente para o trecho de código acima conseguimos notar que temos dois métodos que retornam valores Query e apenas um método que não tem retorno Command que provoca mudanças de estados em nossa aplicação.
Seguindo esses dois princípios básicos não vamos ter grandes problemas durante a implementação para além disso nós teremos alguns benefícios tais como:
- Código Coeso e legível
- Teremos uma maior flexibilidade para testar
- Maior facilidade para manutenção
Mas CQS e CQRS não são a mesmas coisa?
Essa é uma dúvida constante, nos dias de hoje ouvimos muito falar sobre CQRS para tudo que é lado e apesar desses dois padrões estarem relacionados eles não são a mesma coisa e não resolvem os mesmos problemas.
Quando nós falamos de CQS estamos falando de uma separação lógica do nosso modelo entre escrita e leitura. E quando nós falamos de CQRS para além de termos essa separação lógica do nosso modelo de escrita e leitura nós vamos além, e temos uma separação a nível arquitetural onde os objetos de escrita e leitura tem caminhos diferentes.
Não entrarei em detalhes sobre o padrão CQRS nesse artigo, pois é um assunto complexo e muito extenso, mas se você tem curiosidades sobre esse tópico eu deixarei aqui alguns links de referência para o mesmo.
Prós e Contras de trabalhar com CQS
Como tudo dentro do processo de engenharia de software temos os prós e contras e ter conhecimento do trade-off do padrão ou tecnologia que estamos trabalharmos é que nos ajuda a tomar a decisão correta sobre uma implementação.
Farei uma lista curta de prós e contras que mais me chamam atenção e caso você veja algum outro caso que seja pertinente e quiser compartilhar sinta-se a vontade para deixar um comentário :)
Prós
- Separação de conceitos
- Facilidade para escrever testes de unidade
- Facilidade de manutenabilidade e optimização de performances em casos necessários.
Contras
- Em aplicações teremos uma grande quantidade de classes tanto de Command quanto de Query.
- Se você for do tipo de programador purista e quiser seguir padrão a risca provavelmente terá algumas chamadas excessivas ao seu servidor.
Uma Command deve ter retorno?
Uma pausa na parte legal para falarmos sobre polêmicas, pois sempre precisamos ter algo discutível dentro dos padrões.
Em sua essência uma Command deve apenas alterar o estado da sua aplicação e não deve ter retorno em hipótese alguma.
Porém ao olharmos para um cenário comum no dia a dia de um desenvolvedor, onde precisamos retornar o Id que foi gerado para a entidade salva e retornar para quem gerou essa mudança de estado. Para os mais puristas seria um crime fazer com que os objetos de Command retornassem um valor.
Já participei em diversas discussões sobre esse tipo de tópico com alguns amigos conhecidos tais como José Roberto Araújo e Robson Castilho e depois de muita conversa cheguei a uma conclusão pessoal.
Temos soluções elegantes para resolver esse tipo de problemas em alguns cenários, por exemplo quando trabalhamos com NHibernate podemos fazer uso do Hilo para obter os ids a partir de um pool, se você quiser saber mais tem um post muito interessantes do Vladimir Khorikov entretanto nem sempre trabalhamos com NHibernate e nesses casos eu consigo abrir mão do purismo para poder ser pragmático.
Visualizando o padrão CQS
Em um próximo post vamos ver como implementar o padrão em uma aplicação de exemplo.
A aplicação de exemplo irá seguir o padrão que estamos abordando nesse artigo e podemos ver algumas outras ferramentas que estamos utilizando para tornar as coisas um pouco mais interessantes.
Antes de começarmos a escrever código, vamos dar uma olhada para os dois desenhos que representam a arquitetura da aplicação.
Conclusão
A ideia desse artigo foi mostrar de forma simples o que é o padrão CQS (Command Query Separation) e quais são os conceitos básicos e potenciais trade-offs que nós podemos encontrar em uma implementação.
É um conceito que tenho utilizado em diversos projetos onde consigo ver aplicabilidade e as vantagens que tenho tido ao longo dos projetos são inumeras, porém preciso ser sincero que se for algo extremamente simples você não irá ver vantagens em utilizar o padrão uma vez que ele trás um boiler plate considerável de classes e interfaces.
Espero que você tenha gostado da primeira parte desse tópico, caso tenha alguma dúvida ou sugestão adorarei saber sobre.
Referências
