Clean Architecture sem religião
Existe um desenho que qualquer pessoa que já pesquisou Clean Architecture reconhece de cabeça: círculos concêntricos, setas apontando sempre para dentro, Entities no centro, Frameworks and Drivers na borda. O desenho é bonito. O problema é que ele virou, para muita gente, sinônimo da arquitetura inteira, como se seguir o diagrama à risca fosse o objetivo.
O que Clean Architecture realmente propõe
A ideia central, descrita por Robert C. Martin (o “Uncle Bob”), é bem mais simples do que o diagrama sugere: regra de negócio não deveria depender de detalhe de infraestrutura. Banco de dados, framework web, biblioteca de UI, tudo isso é detalhe e deveria poder ser trocado sem tocar na lógica que realmente importa para o domínio.
Essa regra tem nome: a Dependency Rule. O código-fonte só pode apontar para dentro, das camadas mais externas (frameworks, banco de dados, UI) em direção às mais internas (casos de uso, entidades). Uma entidade de domínio nunca deveria importar um DbContext. Um caso de uso nunca deveria conhecer detalhes de uma controller HTTP.
Até aqui, é difícil discordar. O problema começa na aplicação.
Onde a religião entra
Em algum sistema com três telas e um banco de dados, virar quatro ou cinco projetos separados (Domain, Application, Infrastructure, API, e às vezes mais um “Core” só para gerar confusão) para satisfazer o diagrama tem um custo real: mais indireção, mais interface que só tem uma implementação, mais arquivo para navegar até achar onde uma regra de fato acontece.
Isso não é culpa da arquitetura. É culpa de tratar um conjunto de princípios como checklist de pastas obrigatórias, independente do tamanho ou da complexidade real do problema.
Acoplamento é o inimigo, não a simplicidade
O motivo pelo qual Clean Architecture existe é reduzir acoplamento entre regra de negócio e detalhe técnico, para que um detalhe (o banco, o framework) possa mudar sem exigir reescrever a lógica central. Isso importa de verdade quando existe complexidade real de domínio, múltiplas formas de entrada (API, fila, job agendado) ou expectativa concreta de trocar uma peça de infraestrutura no futuro.
Num CRUD simples, com uma única forma de entrada e nenhuma perspectiva real de trocar o banco, o mesmo princípio pode ser satisfeito com muito menos cerimônia: um projeto, camadas lógicas organizadas em pastas, sem exigir múltiplos assemblies e uma interface para cada classe que só tem uma implementação.
Separação de camadas não é medida de qualidade
Uma armadilha comum é usar “quantas camadas o projeto tem” como proxy de “quão bem arquitetado o projeto é”. Complexidade acidental, aquela que vem da estrutura escolhida e não do problema em si, é tão prejudicial quanto acoplamento excessivo. Um projeto pode ter zero camadas separadas e estar bem desenhado, ou ter cinco camadas e ser um labirinto de indireção que ninguém consegue depurar sem abrir seis arquivos só para seguir uma única chamada.
Uma pergunta melhor que “onde eu boto isso”
Antes de criar mais uma camada, mais uma interface, mais um projeto separado, a pergunta que vale mais a pena fazer é: esse detalhe realmente precisa estar isolado da regra de negócio agora, ou esse custo está sendo pago só porque o diagrama diz que deveria existir uma seta apontando para dentro ali?
Clean Architecture continua sendo um conjunto de princípios sólido para o problema que resolve: isolar regra de negócio de detalhe técnico. O erro não está no princípio. Está em aplicá-lo como dogma, independente de o projeto ter ou não o tipo de complexidade que justifica o custo.