Pratico Clean Architecture faz anos. O TOPO Contabil tem 252 use cases seguindo o padrao a risca. Aqui vai o que eu REALMENTE aprendi -- nao a teoria do livro do Uncle Bob, mas a realidade de conviver com isso em escala num projeto de verdade. O QUE FUNCIONA Testabilidade. Essa eh a vitoria inegavel. Todo use case eh funcao pura das dependencias. Injeta mock, asserta output. Nossa suite de teste unitario roda em 18 segundos porque nada encosta em banco ou rede. Quando teste falha, tu sabe EXATAMENTE o que quebrou porque o escopo eh minusculo. Um use case, uma responsabilidade, um arquivo de teste. Onboarding. Dev novo fica produtivo em dias, nao semanas. A estrutura eh tao previsivel que quando tu viu um modulo, viu todos. "Onde fica a logica de negocio?" No use case. "Onde fica a logica de banco?" No repository. "Onde fica a validacao?" No DTO. Sempre. Sem excecao. Confianca pra refatorar. Quando toda dependencia eh injetada por interface, trocar implementacao eh trivial. A gente migrou de um provedor de calculo tributario pra outro escrevendo um adapter novo. Zero mudanca na logica de negocio. Zero mudanca nos testes. Os use cases nao sabiam e nem ligavam. Modelagem de dominio. Se forcar a separar entidade de dominio de entidade de banco te faz PENSAR sobre teu dominio. Nossa entidade de documento fiscal tem comportamento. Ela sabe se validar, calcular totais, transicionar estados. Nao eh um saco de propriedade que eh mutado de fora. Isso importa quando teu dominio eh complexo tipo legislacao tributaria brasileira. O QUE NAO FUNCIONA A cerimonia. Criar feature nova = criar no minimo 5 arquivos. Use case, DTO de input, DTO de output, metodo no controller, talvez metodo novo no repository. Pra CRUD simples eh overkill total. A gente aceita esse imposto porque os beneficios em escala superam o custo, mas nao vou fingir que nao pesa as vezes. Inferno de mapper. Converter entre entidade de dominio, entidade de banco, DTO e objeto de resposta significa escrever MUITO codigo de mapeamento. Eh tedioso e propenso a erro. Automatizamos parte mas ainda existe uma camada de mapper que existe puramente por pureza arquitetural. Ironico ne. Tentacao de over-abstraction. Quando tu ta no mindset Clean Architecture, comeca a abstrair TUDO. Tu realmente precisa de interface de repository pra tabela de lookup que nunca vai trocar de provedor? Provavelmente nao. Mas o padrao diz que sim, ai tu faz, e agora tem interface, implementacao e registro de modulo pra algo que podia ser uma chamada direta ao banco. QUANDO QUEBRAR AS REGRAS Depois de 252 use cases, desenvolvi senso de quando a arquitetura deve flexibilizar: Leitura simples que so busca e retorna dado nao precisa de use case completo. Query service fino que vai direto pro repository ta de boa. Nem tudo precisa de split comando/query. Feature prototipo ganha estrutura mais simples. Quando a gente nao tem certeza se a feature vai sobreviver, builda com menos cerimonia. Se provar valor, refatora pra Clean Architecture completa. Se nao, eh facil deletar. Caminho critico de performance as vezes precisa quebrar camada. Nosso modulo de geracao de relatorio bypassa a abstracao de repository e usa SQL puro porque o ORM era lento demais. O purista de arquitetura dentro de mim chora, mas o pragmatico sabe que relatorio de 30 segundos eh pior que camada impura. Clean Architecture nao eh religiao. Eh ferramenta. Usa onde ajuda. Relaxa onde nao ajuda. O objetivo eh software mantenivel, nao pureza arquitetural por si so. 252 use cases depois, faria tudo de novo. Mas seria menos dogmatico desde o comeco.