Clean Architecture e Hexagonal architecture: Explicando no detalhe o propósito e as semelhanças

O objetivo deste episódio é te mostrar que pouco importa se você vai utilizar Arquitetura Limpa ou Hexagonal, simplesmente porque elas tentam resolver o mesmo problema.
Dentro do vídeo você vai encontrar três explicações: Uma comigo só falando, outra comigo mostrando os desenhos das arquiteturas diretamente dos textos originais e a última comigo mostrando o código que implementa as ideias.
Entendendo os princípios, você vai perceber como tudo fica mais claro.
Como sugestão: Depois de ver o vídeo, tente explicar para as pessoas que você conhece sobre as duas arquiteturas :).
Saiba mais sobre a Jornada Dev Eficiente:
Por um valor acessível você tem acesso a uma jornada de estudo e treino excelente sobre Design de Código. Confere em deveficiente.com :).
Saiba mais sobre mim :)
Github: github.com/asouza
Twitter: / alberto_souza
Instagram: / deveficiente
Links
* Explicação visual sobre Dual Coding - static1.square...
* Vídeo sobre dual coding - • Estilo de aprendizado ...
* Vídeo criticando o uso exagerado de arquiteturas em camadas - • Clean architecture: Pr...
* Vídeo refatorando um código para seguir os princípios da arquitetura em camadas - • Clean Architecture: Ex...

[@DevEficiente]

Para saber mais sobre a Jornada Dev Eficiente acesse deveficiente.com/

[@davidwelber]

Assistindo em 2024. O legal desse tema é que não tem data de validade. Parabéns e muito obrigado!

[@DevEficiente]

Legal demais que gostou !

[@ramilani12]

Parabéns Alberto um vídeo bem explicativo e direto! Li tanto o artigo do Bob e Cockburn e a impressão explicaram da mesma forma usando termos diferentes.

[@DevEficiente]

Opaaa, sinto o mesmo. Apesar que considero que Bob Martin tentou nomear mais partes, justamente pq ele sentia falta desse direcionamento mais claro de como ir dividindo. Para mim é muito sobre granularidade mesmo.

[@afsdab]

Excelente vídeo !!

[@DevEficiente]

Opa, massa que gostou!

[@gustavodeoliveira8316]

Muito show! Gosto muito dessa arquitetura, mas vejo que temos muita duplicação de código com ela também, a fim de eliminarmos a dependencia circular e preservarmos a capacidade de plug and play. Parabéns pelo video!

[@dsteixeira]

Alberto, que video esclarecedor. Muito obrigado por compartilhar essa visão, aprendo bastante com seus videos. Um abraço!

[@DevEficiente]

Ah Daniel, fico muito feliz que ele seja útil! Espero continuar colaborando.

[@jeffersonsantosoliveira8314]

Eu participei de um projeto anterior que usava a risca o Clean Arch, estou em outro projeto que a galera resolveu usar Hexagonal. Pelo que eu entendi dos dois, é que um é mais engessado(Clean Arch) e o outro é mais a gosto do time(Hexagonal) Digo a gosto do time pq vi diversas formas diferente que a galera implementa o Hexagonal e que atinge o mesmo objetivo. Pensei a mesma coisa que você Alberto. Quando tentei entender a diferença entre essas duas, senti que é a "mesma coisa"

[@DevEficiente]

Opa Jefferson, bom demais! É isso mesmo :).

[@igoroxy]

Muito legal o vídeo Alberto, acho que seria legal você compartilhar um pouco de quantas vezes na sua carreira você já viu projetos implementando essas arquiteturas na prática, em sistemas reais e quais sao suas impressões. Inclusive falar um pouco dos problemas que implica em usar essa arquitetura em um cenário de sistemas grandes com N times de devs de diferentes níveis de experiência. Valeuu e parabéns pelo vídeo!

[@DevEficiente]

Oi Igor, vou pensar em algo a respeito e tentar trazer!

[@gilsonsilva1439]

Top, como sempre!!!

[@DevEficiente]

Ahh, valeu demais!

[@antoniolazaro1]

Muito bom. Mas arquitetura hexagonal e clean architecture hoje são questões de processo seletivo. Quando na real, deveria se questionar sobre design....OO bem feito, tira necessidade de muitas ideias.

[@DevEficiente]

Opa Antonio, infelizmente são mesmo. Inclusive já escutei relatos de gente cortada pq não usou x ou y, uma pena.

[@otoniel.duarte]

Excelente conteúdo.

[@DevEficiente]

Opa, valeu demais!

[@RafaelDiasMello]

Muito bom!

[@DevEficiente]

Massa demais que curtiu!

[@edmarsoares9981]

Olá . Pensando em microservices com arquitetura em 3 camadas (controller, service e repository) , faz sentido refatorar pra uma arquitetura hexagonal?

[@DevEficiente]

Oi Edmar, acho que aí precisamos de mais contexto. Minha política com refatoração é que precisa existir um objetivo muito nítido para que ela seja feita. Sem isso, pode ser um caminho que não leve para o lugar ideal

[@eduardocar8305]

Fiquei com uma dúvida... eu posso receber Compra no UseCase e fazer a transformação DadosNovaCompra->Compra no controller? Falo isso pelo fato de poder evoluir minha api para DadosNovaCompraV2 e não quebrar meu domínio. Será que faz sentido? (não sei se consegui me explicar)

[@DevEficiente]

Oi Eduardo, acho que o efeito colateral da solução proposta é que você cria a compra num ponto do fluxo e altera o sistema em outro. Uma prática que considero interessante e tento manter o máximo que posso é que só quem criou o objeto pode alterar seu estado ou alterar o estado do sistema em função dos dados que estão contidos ali. Caso contrário o tracking começa a ficar mais complicado e cada método pode assumir que o anterior pode ou não ter salvado no banco, gerando um acoplamento mais tenso.

[@eduardocar8305]

@@DevEficiente Muito obrigado pela resposta!!

[@eduardocar8305]

@@DevEficiente Eu não deveria ter uma camada "anticorrupção" entre o controller e o usecase? isso para ter mais independência entre o dto que estou expondo pela api rest e o input do usecase. Me parece que da forma como foi implementado, qualquer alteração no dto que está sendo exposto pela api rest, impactara no usecase. O que vc acha?

[@DevEficiente]

@@eduardocar8305 opa, acho que a interface já cumpre o papel. O que chega no caso de uso é uma referência através da interface. A única necessidade é saber criar uma compra. Isso pode vir de um adapter http, grpc, protocolo de mensagem etc. Pelo menos eu acho :)

[@eduardocar8305]

@@DevEficiente Realmente faz sentido. Primeira vez que vejo o input do usecase sendo uma interface. Parece que resolve mesmo... Valeu pela resposta!!! Estou indicando o canal para meus colegas, o conteúdo está sensacional!!