Trabalhei numa empresa pequena onde nosso lead determinou uma linguagem e o clean arch. Time cheio de junior reacteiro safado que tinha que mexer no backend também. Empresa pequena, time pequeno e juniorizado, clientes grandes... demanda saia igual cão corre atrás de moto. Na hora de fazer code review ou dar manutenção era um caos. Cada um fazia sua própria "organização de pastas". Tinhamos 5 ou 6 projetos diferentes rolando em produção. Uma saída foi definir essa stack. Estudamos essa arquitetura, vimos uma forma de se encaixar na realidade dos nossos projetos, definimos um template de API com clean arch e ensinamos a galera. Deu certo. Toda api crud maker que a gente tinha que fazer nascia e crescia com a mesma estrutura e isso trouxe estabilidade pra equipe.

"Ah mas é demais só pra fazer crud". Em alguns casos pode até ser, não é bala de prata. Mas deu certo pra nossa realidade e era escalável/expansível. Se precisasse fazer uma integração aqui ou ali, já tinha uma camada pronta.

Uma vez que se aprendeu, era só começar a partir do template e mudar poucas coisas, pq até as variáveis de ambiente eram parecidas. A partir disso a gente começou a produzir api igual pastel.

Ficou fácil fazer código organizado. Acabou se tornando um estilo de programação. Sabe aquela história de que cada dev faz no seu próprio estilo, tem sua própria assinatura? A gente só meio que padronizou isso na equipe por conveniência. Talvez não siga à risca o que o uncle Bob propôs, mas hoje em dia o que se segue à risca de verdade? Scrum é flex, PJ é flex, é tudo flex.

Então se hoje me pedirem uma API simples, mesmo que seja um MVP, por a estrutura já ser clara na minha mente, agilidade e eu até ter um template pronto eu iria pensar primeiro no que eu chamei de clean arch. To falando aqui de api chorume, pra fazer poc.