CQRS

CQRS significa Command Query Responsibility Segregation. A ideia é separar o que muda dados (comandos) do que apenas lê dados (queries). Em vez de um único modelo fazer tudo, você usa caminhos diferentes para escrita e leitura.

O modelo tradicional

Na maioria dos sistemas, o mesmo modelo lê e escreve:

App  <-->  Modelo único  <-->  Banco

Funciona bem na maioria dos casos. CQRS entra quando leitura e escrita têm necessidades muito diferentes.

Com CQRS

Comando (escrita)        Query (leitura)
     |                        |
[ Modelo de escrita ]   [ Modelo de leitura ]
     |                        |
  Banco escrita    --->   Banco leitura
                  (sincroniza)

• Comando: “criar pedido”, “cancelar”. Altera estado. Não devolve dados.
• Query: “listar pedidos do cliente”. Só lê. Não muda nada.

Exemplo

// Comando
criarPedido({ cliente, itens })   // muda o estado

// Query
buscarPedidosDoCliente(clienteId) // só lê

Cada lado pode ter seu próprio formato de dados. A leitura pode usar uma tabela já pronta e otimizada para exibição, enquanto a escrita mantém as regras de negócio.

Vantagens

• Leitura e escrita escalam de forma independente.
• Consultas rápidas com modelos feitos sob medida.
• Regras de escrita ficam limpas e focadas.

Desvantagens

• Mais complexidade: dois modelos para manter.
• Sincronizar os lados gera consistência eventual.
• Pode ser exagero para CRUD simples.

Quando usar

CQRS vale a pena quando:

• Há muito mais leitura que escrita (ou o contrário).
• As consultas são complexas e diferentes do formato de gravação.
• Você precisa escalar leitura e escrita separadamente.

Para um cadastro comum, não use. A separação só compensa quando a diferença entre ler e escrever é real e grande.