CQRS.

Use um modelo para atualizar informações e um modelo diferente para lê-las. Comandos expressam a intenção de alterar o estado; consultas retornam dados formatados para exibição. Os dois não precisam mais fazer concessões em torno de uma única representação compartilhada.

Em um design tradicional, um único modelo atende tanto escritas quanto leituras. As escritas precisam de validação rica e invariantes; as leituras precisam de formatos desnormalizados e prontos para exibição — muitas vezes vários diferentes para diferentes telas e relatórios.

Forçar ambos através dos mesmos objetos e tabelas leva a concessões desajeitadas: over-fetching, mapeamentos ORM complexos, contenção de locks e um modelo que não é bom em nenhuma das duas tarefas.

O CQRS divide o sistema em dois. O lado de escrita trata os comandos por meio de handlers que carregam um agregado, impõem invariantes e persistem a mudança (opcionalmente emitindo eventos). O lado de leitura serve as consultas a partir de um ou mais read models formatados especificamente para as views que os consomem.

Os dois lados podem compartilhar um banco de dados ou usar stores separados. Quando estão separados, os read models são mantidos atualizados projetando os eventos do lado de escrita, aceitando consistência eventual em troca de escalabilidade independente e consultas mais simples.

• Comando — uma requisição para alterar o estado, nomeada pela intenção (PlaceOrder).
• Command handler — valida e aplica o comando ao write model.
• Write model — agregados que impõem invariantes; podem emitir eventos.
• Read model / projeção — views desnormalizadas construídas para consultas, atualizadas a partir de eventos.
• Query & query handler — requisições somente de leitura servidas a partir do read model.

• Use-o onde leituras e escritas têm formatos ou cargas muito diferentes — muitas views de leitura, relatórios pesados ou uma alta razão entre leitura e escrita.
• Use-o em UIs baseadas em tarefas e domínios colaborativos, onde ele combina naturalmente com Domain-Driven Design e event sourcing.
• Evite-o em CRUD simples; um único modelo é mais simples e a divisão adiciona custo sem retorno.

1. Modele os comandos como intenções explícitas em vez de atualizações genéricas.
2. Roteie cada comando para um handler que carrega o agregado relevante e impõe suas invariantes.
3. Persista a mudança e, se estiver usando eventos, publique o que aconteceu.
4. Construa read models adequados às suas views; se separados, atualize-os projetando eventos.
5. Sirva as consultas diretamente a partir dos read models — sem lógica de domínio no lado de leitura.