Visão geral
Sistema de pedidos dividido em dois microsserviços: um só escreve (Pedidos.Escrita.Api),
outro só lê (Pedidos.Leitura.Api), cada um com seu próprio banco PostgreSQL. A escrita
publica eventos de integração (pedido criado, confirmado, cancelado) via MassTransit/RabbitMQ;
a leitura consome esses eventos e projeta um modelo de leitura denormalizado, sem nunca
receber escrita direta. Isso é CQRS de verdade, no nível de serviço, não só de classe.
Arquitetura
Escrita valida regra de negócio no agregado Pedido (transições de status, exceções de
domínio), persiste e publica evento. Leitura consome o evento e atualiza sua própria tabela,
com checagem de idempotência (RabbitMQ entrega "pelo menos uma vez", não "exatamente uma
vez") e retry com backoff para lidar com evento fora de ordem entre filas diferentes.
Testes
29 testes automatizados: 18 de domínio puro, 6 do lado de escrita (MassTransit test harness in-memory, verifica publish do evento certo) e 5 do lado de leitura (os 3 consumers reagindo a evento, idempotência e evento fora de ordem). GitHub Actions builda e roda a suíte a cada push.
Sobre a infraestrutura real
Tem docker-compose.yml real (RabbitMQ + 2 Postgres + as 2 APIs) pra rodar com
docker compose up --build. Os testes automatizados usam o test harness in-memory do
MassTransit e o provider InMemory do EF Core em vez de subir os containers de verdade — isso
está documentado com clareza no README do repositório, junto com o porquê.
Stack
.NET 8, ASP.NET Core, MassTransit, RabbitMQ, Entity Framework Core, PostgreSQL, xUnit, Docker, GitHub Actions.