Pular para o conteúdo

apps/architecture/modular-monolith

033 · Arquiteturas de Alto Nível (Macro-Architecture) · ≈ 6 min de estudo

Monólito Modular

Um único processo e um único deploy, mas dividido em módulos por capacidade de negócio, cada um com API pública, schema e papel de banco próprios. Os módulos se falam por interface injetada ou por evento; nenhum toca o interno do outro. Use quando o domínio pede fronteiras claras sem pagar ainda o custo de rede dos microsserviços — cada módulo vira candidato a serviço depois.

passos
6
arquivos
7
teste
1
tecnologias
5
Infraestrutura realTypeScriptBunElysiaPostgreSQLDocker
Baixar cartão

Cenário

Banco digital com um só deploy e quatro módulos: accounts (saldos), fraud (análise de risco), payments (ledger de transferências) e notifications (mensagens ao cliente). O pagamento consulta a fraude e aplica a transferência em contas pela interface; a notificação reage ao evento de transferência concluída sem que pagamentos saiba que ela existe.

Planta

Fluxo
8/8
Um processo, um deployPostgreSQL, um schema e um papel por modulomain.tscomposition root + Elysiapaymentsindex.tsfraudindex.tsaccountsindex.tsnotificationsindex.tsshared/bus_eventaccounts.*accounts_modulepayments.*payments_modulenotifications.*notifications_moduleinterface, precisada respostainterface, precisada respostapayments.transfer.completed
8

8 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Um deploy, módulos com fronteiras fortes.

Esconde cada passo: lembre antes de tocar para revelar.

  1. 01

    Cada módulo expõe só index.ts (interface e factory); repository_*.ts é interno e nunca importado de fora

  2. 02

    main.ts é o único composition root: instancia os módulos e injeta as dependências — nenhum módulo cria outro

  3. 03

    Chamada direta pela interface quando a resposta é necessária agora (fraude, contas); evento no bus quando ninguém precisa responder (notificação)

  4. 04

    accounts aplica débito e crédito numa transação, uma vez por transferId; nenhuma FK cruza a fronteira de módulo

  5. 05

    Cada módulo conecta com o próprio papel do PostgreSQL, com GRANT só no próprio schema: ler o schema de outro dá permission denied

  6. 06

    module_boundary.test.ts falha se um arquivo importar o interno de outro módulo em vez do index.ts

Trade-offs

O que se ganha, o que se paga

4 vantagenscada ganho tem um preço4 custos

Vantagens

  • Chamada em memória, sem latência nem falha de rede

  • Fronteira verificada por teste de import e por grants no banco

  • Módulo evolui e é testado isolado

  • Extração para microsserviço módulo a módulo

Custos

  • Falha num módulo derruba o processo inteiro

  • Sem limite de CPU e memória por módulo

  • Sem transação entre módulos: idempotência por transferId

  • Disciplina contínua para não voltar ao acoplamento

apps/architecture/modular-monolith

7 arquivos

src/modules/accounts/

  • index.tsAPI pública de contas; repository_account.ts interno

src/modules/payments/

  • index.tsAPI pública de pagamentos; repository_transfer.ts interno

src/modules/fraud/

  • index.tsAPI pública de fraude, regra pura

src/modules/notifications/

  • index.tsReage ao evento e grava no próprio schema

src/shared/

  • bus_event.tsÚnico código compartilhado: o barramento de eventos

src/

  • main.tsComposition root e API HTTP do deploy único
  • module_boundary.test.tstesteGarante import só pelo index.ts

Executar · com Docker

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

Por que se relacionam

Teste rápido

Qual é o próximo passo depois de Monólito Modular?

Próximo projeto · Arquiteturas de Alto Nível (Macro-Architecture)Microsserviços
Esc

↑ ↓ navegarEnter abrir191 resultados