CQS (Command Query Separation) × CQRS (Command Query Responsibility Segregation)

Em uma frase

CQS é uma regra sobre métodos: ou muda o estado, ou devolve resposta — nunca os dois. CQRS leva a mesma ideia para a arquitetura: dois modelos separados, com caminhos, e às vezes bancos, distintos para leitura e escrita. Um cabe numa classe; o outro muda o desenho do sistema.

Critério a critério

Pergunta	CQS (Command Query Separation) (lado A)	CQRS (Command Query Responsibility Segregation) (lado B)
Qual é a unidade?	O método. `carrinho.adicionar(item)` não devolve o total.	O modelo. Um lado atende comandos, outro atende consultas.
Quanto custa adotar?	Quase nada. É disciplina de assinatura, aplicável hoje, em qualquer código.	Bastante. Dois modelos para manter, sincronização entre eles e um sistema mais difícil de depurar.
Precisa de infraestrutura nova?	Nenhuma. É uma decisão que cabe dentro de um arquivo.	Quase sempre: projeção, fila ou réplica de leitura para alimentar o lado de consulta.
O que se ganha?	Código previsível: dá para chamar uma consulta sem medo de efeito colateral.	Escalar leitura e escrita separadamente, e modelar cada lado para o que ele realmente faz.
E a consistência?	Não muda nada — tudo continua no mesmo modelo e na mesma transação.	Costuma virar eventual: o lado de leitura fica atrás do de escrita por um intervalo, e a interface precisa assumir isso.
Quando surgiu?	1988, com Bertrand Meyer, como princípio de projeto de objetos.	Por volta de 2010, com Greg Young, levando o princípio à escala arquitetural.

Qual é a unidade?
CQS (Command Query Separation)
O método. carrinho.adicionar(item) não devolve o total.
CQRS (Command Query Responsibility Segregation)
O modelo. Um lado atende comandos, outro atende consultas.
Quanto custa adotar?
CQS (Command Query Separation)
Quase nada. É disciplina de assinatura, aplicável hoje, em qualquer código.
CQRS (Command Query Responsibility Segregation)
Bastante. Dois modelos para manter, sincronização entre eles e um sistema mais difícil de depurar.
Precisa de infraestrutura nova?
CQS (Command Query Separation)
Nenhuma. É uma decisão que cabe dentro de um arquivo.
CQRS (Command Query Responsibility Segregation)
Quase sempre: projeção, fila ou réplica de leitura para alimentar o lado de consulta.
O que se ganha?
CQS (Command Query Separation)
Código previsível: dá para chamar uma consulta sem medo de efeito colateral.
CQRS (Command Query Responsibility Segregation)
Escalar leitura e escrita separadamente, e modelar cada lado para o que ele realmente faz.
E a consistência?
CQS (Command Query Separation)
Não muda nada — tudo continua no mesmo modelo e na mesma transação.
CQRS (Command Query Responsibility Segregation)
Costuma virar eventual: o lado de leitura fica atrás do de escrita por um intervalo, e a interface precisa assumir isso.
Quando surgiu?
CQS (Command Query Separation)
1988, com Bertrand Meyer, como princípio de projeto de objetos.
CQRS (Command Query Responsibility Segregation)
Por volta de 2010, com Greg Young, levando o princípio à escala arquitetural.

Quando escolher cada um

CQS (Command Query Separation)

Sempre. É um princípio de baixo custo que torna qualquer código mais previsível, e não pede nada em troca.

Ver o conceito completo

CQRS (Command Query Responsibility Segregation)

Quando leitura e escrita divergem de verdade — em volume, em formato ou em ritmo de mudança — e você aceita pagar consistência eventual por isso.

Ver o conceito completo

Por que confundem

A sigla parecida esconde uma diferença de ordem de grandeza: uma letra a mais custa um sistema distribuído. O erro caro é adotar CQRS por elegância, sem que leitura e escrita realmente divirjam — aí sobram dois modelos para manter, uma projeção para sincronizar e um bug de consistência eventual, em troca de nenhum ganho. O caminho honesto é aplicar CQS em todo lugar desde já, e só considerar CQRS quando existir um problema medido que o justifique.