Compartilhe esse artigo
Em arquitetura de sistemas, Jean Pierre Lessa e Santos Ferreira, CTO do Grupo Carrefour Brasil, observa que a conta do acoplamento quase nunca chega no dia da entrega. Ela chega meses depois, quando alterar um campo de cadastro exige reunir quatro times, três janelas de manutenção e uma noite inteira de plantão.
Boa parte dos inventários de dependência para na lista de bibliotecas e nos serviços chamados por HTTP. Essa é a camada fácil de enxergar e também a menos perigosa, porque está declarada em arquivo e desaparece quando alguém apaga a linha. O que trava a evolução do sistema costuma estar fora dessa lista.
Reduzir dependência não significa eliminar integração. Significa escolher onde o vínculo fica explícito e onde ele pode ser rompido sem quebrar quem está do outro lado. As próximas seções mostram como fazer esse corte, começando pelo que raramente entra na conta.
O que realmente conta como dependência?
Dependência é toda decisão que outro sistema precisa conhecer para continuar funcionando. Isso inclui o nome de uma coluna, a ordem de duas chamadas, o significado de um código de retorno e o horário em que a carga noturna termina. Nada disso aparece no gerenciador de pacotes.
Existe um teste simples para levantar essas amarras. Escolha uma mudança pequena e conte quantas equipes precisam ser avisadas antes que ela vá para produção. O número de avisos revela a dependência real, enquanto o diagrama de arquitetura mostra apenas aquela que alguém desenhou em algum momento.
Os consumidores que ninguém mapeou
Um relatório financeiro lê a tabela de pedidos direto do banco do sistema de vendas. Funciona, é rápido de montar e ninguém precisou negociar nada. A partir daquele dia, renomear uma coluna deixou de ser tarefa do time de vendas e virou negociação entre áreas que nem sabem que dependem uma da outra.
Jean Pierre Lessa e Santos Ferreira pontua esse atalho como o mais frequente entre times sob prazo apertado. O efeito aparece na primeira reescrita: troca-se o componente documentado e surgem, em poucos dias, consumidores que nenhum diagrama registrava. Cada um deles criou o vínculo por conta própria, sem avisar quem mantinha o código.
O banco compartilhado é a dependência mais cara
O mecanismo por trás disso é sempre o mesmo. Quando um segundo sistema lê o banco alheio, o esquema interno vira contrato público sem que ninguém tenha assinado nada. O custo de mudar deixa de depender do tamanho da tabela e passa a depender do número de leitores, que cresce em silêncio.
A saída começa por dar um endereço oficial ao dado que os outros precisam consultar. Uma interface de leitura, um evento publicado a cada alteração ou uma réplica com formato próprio cumprem esse papel, e todos têm o mesmo efeito: o que sai para fora deixa de ser o que está guardado dentro.
Contratos explícitos no lugar de integrações implícitas
Segundo Jean Pierre Lessa e Santos Ferreira, contrato explícito é aquele que quebra em teste automatizado, não em reunião. Cada consumidor descreve o que espera receber, e essa expectativa roda na esteira de quem publica a informação. Se alguém remove um campo em uso, a construção falha antes de chegar à produção.
Sistemas antigos e serviços de terceiros pedem um cuidado adicional. Entre eles e o código novo, vale colocar uma camada fina de tradução, que converte o formato externo para o vocabulário interno em um só lugar. Quando o fornecedor muda a interface, a correção acontece nessa camada, e não em quarenta pontos da base.
Quando reduzir dependência não compensa?
Uma equipe monta uma camada genérica para trocar de provedor de fila quando quiser. Três anos depois, a fila é a mesma, e a camada segue no código, cobrando manutenção e obrigando cada desenvolvedor novo a entender uma indireção que nunca serviu para nada.
Jean Pierre Lessa e Santos Ferreira considera a abstração preventiva um custo que raramente se paga. O critério útil junta duas perguntas: qual a chance real de aquilo mudar e quanto custaria mudar sem preparo. Dependência estável dispensa proteção; a que muda todo trimestre e afeta dez vezes merece contrato, versão e prazo de descontinuação.
Arquitetura como decisão reversível
A qualidade de uma arquitetura aparece menos no desenho e mais no tempo que a empresa leva para desfazer uma escolha ruim. Contar serviços não diz nada. Medir quanto custa remover um deles, ou substituir um fornecedor, diz quase tudo sobre a liberdade que resta ao time.
Jean Pierre Lessa e Santos Ferreira elucida que a pergunta que vale em uma revisão técnica não é quantas integrações existem, e sim quantas delas alguém conseguiria trocar dentro de um trimestre. Sistemas que envelhecem bem não são os que evitaram dependências, e sim os que deixaram cada uma delas visível, nomeada e possível de cortar.