Clean architecture: Provavelmente você não quer isso

No episódio de hoje eu volto a falar sobre o excesso de preocupação trazido por arquiteturas que tentam acomodar possíveis mudanças de tecnologia. A Clean Architecture é o expoente disso hoje em dia. Inspirada em múltiplas arquiteturas de camadas, ela tenta juntar tudo num bolo só para te dar uma espécie de guia interessante.

Além de trazer uma preocupação que, ao meu ver, tende a ser exagerada e provavelmente sem fundamento, criar um software desacoplado de um monte de coisa te atrasa, deixa mais propenso a erro e potencialmente te faz usar de maneira menos interessante tudo que é tecnologia que você decidiu trazer para o projeto.

Se você acredita que a tecnologia tem que te ajudar no desenvolvimento, qual o motivo de você querer ficar desacoplado dela?

# Links

# Saiba mais sobre a Jornada Dev Eficiente:

# Saiba mais sobre mim :)

[israelbgf]

Sempre bom algum conteúdo saindo do comum para refletirmos. Sobre o conteúdo:

- Concordo, que existe uma tendência de querer complicar as coisas, que nem o próprio uso desenfreado de micro-serviços para tudo. Nem todo mundo é uma Netflix, nem virá a ser.

- Você falou "Mais abstração, mais difícil de entender.", até entendi a mensagem, mas não sei se é um conceito bem apurado. Código em assembly tem baixa abstração e é mais complexo de se escrever e manter. Um código em um método só (baixa abstração) é potencialmente difícil de entender, em vários métodos potencialmente mais simples (maior abstração). E não necessariamente é mais difícil escrever um código com mais métodos (ou pelo menos não cresce de dificuldade "linearmente" por assim dizer). Existe uma linha tênue ai nos extremos, e por isso não me parece correto fazer essa regra tão absoluta que fizestes.

- Sobre a Clean Architecture, acredito que você assumiu a necessidade de gerar tantas interfaces, camadas de indirection, como um pré-requisito para a Clean Architecture, mas ela é uma série de princípios e não uma série de regras. Se você tem um Usecase, seu acesso ao banco num Gateway, e o Presenter sendo o controller do seu Framework, e está respeitando a ordem de importação, tecnicamente já é uma implementação de Clean Architecture (bem simplificada, mas suficiente).

- Na minha experiência com a Clean Architecture [em python] (com erros e acertos na forma de implementar) ela me facilitou: 1- Inserir uma camada de cache entre minha regra de negócio e minha persistência com mínimo esforço. 2- Ao atualizar o framework Django, o fato de termos algumas dependências isoladas (como o backend de cache) tornou muito mais fácil corrigir um alteração de comportamento do framework (em que o 1 deixou de ser válido como true). 3- Pensar em separar componentes, simplifica os testes (teste seu Gateway sem precisar levantar um controller e ter que lidar com autenticação e outros aspectos desnecessários para as fixtures). Entendo que no entanto, muitos desses aspectos, nem precisam do nome "Clean Architecture", não sendo muito diferente ai de uma "Lasanha Application Clássica™" (risos).

Em resumo, acho que você teve uma expectativa específica de implementação a lá EnterpriseFizzBuzz, como a "única forma de se implementar uma Clean Architecture". Na minha experiência, não é o caso, e nem reflete o que eu acredito que seja proposto pela CA (que é mais princípios do que regras). Até pq o Uncle Bob realmente é muito ruim em dar exemplos, só fica falando e não mostra nada (risos).

Como sugestão adicionar, eu iria dizer para tentar ser um pouco mais objetivo na apresentação do tema, mas provavelmente eu faria o mesmo, por não ter tanto tempo para ficar editando e querer fazer em 1 take só como se fosse um bate-papo. :P

Grato pelo conteúdo e por proporcionar a troca de experiências. Abraços.

[Mike-yuwh]

É o tipo de vídeo que não existe na Internet, questionando o "inquestionável". Parabéns vc é incrível

[joseaugusto]

