Dependência não é defeito. Um sistema útil sempre conecta coisas. A dor começa quando essas conexões ficam invisíveis: módulos formam ciclos, regras importam SDKs, dois deploys precisam acontecer na ordem certa e ninguém sabe explicar por quê.
Nesse cenário, “alteração local” vira expressão otimista. Até trocar um detalhe exige procurar efeitos espalhados pelo repositório e pela operação.
Acoplamento não vive só nos imports
Há dependência estrutural, mas também temporal e semântica. Um consumidor pode não importar nenhum arquivo e ainda depender da ordem exata de dois eventos ou interpretar um campo interno que nunca foi prometido.
O histórico ajuda a enxergar isso. Arquivos sempre alterados juntos e incidentes causados por sequência de execução contam uma história que o grafo de imports não mostra.
Política aponta para dentro
Casos de uso deveriam declarar suas necessidades em termos do produto. Adaptadores resolvem PostgreSQL, fila e APIs externas. A composição conecta os dois na borda.
- Política: a decisão que pertence ao negócio.
- Porta: o contrato mínimo pedido pelo caso de uso.
- Adaptador: a tradução para uma tecnologia concreta.
- Composição: o lugar visível onde tudo é ligado.
Não crio interface para cada classe. A abstração faz sentido quando protege uma decisão relevante ou uma dependência volátil.
Eventos também acoplam
Trocar chamada direta por evento não apaga a relação. Consumidores continuam dependendo do formato e, principalmente, do significado. Um genérico entityUpdated só terceiriza a interpretação.
Eventos específicos, imutáveis e versionados são mais honestos. Ainda precisamos lidar com atraso, duplicidade e ordem; consistência eventual não pode ser surpresa para a interface.
Fronteiras externas deixam a lição clara
Em trabalhos com Sinaxys e Entrega Contínua, integrações com Stripe, N8N e WhatsApp tinham falhas e ciclos próprios. Traduzir respostas externas antes de acionar o domínio manteve esses detalhes fora dos casos de uso.
Na ANIMAPS e na KasbHealth, injeção de dependência ajuda, mas não faz milagre. Injetar o mesmo serviço enorme em todos os módulos continua sendo acoplamento — apenas com decorator.
Desacoplar não é cortar relações. É conseguir apontar cada relação, explicar seu motivo e testá-la sem encenação.
Desatando o nó
Começaria pelos ciclos e pelas dependências em tecnologia instável. Uma fachada permite migrar chamadas gradualmente; testes de contrato preservam o comportamento durante a troca.
Regras automatizadas de import ajudam a manter o desenho, mas exceções existem. Melhor documentar uma exceção consciente do que deixar um atalho invisível virar padrão.
Conclusão
Quando tudo depende de tudo, código, teste e deploy passam a carregar o mesmo risco. Relações menores e direcionadas devolvem espaço para mudança. O objetivo não é independência absoluta, e sim dependências que a equipe consegue entender e administrar.