Arquitetura Limpa: a esperança dos projetos que não viram espaguete.
Sabe aquele projeto que você começa animado e, em 3 sprints, tá chorando nos if-else aninhados com 10 níveis de profundidade?
Pois é, meu consagrado, o nome disso é acoplamento tóxico com pitadas de desespero.
E é aí que entra a famosa Clean Architecture — ou como diria um dev das antigas: o Santo Graal do código desacoplado.
O que é essa tal de Arquitetura Limpa?
Resumindo em bom devês:
É um modelo de organização de software que separa responsabilidades por camadas, isolando regras de negócio de detalhes técnicos como frameworks, bancos e APIs externas.
Ou seja:
- Seu código fica mais fácil de manter
- Dá pra testar sem precisar subir a infra da NASA
- O front-end pode mudar, o banco também, mas a lógica de negócio continua firme e forte
Como ela se aplica na vida real com .NET e C#?
📁 Estrutura básica de um projeto:
/src
/Core → onde moram as regras de negócio (Entities, UseCases)
/Application → os contratos, interfaces, DTOs, validações
/Infra → implementações de repositórios, serviços externos etc
/WebApi → a ponta que recebe requisições e devolve respostas bonitinhas
Spoiler: essa separação NÃO é só pra ficar bonito no GitHub. Ela resolve coisa séria como:
✅ Testabilidade
✅ Substituir uma lib sem sair quebrando tudo
✅ Crescer o projeto sem criar Frankenstein
E os testes?
Com essa separação toda, testar fica MUITO mais fácil.
Você pode testar os UseCases sem depender do banco, da API externa, nem do Azure caindo.
[Test]
public void ShouldCalculateCorrectDiscountForPremiumUser()
{
var useCase = new CalculateDiscountUseCase();
var result = useCase.Execute(new PremiumUser());
Assert.AreEqual(0.2, result.Discount);
}
A lógica tá desacoplada, logo... testável! É disso que o TDD gosta. 😎
Mas e os frameworks, ORMs, automappers?
Todos eles devem girar em torno do seu domínio, e não o contrário.
Você não deveria mudar sua regra de negócio só porque o EF não curte um relacionamento em cascata.
Aliás, Uncle Bob (autor da arquitetura) disse:
"Frameworks são ferramentas, não a fundação do seu software."
Tradução livre:
“Pare de fazer o banco ser o rei da festa, quem manda aqui é a regra de negócio.”
😅 Mas e quando o time acha “overkill”?
Sim, usar Clean Architecture num CRUD de 3 endpoints talvez seja exagero...
Mas na real? Projetos raramente ficam pequenos.
O que começa como um MVP hoje vira um monstro corporativo amanhã.
Se você já começa com uma base sólida, você ganha tempo, sanidade e respeito do eu-futuro que vai manter isso depois.
E o papel da IA nisso tudo?
Hoje, com assistentes como o GitHub Copilot, você consegue gerar muito código boilerplate rápido.
Mas atenção: IA é ferramenta, não arquiteta.
Cabe a você saber estruturar bem as camadas, os limites, os contratos.
Senão vira aquele código “bonito por fora, mas gritando por ajuda por dentro”.
