Arquitetura Limpa sem exagero: como evitar o excesso de código

O mito das dezenas de camadas e interfaces vazias

Quando ouvimos falar em Clean Architecture, a primeira imagem que vem à mente é uma cebola perfeita, repleta de camadas concêntricas onde o domínio do negócio vive isolado do mundo exterior. Na prática, muitos projetos corporativos interpretam isso como a obrigação moral de criar interfaces para absolutamente tudo. O resultado costuma ser uma colcha de retalhos de arquivos de mapeamento, DTOs de conversão infinita e classes que apenas delegam chamadas umas para as outras sem adicionar nenhuma lógica real. Esse padrão de engenharia defensiva acaba gerando um cansaço operacional imenso, onde alterar um campo simples exige mexer em meia dúzia de arquivos espalhados pelo projeto. Para entender como mitigar essa complexidade acidental, vale lembrar que, em paralelo com boas práticas de estruturação, muitos sistemas também sofrem com a falta de assincronismo, conforme discutido em por que o código síncrono trava sua API e como migrar, mostrando que o foco deve ser sempre resolver gargalos reais.

Quando a abstração vira um tiro no pé

A promessa original da arquitetura limpa é proteger o núcleo da aplicação contra mudanças em tecnologias externas, como frameworks web ou bancos de dados. Contudo, na maior parte dos softwares corporativos, o banco de dados raramente muda de ORM ou de fornecedor ao longo do ciclo de vida do produto. Criar camadas genéricas de repositório apenas para garantir que a aplicação seja 'independente do banco' costuma ser uma perda de tempo preciosa. Na prática, isso significa escrever código duplicado para mapear entidades de banco para modelos de domínio e depois para objetos de transferência de rede, criando uma burocracia inútil. Em sistemas legados, essa pressa em abstrair tudo geralmente gera um emaranhado difícil de manter, tema que abordamos em detalhes quando discutimos por que o código legado falha e como refatorar com testes para garantir segurança sem burocracia excessiva.

Simplificando o design sem perder a modularidade

Manter o código limpo e desacoplado não significa espalhar o projeto em dezenas de microservices ou pacotes minúsculos. Um monólito modular bem desenhado costuma entregar a mesma separação de responsabilidades com uma fração minúscula da dor operacional de infraestrutura. A regra de ouro é isolar as regras de negócio puras em um módulo central, permitindo que elas ignorem completamente detalhes de infraestrutura como requisições HTTP ou drivers de mensageria. Quando precisamos de flexibilidade, podemos recorrer a padrões consagrados sem cair no exagero de criar fábricas abstratas para objetos simples de configuração. Na prática, isso significa escrever funções diretas que resolvem o problema imediato, mantendo o código aberto à extensão apenas onde a volatilidade do negócio realmente justifica o investimento.

Práticas pragmáticas para o dia a dia do desenvolvedor

Para colocar uma arquitetura pragmática em prática, comece eliminando interfaces que possuem apenas uma única implementação óbvia. Se uma classe de serviço concreta atende perfeitamente ao caso de uso, injete-a diretamente sem medo de acoplamento excessivo, afinal, o acoplamento só é prejudicial quando conecta lógicas de negócios a detalhes voláteis de infraestrutura. Outro ponto crítico é evitar a proliferação de DTOs para cada pequena variação de tela ou endpoint, preferindo contratos coesos que atendam contextos específicos de negócio. Manter a disciplina na equipe exige revisões de código focadas em questionar a utilidade de cada nova camada introduzida, garantindo que o time priorize a entrega de valor funcional em vez de arquitetura cosmética. Dessa forma, a base de código permanece ágil, compreensível e preparada para evoluir junto com as demandas reais da empresa.

Considerações finais sobre o equilíbrio arquitetural

A busca por um design de software elegante nunca deve se sobrepor à capacidade da equipe de entregar valor de forma sustentável e previsível. Clean Architecture é sobre gerenciar dependências e proteger o núcleo do negócio, e não sobre seguir dogmas rígidos que transformam tarefas simples em labirintos burocráticos. Avalie sempre o custo-benefício de cada nova camada, mantenha o código o mais simples possível e lembre-se de que a melhor arquitetura é aquela que atende às necessidades atuais da organização sem impedir o crescimento futuro.