Pular para o conteúdo
thiagoetipadrões

Contatos

apps/data-patterns/cqrs

078 · Dados & Persistência · ≈ 5 min de estudo

CQRS (Command Query Responsibility Segregation)

Separa a escrita (commands) da leitura (queries) em modelos distintos. O command side grava num modelo normalizado e valida as regras de negócio; o query side lê um modelo desnormalizado e pré-calculado, sem JOIN nem agregação na hora da consulta. Use quando leitura e escrita têm forma ou carga muito diferentes.

passos
5
arquivos
8
teste
1
tecnologias
4
Infraestrutura realTypeScriptBunPostgreSQLDocker
CenárioRelaçõesComparar
Baixar cartão

Cenário

Conta corrente de banco digital: depósitos e saques entram no livro de transações (write model). O app consulta saldo, totais do mês e extrato com saldo após cada lançamento — consultas muito mais frequentes que os lançamentos, servidas pelo read model sem recalcular nada.

Planta

Sequência
11/11
saque de R$ 200,001SELECT balance_cents FOR UPDATE2saldo real, conta travada3UPDATE accounts e INSERT transactions4AFTER INSERT5atualiza resumo e grava linha do extrato com saldo após6COMMIT (os dois modelos juntos)7saldo e extrato8SELECT sem JOIN nem SUM9valores pré-calculados10resumo e extrato11read model apagado é reconstruído pelo replay do write modelClienteCommand sideWrite model(accounts, transactions)TriggerRead model(account_summaries, statement_lines)Query side
11

11 passos — reproduza para seguir o fluxo

Como funciona

5 passos

Comandos e consultas em modelos separados.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

INSERT+3
JOIN+2
  1. 01

    O command side abre a transação e trava a linha da conta com SELECT ... FOR UPDATE

  2. 02

    A regra de saldo é validada contra o write model travado, nunca contra o read model

  3. 03

    O INSERT em transactions dispara o trigger, que atualiza account_summaries e grava a linha em statement_lines na mesma transação

  4. 04

    O query side lê só o read model, por um pool próprio, sem JOIN nem SUM

  5. 05

    O read model não é fonte de verdade: accountProjectionRebuild o apaga e reconstrói pelo replay de transactions

apps/data-patterns/cqrs

8 arquivos

sql/

  • 01_schema.sqlschemaWrite model, read model e triggers de projeção

src/

  • config_account.tsVariáveis de ambiente validadas no boot
  • pool_account.tsUm pool por lado e transactionExecute
  • command_account.tsAbertura, depósito e saque com a regra de saldo
  • query_account.tsResumo e extrato lidos do read model
  • projection_account.tsReconstrução do read model pelo write model
  • demo.tsdemoFluxo completo, recusa de saque e reconstrução
  • command_account.test.tstesteProjeção, limite de saldo, concorrência e reconstrução contra PostgreSQL real

Executar · com Docker

  1. ./docker.sh up# sobe PostgreSQL
  2. bun install# dependências
  3. bun run demo# roda o cenário
  4. bun run test# integração contra o serviço real
Requisitos
BunDocker
Sobe junto
PostgreSQL

Relações

Onde ele se encaixa

Mapa
  1. vem antesSnapshot Pattern
  2. CQRS
  3. próximo passoMaterialized View
  • Vem antes1
  • Próximo passo1
  • Combina com5

L5Eventos e histórico· estação 5 de 6

← Snapshot PatternMaterialized View →

Também implementado em

Por que se relacionam

Vem antes

Próximo passo

Combina com

Teste rápido

Qual é o próximo passo depois de CQRS?

Próximo projeto · Dados & PersistênciaEvent Sourcing
Esc

↑ ↓ navegarEnter abrir191 resultados