Assim como o Israel Fonsenca pontuou, vou levantar um outro ponto:
- Quando falando de clear arch, não necessáriamente temos apenas apenas Java para pensar. O próprio o Israel menciou Python, vou mencionar PHP. Quando iniciei com PHP, tinhamos embriões de FW, até mesmo pela baixa aderência da linguagem à OO. Fazer código todo misturado era uma premissa à época (acho que com o java tbm nas tais JSP). Vieram os frameworks (zend, cake, laravel, symfony, mais 1bi e 900mi). Pela sua retórica, deveria não me preocupar em abstrair o código de negócio do FW. A pergunta é: se minha aplicação tivesse escrita em zf1, seria mais fácil reescrever tudo apenas para trocar de FW para zf2 pq o vendor não manteve a retrocompatibilidade (idem para todos os demais fw)?

- Tenho clientes que têm código em zf1 e não conseguem migrar por conta do alto risco que corre em reescrever sua aplicação. Hoje, pagam o preço da obsolecência de framework, da linguagem, de banco e sistema operacional. Sim, pq o zf1 só roda até uma versão x do php. o php x só dá suporte até y versão de drivers, o ubuntu por sua vez, só dá suporte a versão x do php até dada versão do SO. Nota-se que prender seu negócio a uma tecnologia, nem de longe é saudável.

- Outro ponto, se vc acha que reescrever um código todo é menos traumático que evoluir, eu diria: leva essa ideia para o pessoal do BB que não sai totalmente do COBOL até hoje (sim, sei que tem muita coisa migrada para java).
Softwares criados e postos em produção não são estáticos. São vivos. Todos os dias eles recebem correções, evoluções e melhorias. Por vezes, são decadas de evolução em cima de um software e, novamente, se para você é mais fácil trocar tudo do que simplesmente ter a opção de evoluir apenas um componente de forma a não alterar um componente que ficou obsoleto. não sei se concordo.

- Voltando-nos apenas para o mundo java: se vc tiver um software que usou os embriões do JPA e, agora, precisa/quer trocar por Hibernate ou a camada de view. para vc, é mais fácil trocar tudo?

[VictorMantovani]

Nossa área tem muito "cargo cult", acho Clean Arch bem desnecessário na maioria dos casos e adiciona uma complexidade que as bases de código não precisavam ter, fico admirado com projetos de outras linguagens que organizam código de forma bem mais simples, o mundo Java gosta de complexidade e acha isso "profissional"

[carlosruesta]

Gostei do video e da provocação. Na empresa tem sempre esse dilema. Como eu gostou de estudar vejo a beleza do Clean Architecture, mas concordo que é para muitos projetos pequenos/coesos já é muita coisa. Se um software pequeno ficar obsoleto não seria difícil adaptar a um novo framework ou até mesmo reescrever ele.
Mas em projetos maiores que normalmente são aqueles que formarão um pilar de sustentação de uma empresa já vejo mais valor. Nesse sentido, gostaria de complementar com um pergunta para vocês: quantas vezes já teve a vontade de fazer a troca de framework (bd, orm, etc) e segurou pelo acoplamento? E digo mais.... Quantas vezes teve a necessidade e abriu mão de uma venda pois a mudança implicaria na mudança de framework?
No meu caso, confeso que algumas vezes. Já encaramos a troca sem CA e deu certo. Também já mantivemos como está o produto, pois não valeria a pena o esforço, mesmo com a vontade de mudar. Também ja reescrevemos do zero e ainda estamos nesse processo, rsrs. Eu acredito que se o domínio estivesse limpinho seria muito mais rapido e fácil esse processo, mas concordo que o esforço no início do projeto seria maior e precisaria de maior maturidade do time e por ai vai... Enfim, gostei das provocações e estou sempre levando isso para o time e é por isso que acompanho esse canal. Valeu Alberto.

[abraaohonorio]

Concordo que existe muito software que não deveria ter sido construido usando clean arch mas evitar acomplamento é ruim? Seguindo esse raciocínio você não deve usar o repository pattern, correto ?
Falando do meu relato o uso de use cases facilita muito entender o software, já usei tanto em aplicações usando Clean Architecture assim como no Vertical slice. O uso de clean arch em minha vida facilitou muito quando as aplicações que estava trabalhando que só recebia input via Http passaram a receber via um work em backgroud(isso é bem comum hoje em dia) e necessitava executar o mesmo use case, outro exemplo que facilitou quando tive mudar a mensageria do sistema de Service Bus para Rabbit. Qual arquitetura você usaria quando sua aplicação tem que vários tipo de entrada/saída de dados por exemplo o Rest, gRPC, Work?
Vale salientar que todas minhas experiência foram de aplicações que não estavam no mundo spring boot.

