Por Mickael Maison
Command query responsibility segregation (CQRS) é um padrão de arquitetura de aplicativo. Esse padrão é regularmente usado em aplicativos ativados por eventos e frequentemente associado à orientação a eventos (event sourcing). Consiste em separar a lógica relacionada a comandos daquela associada a consultas.
O padrão de arquitetura CQRS
Vamos começar definindo o que são comandos e consultas. Em sua forma mais simples, um comando é uma operação que altera o estado do aplicativo, enquanto uma consulta é uma operação que lê o estado do aplicativo.
Em um aplicativo, os dados são representados por meio do uso de modelos. Tradicionalmente, para um domínio definido, é usado um único modelo que guia todas as operações (criar, ler, atualizar e excluir, ou seja, as operações CRUD). No entanto, de acordo com a evolução dos requisitos, o modelo pode se tornar complexo e incontrolável.
Ao dividir os comandos e as consultas, o padrão de arquitetura CQRS permite que os desenvolvedores usem modelos diferentes para ler e gravar dados.
Por exemplo, se considerarmos um serviço que esteja gerenciando pedidos:
OrderService:
* `createOrder()`
* `updateOrder()`
* `cancelOrder()`
* `getAllOrders()`
* `getOrdersForCustomer()`
Se você aplicar o padrão CQRS, os serviços se tornarão OrderCommandService e OrderQueryService:
OrderCommandService:
* `createOrder()`
* `updateOrder()`
* `cancelOrder()`
OrderQueryService:
* `getAllOrder()`
* `getOrdersForCustomer()`
Essencialmente, o padrão CQRS consiste em simplesmente separar os lados do comando e da consulta. Na prática, o grau de separação pode variar da presença de dois modelos dentro de um aplicativo até a presença de dois aplicativos.
A ideia de separar comandos e consultas também tem origem no fato de ser relativamente comum que ambos sejam usados por diferentes atores ou em diferentes escalas. Por exemplo, no OrderService descrito acima, os clientes usariam principalmente os comandos, enquanto a empresa oferecendo o serviço é quem usaria as consultas.
Com relação à arquitetura, um aplicativo de padrão CQRS pode se assemelhar a isso:
Arquitetura do padrão CQRS
Nesse caso, os comandos registram atualizações no Apache Kafka nos tópicos correspondentes. No lado da consulta, o Kafka Streams pode ser usado para criar projeções (através de agregações ou junções) dos dados nos tópicos. Você pode explorar uma arquitetura orientada a eventos básica ou estendida no IBM Cloud Architecture Center.
Veremos na próxima seção os benefícios que isso pode ter em nossa arquitetura de aplicativos.
Por que usar o CQRS?
O CQRS fornece uma separação de conceitos e nos permite ter modelos mais simples focados em diferentes casos de uso. Em um aplicativo complexo, isso pode evitar um modelo único que se torna incontrolável em razão da lógica de validação complicada para gravações e de muitos objetos de transferência de dados (DTO) para leituras.
Esses modelos podem ser otimizados para leituras ou gravações e mapear de perto o padrão DTO. Cada modelo também pode ser sustentado por uma camada de persistência diferente, novamente otimizada para sua função. Por exemplo, o banco de dados de consulta pode ter visualizações materializadas correspondentes a DTOs sem a preocupação com o desempenho da gravação.
A separação de conceitos também garante que outro serviço que interaja com o lado da consulta não possa atualizar dados e tenha apenas acesso de leitura.
A outra razão pela qual o CQRS é usado com frequência é a escalabilidade. Quando temos dois serviços, eles podem ser dimensionados de forma independente para fornecer alto desempenho. Isso é especialmente relevante quando há uma disparidade ampla entre leituras e gravações.
Por exemplo, considere que uma empresa de transporte de contêineres possa receber milhares de pedidos de seus clientes ao longo do dia. Todavia, os pedidos serão recuperados apenas periodicamente a cada dia.
Outras considerações ao usar o CQRS
Como qualquer outro padrão de aplicativo, alguns cuidados devem ser tomados ao implementar um serviço usando o CQRS.
Primeiro, aplicar o CQRS a um serviço adiciona complexidade. Nos vemos com mais modelos para gerenciar e, se um microsserviço é dividido em duas partes, é necessário executar e gerenciar dois microsserviços.
Também em decorrência da natureza muito específica de seus benefícios, o CQRS deve ser aplicado apenas a serviços que exigem seus recursos. Na maioria dos casos, esse é um subconjunto muito pequeno de serviços.
Como há modelos separados para gravações e leituras, precisamos mantê-los sincronizados; portanto, quando um comando é processado, ambos os modelos de comando e de consulta são atualizados. Em muitos casos, isso conduz a sistemas que são eventualmente consistentes.
Resumo e próximos passos
Neste artigo, forneci uma visão geral de alto nível do padrão de arquitetura CQRS. Para saber mais sobre o padrão de arquitetura CQRS, assista ao vídeo “Criando microsserviços ativados por eventos: explore padrões de arquitetura orientados a eventos para seus aplicativos de microsserviços”. Para aprender sobre esse padrão com mais detalhes, explore a Unidade 6, a Unidade 7 e a Unidade 8 na série de tutoriais “Reativos na prática”, sobre a construção de sistemas reativos.
...
Quer ler mais conteúdo especializado de programação? Conheça a IBM Blue Profile e tenha acesso a matérias exclusivas, novas jornadas de conhecimento e testes personalizados. Confira agora mesmo, consiga as badges e dê um upgrade na sua carreira!
Categorias
