CQRS na prática, introdução - Parte 1

Introdução

O padrão CQRS (Command query responsibility segregation) tornou-se um pilar na abordagem do DDD (Domain driven design), no entanto existem várias equívocos em torno do CQRS, principalmente quando aplica-se ao mundo real.

• Devos utilizar Event Sourcing?
• Devemos sempre ter bancos de dados separados para leitura e gravações?
• Devemos tornar a sincronização entre leituras e gravações assíncronas?

Entenderemos exatamente o que é o CQRS e pretendo ajuda-lo a responder essas perguntas nos próximos artigos.

CQRS e suas origens

Command and Query Responsibility Segregation, seu conceito é muito simples, em vez de termos modelos unificado, separamos em dois tipos de modelos, de leitura (Read Models) e escrita (Write Models), apesar de simples, essa diretriz leva a benefícios significativos, veremos esse benefícios mais adiante.

O CQRS foi introduzido por Greg Young em 2010, Greg usou como base a ideia de Bertrand Meyer, CQS - Command Query Separation Principle, esse padrão indica que cada método deve ser um comando que executa uma ação (Produz efeitos colaterais) e consultas (Não produzem efeitos colaterais). Um comando sempre deve retornar vazio, e uma consulta não vazio. Isso irá permitir aumentar a legibilidade do código fonte, pois, poderemos entender o propósito do método somente observado sua assinatura, sem necessidade de mergulhar em detalhes de implementação.

• Um efeito colateral é quando uma função depende ou modifica algo fora de seus parâmetros para fazer algo. Por exemplo, uma função que lê ou escreve de uma variável fora de seus próprios argumentos, um banco de dados, um arquivo ou o console pode ser descrita como tendo efeitos colaterais

Nem sempre será possível seguir o princípio de separação entre comandos e consultas, existirá situações em que faria mais sentido para um método ter um efeito colateral e retornar algo. Nesse cenários excepcionais devemos não seguir o CQS, mas ele deve ser nossa base.

CQRS leve a mesma ideia do CQS e a levar para um nível mais alto. Em vez de afetas somente os métodos como o CQS, o CQRS também se concentra-se no modelos e nas classes desse modelo, e em seguida, aplica os mesmo princípios a eles.

Por que utilizar o CQRS, quais os benefícios?

• Escalabilidade.
  • Na maioria dos sistemas, as operações de leituras são muito mais utilizadas do que as de escrita, portanto, é importante escalá-las independentemente umas das outras. Podemos escalar de maneira assimétrica, por exemplo, utilizando 1 servidor para comandos e 10 para consultas
• Performance
  • É relacionado à escalabilidade, mas não é a mesma coisa. Mesmo que desejemos hospedar leitura e escrita no mesmo servidor, ainda poderemos aplicar técnicas de otimização que não seriam possíveis com um único modelos unificado. Como por exemplo, utilizar cache, otimizar nossas consultas SQL
• Simplicidade
  • O principal benefício, lados comando e consulta, tem uma necessidade bem diferentes, e tentar criar um modelo unificado para essa necessidade sempre resultará em um modelo complicado que não lida bem com nenhuma dessas duas partes. Aplicamos o SRP (Single Responsability Principal) em um nível arquitetural, assim diminuindo bastante a complexidade do nosso código que antes precisava lidar com duas intenções e agora liderar somente com uma, ou escrita, ou leitura.

CQRS é sobre otimizar decisões para diferentes situações.