Existe um momento muito específico na carreira de qualquer engenheiro sênior: você abre um repositório novo, procura a lógica de negócio de uma função que atualiza o status de um pedido, e acaba pulando por seis pastas diferentes. Entity, use case, gateway, presenter, controller, adapter. Vinte minutos depois, você encontra a linha que realmente faz algo: um update em uma tabela. O resto era cerimônia. Alguém leu "Clean Architecture", do Robert Martin, se empolgou com os círculos concêntricos, e decidiu que um CRUD de configuração de usuário merecia a mesma separação que o núcleo transacional de um banco.
Esse é o problema real: aplicar clean architecture sem se perguntar para que você está aplicando isso.
O que a clean architecture resolve quando o problema é real
A ideia de fundo da clean architecture não é ruim, e vale dizer isso sem rodeios: separar as regras de negócio dos detalhes de infraestrutura (o banco de dados, o framework web, o provedor de mensageria) é uma aposta que compensa quando essas regras de negócio vão durar mais do que a tecnologia que as cerca hoje.
Pense em um sistema de faturamento que processa as regras fiscais de 12 países. Essas regras mudam por lei, não por moda tecnológica. Se elas estão enterradas em controllers do Express ou em stored procedures acopladas a um ORM específico, cada migração de framework vira uma reescrita de negócio disfarçada de upgrade técnico. É aí que separar entidades, casos de uso e adaptadores faz sentido: não porque o livro manda, mas porque existe uma razão concreta para o domínio não saber que o PostgreSQL existe.
O mesmo acontece quando a equipe cresce. Com quinze engenheiros mexendo no mesmo serviço, você precisa de fronteiras claras entre "isso é uma regra de negócio que discutimos no comitê de produto" e "isso é um detalhe sobre como persistimos isso hoje". Sem essa fronteira, qualquer troca de biblioteca HTTP te obriga a mexer na lógica de descontos porque alguém misturou as duas coisas no mesmo arquivo há dois anos. A clean architecture, nesse contexto, é um mecanismo de coordenação entre equipes que não conversam todo dia, não uma questão estética.
Há um terceiro cenário em que a clean architecture compensa e é menos mencionado: quando o mesmo domínio precisa ser exposto por mais de uma porta de entrada. Um motor de precificação que atende uma API REST, um worker que processa eventos de uma fila, e um job batch que roda de noite. Se a lógica de cálculo de preço vive grudada no controller REST, você acaba copiando ela (mal) no worker e no batch, ou construindo dependências cruzadas esquisitíssimas entre essas três pontas. Separar o caso de uso do adaptador de entrada não é capricho: é a única forma de as três portas chamarem a mesma regra sem duplicá-la.
Quando a separação em camadas é só teatro arquitetônico
Agora o outro lado, que é onde a maioria dos projetos latino-americanos que já vi realmente sofre. Um serviço interno que expõe três endpoints para gerenciar tags de um catálogo não precisa de entidades de domínio, casos de uso independentes do framework, e uma camada de adaptadores para falar com uma tabela do Postgres que provavelmente nunca vai trocar de motor. Isso é puro teatro.
O sintoma é reconhecível na hora: para adicionar um campo novo em um formulário, você mexe no DTO, no mapper do DTO para a entidade, no caso de uso, no mapper da entidade de volta para o DTO de resposta, e no controller. Cinco arquivos para o que, em um CRUD direto, seria uma mudança em um modelo e em um endpoint. Ninguém se beneficiou dessa indireção. Nem o negócio, que não tem regras complexas para proteger, nem a equipe, que provavelmente é uma ou duas pessoas que conhecem o código de cor.
Isso acontece com muita frequência quando alguém júnior com ambição arquitetônica (ou alguém sênior que quer deixar sua marca) aplica o padrão porque é "a forma certa de fazer software", sem se perguntar se o contexto justifica isso. Uncle Bob nunca disse que todo sistema precisa de quatro camadas. Ele disse que a dependência deve apontar para o domínio quando este for o que você precisa proteger. Se você não tem nada para proteger, está pagando o custo da indireção sem receber nenhum dos benefícios.
Já vi o mesmo padrão se repetir em diferentes startups da região: a equipe fundadora começa com um monólito direto, sem camadas, e funciona bem por um ano e meio. Depois contratam alguém com background em uma consultoria grande, que chega com a melhor intenção e reescreve o core em uma clean architecture completa antes de o produto ter confirmado o product-market fit. Seis meses depois o negócio pivota, como pivotam a maioria dos produtos em estágio inicial, e agora é preciso jogar fora entidades, casos de uso e adaptadores que protegiam regras de negócio que já não existem. A arquitetura não falhou tecnicamente. Falhou porque foi aplicada antes de se saber o que precisava ser protegido.
O custo real que ninguém menciona nas palestras de conferência
Cada camada que você adiciona tem um custo que é pago diariamente, não uma única vez. Onboarding mais lento, porque um engenheiro novo precisa entender cinco conceitos antes de conseguir mexer em uma função. Debugging mais demorado, porque seguir o fluxo de uma request implica pular entre arquivos que vivem em pastas diferentes. E um custo silencioso que é o pior de todos: menos gente se anima a propor mudanças, porque mexer em algo "bem arquitetado" dá medo mesmo quando a mudança é trivial.
Esse último ponto é o que mais machuca as equipes. Quando a arquitetura fica mais importante do que o problema que resolve, as pessoas param de questioná-la. Ela vira dogma. E dogma em engenharia é sempre um sinal de que você parou de pensar no contexto e começou a copiar uma estrutura que leu em outro lugar.
O ponto polêmico aqui, e vou dizer sem meias palavras: clean architecture funciona em sistemas grandes, com múltiplas equipes, com lógica de negócio que você sabe que vai sobreviver ao framework da vez. Falha, e falha feio, em serviços pequenos, em CRUDs administrativos, em ferramentas internas que uma equipe de três pessoas mantém e entende de ponta a ponta. Aplicar ali é cargo cult, não disciplina.
Sinais concretos para decidir se vale a pena para você
Existem perguntas que você pode se fazer antes de decidir quantas camadas seu projeto precisa, e nenhuma delas tem a ver com o quanto o padrão está na moda.
Esse sistema vai sobreviver a uma troca de framework ou de banco de dados nos próximos anos? Se a resposta é sim, investir para que o domínio não dependa desses detalhes tem um retorno real. Existe mais de uma equipe mexendo nesse código sem se coordenar diariamente? Se sim, fronteiras explícitas evitam que uma mudança de infraestrutura quebre uma regra de negócio por acidente. A lógica de negócio é complexa de verdade (cálculos, regras condicionais, fluxos de estados) ou é basicamente operações CRUD com validações simples? Se é a segunda opção, qualquer camada adicional é pura fricção.
E a pergunta que mais se pula: alguém nesta equipe entende por que estamos aplicando esse padrão, ou estamos copiando porque vimos assim em um repositório de exemplo? Se ninguém consegue explicar qual problema concreto cada camada resolve no seu contexto, você não tem clean architecture. Tem um template que decidiu não questionar.
Uma forma prática de resolver isso sem cair em nenhum extremo é projetar para migrar, não para prever. Você começa com a estrutura mais simples que funcione: modelos, validações, um handler por endpoint. No dia em que uma regra de negócio começa a se repetir em três lugares diferentes, ou quando você precisa expor essa regra por um segundo canal além do HTTP, esse é o momento de extraí-la em um caso de uso independente do framework. Não antes. A separação em camadas deveria ser uma resposta a uma dor real que você já sentiu, não uma aposta sobre uma dor que você acha que vai sentir daqui a dois anos. Refatorar para mais estrutura quando você precisa é barato. Carregar estrutura que você nunca precisou é uma hipoteca que toda a equipe paga, todos os dias, por anos.
A arquitetura não é a conquista, é a ferramenta
Aqui está minha posição, sem rodeios: a arquitetura de um sistema é uma ferramenta que existe para resolver um problema específico de manutenibilidade, não algo que você mostra em uma palestra para provar que conhece padrões. Quando esse problema não existe, a ferramenta mais elegante é não usá-la.
Clean Architecture deu à indústria um vocabulário útil para falar de dependências e de separação de responsabilidades. Isso é valioso e não deve ser jogado fora. Mas o vocabulário virou, em muitas equipes, uma desculpa para não pensar. Seis camadas de indireção em um CRUD são a ausência de uma decisão, disfarçada de boas práticas, não rigor técnico.
O engenheiro sênior que realmente entende isso é o que consegue olhar para um sistema e dizer, com a mesma convicção, "aqui a separação em camadas vai nos salvar daqui a dois anos" ou "aqui é puro overhead e vamos simplificar", não o que aplica o padrão em tudo por consistência. Essa capacidade de discriminar contexto, não a memorização do livro, é o que separa quem entende arquitetura de quem só a imita.
