Monólito modular na prática

O problema

Tem time que olha para um backend grande e conclui rápido:

“precisamos quebrar isso em microservices”

Às vezes precisa mesmo.

Mas, em muita base, o problema vem antes:

• tudo conhece tudo
• regra de domínio atravessa módulos sem freio
• tabelas viram API interna informal
• pastas existem, mas não protegem nada

Isso não é “problema de monólito”.

É problema de fronteira.

Modelo mental

Monólito modular é uma forma de dizer:

vamos criar limites internos sérios antes de distribuir o caos em vários serviços

Esses limites costumam ser:

• contexto
• dependência explícita
• ponto claro de integração
• dono mais previsível

Não precisa parecer microservice em miniatura.

Precisa só impedir que o sistema continue virando uma sopa única.

O que modularizar de verdade significa

Modularizar não é:

• criar mais pasta
• colocar prefixo em arquivo
• inventar package interno que continua sendo acessado de qualquer lugar

Modularizar é conseguir responder:

• quais partes do sistema pertencem juntas?
• quais regras mudam no mesmo ritmo?
• quais módulos podem depender de quais?
• por onde uma parte fala com a outra?

Se isso não está claro, a estrutura é decorativa.

Separar por contexto costuma funcionar melhor

Muita base separa assim:

• controllers
• services
• repositories

globalmente.

Isso ajuda pouco quando o sistema cresce.

Porque tudo continua misturado por domínio.

Frequentemente funciona melhor separar por contexto:

• billing
• identity
• orders
• catalog

Dentro de cada contexto, você até pode ter handler, use case e repository.

Mas o limite principal não é o tipo do arquivo.

É o assunto do sistema.

Exemplo simples

Imagine um e-commerce interno.

Uma estrutura ruim:

• controllers/
• services/
• repositories/

com arquivos de pedidos, pagamentos, estoque e usuário todos convivendo no mesmo corredor.

Uma estrutura melhor:

• orders/
• payments/
• inventory/
• identity/

Cada contexto com suas próprias entradas, regras e persistência.

Agora já fica mais claro:

• quem depende de quem
• onde uma regra mora
• onde um vazamento está acontecendo

O que não fazer

Tem dois exageros comuns.

1. Fingir que cada módulo já é um microservice

Às vezes o time cria “contratos”, “SDKs” e “network-like boundaries” dentro do mesmo processo sem necessidade.

Isso pode virar teatro.

O módulo ainda está no mesmo deploy, no mesmo banco e no mesmo runtime.

Então a fronteira precisa ajudar a leitura e a mudança, não simular distribuição.

2. Deixar tudo livre porque “é tudo monólito mesmo”

Esse é o outro extremo.

Quando vale tudo:

• módulo importa o que quiser
• query atravessa qualquer contexto
• regra de negócio é reutilizada por cópia

o custo explode do mesmo jeito.

Como um senior pensa

Quem olha melhor para isso geralmente pergunta:

• qual contexto sofre junto?
• qual parte muda no mesmo ritmo?
• qual dependência está saudável e qual está vazando?
• estamos tentando resolver fronteira ou só rebatizar pasta?

Essa leitura costuma evitar duas decisões ruins:

• microservice cedo demais
• monólito bagunçado para sempre

Quando ficar no monólito ainda é melhor

Ficar no monólito ainda pode ser a melhor escolha quando:

• o time é pequeno
• o domínio ainda muda rápido
• a operação distribuída custaria mais do que ajudaria
• o principal problema ainda é acoplamento interno

Nesse cenário, o passo adulto não é “mais serviços”.

É “mais clareza”.

Ângulo de entrevista

Esse tema aparece quando perguntam:

• “como você organizaria esse backend?”
• “como quebraria isso sem reescrever tudo?”
• “quando microservice faz sentido?”

Resposta forte não glorifica distribuição.

Ela mostra prudência.

Algo como:

“Antes de distribuir, eu separaria o monólito por contextos reais do domínio, com dependências mais explícitas e menos vazamento entre módulos. Isso já reduz acoplamento e facilita evoluir depois, inclusive se virar necessário extrair serviço no futuro.”

Isso transmite uma coisa importante:

você sabe melhorar arquitetura sem comprar complexidade cedo demais