[maltasga]

Trabalho com desenvolvimento há mais ou menos 10 anos, sempre com tecnologias .NET, e nunca passei por nenhuma mudança motivada por obsolescência. Por outro lado, já vi muito problema relacionado a mal planejamento do software, que nos levou a famigerada situação de "temos que reescrever o sistema".
Minha percepção é que hoje em dia a gente tá cada vez mais pensando software para situações que podem vir a acontecer, sempre com aquele pensamento de "vai que eu preciso mudar no futuro", com isso não focamos no hoje e em solucionar o problema do negócio. Afinal de contas, no geral, produtos de software são enablers para um objetivo final.

Alberto, obrigado por trazer essa ótima reflexão!

[alessandro]

Cuidado cara, os fãs de tech influencerzinhos de meia tigela e de escritores famosinhos vão querer te atacar, se falar mal de Scrum e SOLID também sua vida estará em perigo rsrs. Brincadeiras à parte excelente vídeo

[andrecarvalho]

Lá no time a gente usa o good enough.
Abraçamos os use cases e de fato achei muito melhor que jogar tudo dentro de uma service. Abraçamos gateways também, é maravilhoso para integrações com APIs externas, Kafka, pubsub, envio de email, etc, banco de dados também. Isso faz com que o código fique incrivelmente mais fácil de testar, pois se não quisermos subir uma base em memória, ou uma base de dsv, só usamos lá um repository de arrays. O mesmo para os outros componentes de integração.

O que não fizemos foi deixar o core dos nossos micro serviços desacoplados do Spring e do JPA, porque isso sim seria custoso e exigiria mais complexidade. Preferimos não abrir mão da DI dos Beans dentro dos usecases, além de coisas como anotações de transaction, retry e coisas parecidas não nos pareceram valer o esforço de deixar desacopladas.

Dessa forma usamos a arquitetura de forma que fosse boa o suficiente para o time.

[alysson.cirilo]

Acho que vale marcar uma live com Uncle Bob ai hein kkk

[marcioborges]

Man, tirei o chapéu pra vc.
Fui reprovado em uma entrevista para desenvolvimento android, simplesmente, porque disse que o clean arch não se aplica a todas aplicações, pois, o esforço seria grande demais e desnecessário, uma vez, que estaríamos construindo algo específico.

A bronca é que o clean arch virou modismo. Espero que isso passe logo.

[educobuci]

O Uncle Bob não apresenta o Clean Architecture, em seu livro de mesmo nome, como uma solução para se proteger de obsolescência tecnológica, este é apenas um dos benefícios dela. O principal benefício apresentado por ele no livro é sobre a manutenção do software: a confiança que uma boa arquitetura unida a técnicas como o TDD proporcionam para o ciclo de desenvolvimento e evolução de um software.
Tenho muita experiência em desenvolver e entregar software de verdade, 18 anos precisamente, e sempre fui bastante cínico em relação ao TDD e Clean, em especial ao trabalho do Uncle Bob, Kent Beck e cia, mas quando eu finalmente entendi de verdade os fundamentos minha visão mudou completamente.
O principal fator que me fez mergulhar nesta escola foi a percepção do valor que o lean, design thinking, CI/CD e etc., trazem para o negócio, e que sem uma aplicação testada nada disso é possível, e é justamente isso o que uma arquitetura limpa te proporciona, confiança evoluir o software rapidamente e com confiança.
Assim como eu já fiz no passado, eu acredito que você e muitos outros críticos desta escola a estejam julgando de forma superficial, e que talvez não tenham nem mesmo lido o livro ou suas referências (a maioria apontada no início artigo do blog dele).
Por isso, gostaria de deixar minha sincera sugestão de que dê uma chance ao clean arch, beba da fonte e leia o material original do Uncle Bob, experimente em um pequeno projeto, e se ainda assim não entender como uma técnica desejável, tudo bem! Mas tenho certeza que ao final terá de fato um entendimento mais claro sobre o tema. Um abraço! Se precisar de alguma ajuda pode me contatar!

[LuisCarlos-pmmi]

Estou em um projeto que "usam" clean architecture e a coisa é difícil de navegar e entender. Tem muita interface e CrudUseCase pra coisa boba.

[diogocorreia]

Eu sempre pensei isso e achava que eu era maluco. Muito feliz com esse vídeo! Ganhou um inscrito.

[kevingood]

