.NET
Por que acho que iniciantes deveriam aprender clean architecture
Eu costumava jogar meu DbContext direto nos controllers e despejar lógica no Program.cs. Funcionava, até eu precisar mudar alguma coisa. Clean architecture foi o que consertou isso.
Quando comecei a programar em .NET, meu único objetivo era fazer as coisas funcionarem. Eu jogava meu database context direto nos controllers da API, escrevia checagens de validação bem do lado das minhas queries SQL, e despejava metade da minha lógica no Program.cs. Funcionava. A aplicação rodava, o JSON voltava, e eu sentia que sabia o que estava fazendo.
Depois veio a primeira vez que eu precisei mudar alguma coisa.
Tentei trocar uma biblioteca de database e atualizar uma regra de negócio no mesmo dia. Metade dos meus endpoints quebrou. Um ajuste num cálculo de pedido de alguma forma afetou minha lógica de registro de usuário. Eu estava gastando a maior parte do meu tempo desenrolando código que eu tinha escrito duas semanas antes em vez de escrever qualquer coisa nova.
Essa bagunça foi o que me empurrou para estudar clean architecture.
No início parecia intimidador. Todo mundo falando sobre isso soava como se estivesse lendo de um livro didático enterprise, jogando termos como dependency inversion e domain-driven design. Mas assim que comecei de fato a quebrar minhas solutions .NET em camadas apropriadas, algo fez sentido.
Como eu de fato estruturo isso agora
Quando começo um projeto, configuro a camada Domain primeiro com classes C# puras, sem Entity Framework, sem HTTP, sem pacotes de terceiros, só a lógica de negócio sozinha. Depois a camada Application cuida dos use cases de verdade, definindo interfaces para o que ela precisa, algo como "buscar um usuário" ou "mandar um email", sem se importar ainda com como essas coisas de fato acontecem.
Só depois disso estar no lugar eu toco no EF Core ou no ASP.NET. Database contexts e APIs externas ficam na Infrastructure, e as Minimal APIs ou Controllers ficam na Presentation.
O que de fato mudou no dia a dia
Os princípios SOLID pararam de ser respostas de entrevista e passaram a ser como minhas pastas de projeto já estão configuradas, não algo que eu tenho que lembrar de aplicar por cima.
Testing parou de ser uma dor de cabeça. Regras de negócio que não sabem nada sobre um database podem ser testadas com xUnit em segundos, sem database em memória, sem mocks elaborados, só a lógica sozinha.
Lock-in de tech stack parou de me preocupar. Se eu trocar o SQL Server ou mudar um provider de email, só a Infrastructure muda. A aplicação principal nem percebe.
Onde eu ainda mantenho simples
Ainda tem vezes para pular tudo isso. Um app CRUD básico que poderia ser uns dois arquivos não precisa de quatro projetos separados. Mas passar por essa mudança mudou como eu penso sobre código de forma geral: de jogar sintaxe na parede até funcionar, para construir algo pensado para de fato aguentar quando eu precisar mudá-lo depois.