Padrão CQRS

Wed, 01 Jan 2025 00:00:00 +0000

O que é

O padrão CQRS (Command Query Responsibility Segregation) é uma abordagem arquitetural que separa as operações de leitura e gravação em um sistema, permitindo a otimização independente de cada aspecto. Este modelo, introduzido por Greg Young, visa melhorar o desempenho, a escalabilidade e a manutenção de aplicações complexas.

Separação conceitual

No modelo tradicional (CRUD), usamos o mesmo modelo de entidade para ler e escrever:

// Modelo único — usado tanto para leitura quanto para escrita
@Entity
public class Cliente {
    @Id private Long id;
    private String nome;
    private String email;
    private String telefone;
    private LocalDate dataCadastro;
    // 10+ campos...
}

No CQRS, separamos em dois modelos distintos:

// COMMAND — usado apenas para escrever
public class CriarClienteCommand {
    private String nome;
    private String email;
    private String telefone;
}

// QUERY — modelo otimizado para leitura (pode ser uma projeção)
public class ClienteResumoDTO {
    private Long id;
    private String nome;
    // apenas os campos necessários para a view
}

Exemplo prático com Spring

// Command (escrita)
@Service
public class ClienteCommandHandler {
    @Autowired
    private ClienteRepository repository;

    public void handle(CriarClienteCommand cmd) {
        var cliente = new Cliente(cmd.nome(), cmd.email(), cmd.telefone());
        repository.save(cliente);
    }
}

// Query (leitura) — pode usar uma projeção JPA
public interface ClienteQueryRepository extends JpaRepository<Cliente, Long> {
    // Projeção fechada — busca apenas os campos necessários
    <T> List<T> findByOrderByNome(Class<T> projection);
}

Cenários onde aplicar o CQRS

O padrão CQRS é uma abordagem arquitetural que pode trazer benefícios em cenários específicos e agregar complexidade em outros. Em geral ele traz benefícios em Sistemas de Alta Performance, pois permite otimizar o fluxo de leitura e escrita da melhor forma, inclusive a nível de banco de dados.

Não há uma única forma de aplicar ou biblioteca mágica que irá abstrair toda a complexidade. Optar por CQRS irá exigir uma correta modelagem tanto do cenário de leitura quanto de escrita e a revisão contínua dessa abordagem. Este padrão não exige aplicação em todos os domínios, então pode ser aplicado nos pontos que mais irão render benefícios, como performance ou organização da arquitetura.

Conclusão

O CQRS é um padrão poderoso para cenários onde leitura e escrita têm requisitos significativamente diferentes. Não é recomendado para CRUDs simples — a complexidade adicional só se justifica quando há ganhos reais de performance, escalabilidade ou organização.

Aprofunde seus conhecimentos:

Se você chegou até aqui e ficou curioso com este padrão, recomendo estes artigos que irão agregar mais conhecimento para que você possa de fato aplicar os conceitos:

Padrão REST: Entenda esse estilo arquitetural e aplique no seu projeto

Fri, 20 Aug 2021 00:00:00 +0000

Sobre o REST

Antes de tudo precisamos entender que o REST (Representational state transfer) não é uma ferramenta, biblioteca nem mesmo um protocolo de comunicação.

Na verdade ele é um estilo arquitetural utilizado para comunicação entre sistemas. Com outras palavras, podemos dizer que é um conjunto de princípios e definições que definem uma forma padronizada para realizar essa comunicação.

Conceitos importantes

Ele é fortemente ancorado pelo protocolo HTTP, fazendo uso padronizado de URLs, verbos, status, cabeçalhos e tudo mais que o HTTP nos fornece.
Embora seja mais comum a utilização do formato JSON, ele não é uma restrição do REST, podendo ser utilizado XML, HTML, imagem, texto, etc.
Se trata de uma comunicação Cliente-Servidor. Isso quer dizer que de um lado o Servidor se comporta como provedor do serviço, continuamente disponibilizando o serviço a ser acessado. Já no outro lado, podemos ter 0, 1 ou vários Clientes conectando por demanda sempre que precisarem acessar algum dos recursos disponibilizados pelo Servidor.

O HTTP

Métodos (ou Verbos) HTTP:

Cada método possui uma finalidade específica que deve ser respeitada para deixar claro aos clientes qual o efeito esperado. Os métodos mais utilizados são:

GET: usado para busca de informações. Não deve alterar dados no servidor.
POST: usado para criação de recursos no servidor.
DELETE: usado para remoção de recursos existentes no servidor.
PUT: usado para substituição de recursos previamente criados no servidor.
PATCH: usado para atualização parcial de recursos previamente criados no servidor.

Status de retorno:

Da mesma forma que os métodos. Os status code existentes no HTTP são utilizados. Os status mais utilizados são:

Status de sucesso:

Ou seja, a operação foi realizada:

200: acompanhada de retorno de informações.
204: sem informações de retorno.
201: com a criação de informações.
202: de forma assíncrona, ou seja, foi recebida para processamento.

Status de erro de cliente:

Ou seja, a operação não foi realizada, e a responsabilidade provavelmente é do cliente:

400: e o motivo provavelmente está no corpo da requisição.
404: pois a informação solicitada não existe.
422: pois houve falha em uma validação de negócio.
401: por falta de autenticação.
403: por falta de permissão.

Status de erro de servidor:

Ou seja, a operação não foi realizada, e a responsabilidade provavelmente é do servidor:

500: e o motivo provavelmente está no retorno da requisição.
503: pois o serviço está indisponível.
502: pois um serviço necessário está retornando algo inesperado.
504: pois um serviço necessário está demorando para responder.

Exemplo prático

Uma requisição REST para gerenciar usuários:

### Listar usuários
GET /api/usuarios
Accept: application/json

### Criar um usuário
POST /api/usuarios
Content-Type: application/json

{
    "nome": "João Silva",
    "email": "joao@email.com"
}

### Resposta esperada (201 Created)
HTTP/1.1 201 Created
Location: /api/usuarios/1
Content-Type: application/json

{
    "id": 1,
    "nome": "João Silva",
    "email": "joao@email.com"
}

### Buscar usuário específico
GET /api/usuarios/1
Accept: application/json

### Resposta esperada (200 OK)
HTTP/1.1 200 OK
Content-Type: application/json

{
    "id": 1,
    "nome": "João Silva",
    "email": "joao@email.com"
}

### Remover usuário
DELETE /api/usuarios/1

### Resposta esperada (204 No Content)
HTTP/1.1 204 No Content

Conclusão

REST é o estilo arquitetural dominante para APIs web. Seguir seus princípios — uso correto dos verbos HTTP, statelessness, recursos bem definidos — garante APIs previsíveis, testáveis e de fácil manutenção.

Mais informações:

Gosta de vídeo?

REST // Dicionário do Programador - Código Fonte TV:

O QUE É UMA API RESTful NA PRÁTICA? MATURIDADE DE RICHARDSON - Michelli Brito:

Arquitetura on Gilberto | GibaTech

Padrão CQRS

O que é

Separação conceitual

Exemplo prático com Spring

Cenários onde aplicar o CQRS

Conclusão

Aprofunde seus conhecimentos:

Padrão REST: Entenda esse estilo arquitetural e aplique no seu projeto

Sobre o REST

Conceitos importantes

O HTTP

Métodos (ou Verbos) HTTP:

Status de retorno:

Status de sucesso:

Status de erro de cliente:

Status de erro de servidor:

Exemplo prático

Conclusão

Mais informações:

Gosta de vídeo?