trabalho 5 anos na area e tenho uma certa opinião sobre isso, acho que é muito mais viavel a pessoa saber aplicar um clean code do que essas arquiteturas ai, a clean arch têm muitos pontos positivos, mas 90% desses pontos a pessoa não vai chegar a usar, porem com os pontos negativos… é horrivel debugar, leitura de código muito chato pq tem que ficar navegando de pasta em pasta e etc

eu prefiro o vertical arch para criar os apps, muito melhor msm.

[adbysantos]

PS: Não sou especialista em arquitetura; o que aprendi foi uma mescla de certa quantidade de estudo, prática e experiência compartilhada.

Estava assistindo e parei em 16:45, e a melhor parte da crítica até então foi: fazer um software que você abstrai tudo é um p*** de um esforço. Realmente é, digo por experiência própria.
Em um determinado projeto, nossa equipe iniciou sem conhecimento de como seriam feitas as requisições no banco de dados. Como usamos Clean Arch, a ideia de independência nos deixou tranquilos. Porém, quando recebemos a API, aconteceu um mini caos, pois algumas requisições dependiam de dados que não eram claros para quem vê o front. Então realmente essa ideia de independência (nesse caso, entre front e back) não rola. Poderia muito bem existir outra API, com outro tipo de burocracia, e teríamos que a seguir, ou seja, acoplar nosso front. Se fôssemos fazer o app realmente independente de API, apesar de eu minimamente conceber uma forma, seria, como dito pelo autor do vídeo, um p*** esforço.

(Sim, já terminei de ver o vídeo todo)

Como disse, não sou especialista em arquitetura. Simplesmente a organização de códigos e diretórios do Clean Arch faz sentido para mim. Pode ser que no futuro encontre uma organização melhor. Sou muito novo na área também.
Por fim, vou levantar essa discussão sobre "independência" com minha equipe; ela é, no mínimo, essencial.

[eliasmullerjava]

Normal, a galera quer uma bazooka pra matar mosca. Concordo com vc!

[marcioengsoft]

Ótima explicação.
Mas isso acaba magoando programadores java, que adora fazer uma pirotecnia gigantesta, para fazer um simples crud.

[fabiotc]

Acho que a proteção ao futuro e a possibilidade de substituir tecnologias é apenas mais um dos benefícios.
O principal, na minha opinião (e citado muitas vezes pelo Uncle Bob) é a possibilidade de ADIAR decisões, onde escolhas e implementações como de banco de dados, framework web, APIs externas, documentação de apis, escolha de endpoints, etc não precisam ser decididas (e implementadas) no começo do projeto, e o foco ser somente nos casos de uso e no domínio do problema.
E principalmente deixar tudo muito mais fácil de testar, onde por "regra" sempre temos a menor implementação de referência possível, e também "força" o time a pensar muito mais em abstrações do que implementações.

[ebr]

posso ter entendido errado, pra mim não ficou claro o que você considera clean arch, mas não acho que uma aplicação baseada em clean arch necessariamente teria a mesma complexidade do spring ou de qualquer outro fw de mercado

particularmente, entendo que a proposta central do uncle bob é isolar as regras de negócio (domain e application) do mundo externo, e também nunca permitir que usecases chamem uns aos outros, diferente do que acontece com application services em ddd… pois evitando essas chamadas é muito mais fácil testar a camada application

não vejo como esses pontos centrais da clean arch podem trazer complexidade p/ uma aplicação ou time de desenvolvimento… ter o cuidado de não importar libs externas no domínio e tipar entradas, saídas e injeções dos usecases, no final das contas, é um pequeno preço a se pagar em comparação aos problemas que podem decorrer de um acoplamento total de software… faker e log4j estão aí para provar isso

também acho que é possível isolar as regras de negócio e ainda utilizar frameworks e libs para compor demais camadas… tudo depende do negócio, tempo e senioridade do time… uma regra que acho inegociável, e que vc clarificou ainda mais ao citar o caso da alura utilizando scala, é a importância de não ser fanboy de tecnologia… entendo que cada ferramenta foi feita para um propósito diferente, e ainda que seja possível resolver o mesmo problema de várias formas, não significa que não exista uma forma ideal para cada situação

uma coisa é certa, variáveis existem dentro e fora dos editores de texto… e o dev eficiente é aquele que sabe lidar da melhor forma com a junção de todas elas 😄😄