Nenhuma aplicação acorda monolítica no pior sentido da palavra. Ela chega lá por pequenas concessões: uma consulta direta “só desta vez”, uma regra copiada para ganhar prazo, um módulo que importa o interior de outro. Cada atalho parece barato sozinho. Juntos, transformam qualquer mudança em investigação.
O problema não é o número de linhas. É não saber onde uma decisão começa, quem pode alterá-la e o que será afetado.
Acoplamento cobra depois
Acessar uma tabela alheia poupa alguns minutos hoje, mas cria uma obrigação permanente. A partir dali, toda mudança no schema precisa lembrar daquele consumidor escondido. Multiplique isso por dezenas de fluxos e a velocidade inicial desaparece.
Dependências são normais. Dependências implícitas, circulares e apoiadas em detalhes internos é que tornam o sistema imprevisível.
Banco compartilhado pode ter dono
Um monólito modular pode usar o mesmo PostgreSQL sem transformar o schema em API pública. Cada módulo altera suas tabelas por meio de casos de uso próprios. Outros módulos consultam contratos deliberados.
- Propriedade: um módulo protege as mudanças dos seus dados.
- Invariante: a regra não pode ser contornada por um update externo.
- Contrato: o consumidor recebe o necessário, não acesso irrestrito.
- Transação: inclui apenas o que realmente precisa ser atômico.
Pastas por camada não bastam
Separar todos os controllers de todos os services organiza tecnologia, mas espalha uma feature pelo repositório inteiro. Prefiro módulos verticais por capacidade, ainda que cada um tenha camadas internas quando necessário.
Isso também evita a corrida para microsserviços. Primeiro vale provar a fronteira no código. Rede, consistência eventual e deploy independente só entram quando existe motivo operacional real.
O limite precisa funcionar
Na ANIMAPS, modularidade ajudou a manter o produto legível à medida que novas capacidades surgiram. Na KasbHealth, uma fronteira forte é ainda mais importante porque permissões e regras clínicas não podem vazar para helpers genéricos.
Aprendi a desconfiar de módulos bonitos no diretório, mas atravessados por imports internos. A fronteira de verdade consegue dizer “não” a uma operação inválida.
Se uma mudança pequena exige conhecer metade do sistema, o custo arquitetural já está aparecendo.
Como recuperar terreno
Reescrever tudo raramente é a melhor primeira ação. Eu escolheria um fluxo importante, registraria o comportamento atual com testes e criaria uma fachada. Depois, moveria regras e acessos diretos para dentro do novo limite aos poucos.
Arquivos que mudam juntos, ciclos de imports e áreas com mais incidentes ajudam a decidir por onde começar. A refatoração ganha força quando acompanha trabalho real.
Conclusão
Crescer com fronteiras não significa impedir colaboração. Significa definir como partes colaboram sem compartilhar todos os detalhes. Propriedade, contratos e módulos coesos preservam algo valioso: a possibilidade de mudar uma área sem pedir licença ao sistema inteiro.