ARQUITETURA HEXAGONAL NA PRÁTICA COM SPRING BOOT | Conheça a implementação deste microsserviço

[@falchi8048]

pediram esse tema em uma entrevista pra pleno, sinceramente sinto que bombei por nao conhecer tao a fundo essa arquitetura, obrigado pelo video

[@jeanjacquesbarros]

Estava a dias procurando um vídeo assim, que explicasse de forma simples como ficaria essa arquitetura com Spring. Muito bom! Parabéns!!

[@gusrubin]

Parabéns pelo vídeo. Eu costumo deixar o domínio livre dos DTOs também, eu considero o DTO como responsabilidade da application, entao é ela que tem que se virar para transformar o DTO em objeto de domínio e vice-versa

[@leandrosoares6]

Boa gustavo!

[@gusrubin]

@User6497 Faz muito sentido sim, obrigado pela explicação, vou repensar minhas implementações, eu só não sei se deveria reaproveitar o DTO como objeto de entrada do domínio ou se deveria criar mais um objeto de request, o que você acha?

[@abdulsacur2615]

​@User6497 faz sim!

[@pabloceni6905]

Explicação excelente de ambos os videos, tanto o teórico como o prático. Parabéns!

[@andreoliveirasantos9727]

Muito bom amigo meus parabéns

[@alexasasouza]

Simple e direto ao ponto. Parabéns.

[@Matheus581]

Obrigado pela didatica e explicação, os 2 viddeos com certeza me ajudaram no entendimento disso

[@amandamuniz7748]

Didática SENSACIONAL

[@euivanw]

Obrigado por compartilhar seu conhecimento

[@tiagoornelas964]

Muito obrigado pelo vídeo!!! Consegui entender e aplicar para o projeto que estou trabalhando.

[@marlonscastro]

Caramba, meu amigo.. que show hein ? Sem lenga lenga, foi direto ao ponto.. Top. 👏🏻👏🏻👏🏻👏🏻

[@lucashenrique6076]

Muito bom Danilo, continua fazendo vídeos, eu assisti vários sobre essa arquitetura e achei muito confuso, e no seu voce em 5 minutos explicou tudo que era necessário um iniciante saber, e agora em 12 minutos consolidou a parte teórica, vou ate fazer um novo projeto aqui seguindo esses ensinamentos pra fixar melhor, valeu cara tudo de bom!!

[@DaniloCaneschi]

Que bom Lucas. Fico feliz por ter contribuído com seu aprendizado.

[@lopesleticiam]

Incrível! Muito obrigada 💪

[@henriquemundowap5046]

Muito bom, sou dev PHP e consegui entender tudo, explicou muito bem!

[@pedroalbertogomes3809]

Muito obrigado. Uma dúvida, onde eu botaria anotações do tipo oneToMany ? Na entidade ou no domínio ?

[@leandromoreira7115]

Tenho uma duvida porq vc tem adptador dentro do seu core domain service já que esse adptador deveria estar fora do core acessando o uma porta?

[@nailtonsimoes3738]

show de bola amigo!! muito bom

[@vitormomberg9461]

Excelente! Muito obrigado por compartilhar esse conhecimento.

[@LucasArkantos]

Passar Produto como como parametro do construtor de ProdutoEntity não cria uma hyper-depedencia de classe? Neste caso viiolando o SOLID?

Parabéns pelo conteúdo!

[@java-lab]

A injeção de componentes pode ser melhorada fazendo as portas implementarem uma interface comum e configurando @ComponentScan na classe de configuração dos beans. Assim, não é necessário definir manualmente cada bean.

[@lucasteodoro3833]

Amigo, sua didática é excepcional. Fez algo que pra mim é extremamente complexo, parecer simples. Parabéns! Mas continue seus ensinos por favor.

[@wilsonreis3469]

Parabéns Danilo. Apresentação e código impecáveis. Agradecido pelo compartilhamento.

[@raulvitoriano5635]

Parabéns pelo conteúdo! Rápido e uma boa didática.

[@italobaciliere2081]

Obrigado Danilo, seu trampo é o melhor desse KZbin!!!

[@pedroeuropeu]

Muito bom. Um conceito muuuuito antigo(arquitetura hexagonal) e que agora entrou no "Hype". Mas bela explicação

[@CViniciusSDias]

Olá, Danilo. Se você for em View, na IDE, tem um modo de apresentação. Fica bem melhor de ver. Eu, por exemplo, tive que deixar pra ver o vídeo depois porque não dá pra acompanhar pelo celular com esse tamanho de fonte. Abraços!

[@DaniloCaneschi]

Valeu Vinícius. Vou tomar cuidado com isso para os próximos vídeos.

[@leandrosoares6]

Cara eu li livros e vi várias explicações de Arquitetura Hexagonal, até criei umas implementações no meu git mas ainda não vi explicação mais simples e direta ao ponto que essa. Meus parabéns e obrigado por partilhar seu conhecimento!

[@DaniloCaneschi]

Que bom Leandro que achou o entendimento fácil. Mas não descarta os livros cara, são importantes.

[@gabrieldragone]

Ótimo video, mto bem explicado. Obrigado!

[@gabrieldragone]

Vc poderia disponibilizar um exemplo aplicando testes unitários tbm?

[@naianesilvadacostabatista9267]

Maravilhosa aula... Obrigada Mestre!

[@DaniloCaneschi]

Que bom que gostou.

[@pedroppd]

Pode fazer mais vídeos assim ? mostrar mais exemplos, sempre tive essa dúvida de como fazer clean arq com Spring

[@lmfacchini]

Valew mesmo. Muito bom.

[@danilocatapan]

Opa, parabéns pelo vídeo... muito bom!!!

[@edmilsonvasconcelos1720]

Muito legal, me deu uma visão massa. Muito obrigado!

[@luizgustavo2341]

Parabéns pelo vídeo! Me ajudou a entender um pouco mais sobre arquitetura hexagonal.

[@maxdavisdesign]

Parabéns pelo vídeo! Didática excelente.

[@fabricionicolato5276]

Muito bom Danilo!

[@DaniloCaneschi]

Valeu

[@pauloricardonoe]

Ótimo conteúdo Danilo. Parabéns!

[@DaniloCaneschi]

valeu Paulo

[@kotov2]

Parabéns pelo vídeo. Uma dúvida, Danilo. No caso das validações de dados, como seria feita? As anotações de validation seriam colocadas nas classes dtos dentro do pacote domínio?

[@DaniloCaneschi]

Valeu Batista. Sim, nas classes dto pra validar a entrada dos dados. Também pode adicionar na entidade, ao persistir no banco de dados

[@wellingtondivino8263]

Conteúdo top, Danilo!

[@DaniloCaneschi]

Valeu

[@alexandrerogerio7520]

Ótimo conteúdo

[@marcelbarbosa281]

Achei muito bom novamente, valeu Danilo! Tenho algumas sugestões, quando você cadastrar um produto acho que seria melhor retornar o status 201 (created) e fiquei um pouco confuso em relação ao ProdutoRepository, ele faz algumas validações como por exemplo, quando busca um produto ele valida se o produto existe antes de retorná-lo, caso ele não exista ele lança uma RuntimeException, será que essas validações não fazer parte do domínio? Mesmo que sejam regras simples acho que compensaria deixá-las no domínio e abusar do Optional na classe que implementar o ProdutoRepositoryPort, o que você acha?

[@DaniloCaneschi]

Boa Marcel. Correto é retornar 201 mesmo. Acredito que faz sentido sim, ficar no domínio, mas depende muito do projeto.

[@avpfer]

É possível refatorar essa aplicação para que funcione sem o Spring ?

[@DaniloCaneschi]

É possível sim. Hexagonal serve pra desacoplar a regra de negócio só mundo externo, por isso cabe a projetos que não usam spring.

[@franciscopereira5702]

Excelente conteúdo!!

[@DaniloCaneschi]

Valeu

[@felipeguimaraes2568]

Curti! Vai me salvar num trabalho da faculdade.

[@DaniloCaneschi]

Show Felipe

[@bernardosilvaneves3732]

Opa, uma duvida quero aplicar hateoas nessa estrutura, no padrão spring-hateoas vou precisar de um modelo para estender da classe Representation, só que como tou passando o DTO para o controller e ele esta no domínio da api não posso mexer nele, não isso ? como faria para ter essa segunda camada de DTO ?

[@DaniloCaneschi]

E aí Bernardo! Você pode modificar sim, a classe DTO, pois ela serve para transferência de dados. Uma melhor solução seria você criar um wrapper responsável por converte-los em EntityModel e CollectionModel utilizando generics, que pode ficar na camada de aplicação.

[@bernardosilvaneves3732]

@@DaniloCaneschi entendi obg!

[@esbnet]

Danilo, uma dica: quando for gravar o código, busque aproveitar toda a área da tela. Com tela cheia muitas vezes não consigo ler, a letra está muito pequena. Mas o conteúdo está ótimo.

[@DaniloCaneschi]

Além disso aumentar o tamanho da fonte também. Vlw Edmilson.

[@pbeanni]

OI Danilo, adorei o conteúdo, tenho interesse em me aprofundar no estudo das arquiteturas e principalmente na utilização delas com Spring, tens alguns livros que tu recomendas ? na tua opnião existe uma preferencia de arquitetura no mercado spring ? clean ou hexagonal ? muitas duvidas hahahah

[@julianorazzo8392]

por isso que JAVA tá virando uma liguagem chata. era tão simples (Controller, Service,Repository)

[@paulomatos1087]

vc ainda pode trabalhar desse jeito... mas dividir em camadas nao garante uma arquitetura limpa. E esses principios se aplicam a qualquer linguagem, nao apenas Java

[@d.martins4471]

Isso é a exatamente mais do mesmo, com você adicionando a complexidade desnecessária de agora ter dois lugares pra refatorar uma assinatura caso precise: interface e classe de implementação. Absolutamente totalmente desnecessário. Mil vezes melhor utilizar apenas uma classe controller, que chama um service que por sua vez pode chamar um facade ou um repository. Mais uma "arquitetura" de pura lorota, com mais do mesmo, utilizando diferentes nomes para os bois(ports, e blablabla).

[@DiegoHammesHoffmann]

Mas que raiva toda é essa? Kkkkkkkkk

[@didamendes]

Excelente aula. Essa modinha do arquitetura hexagonal e fod0. E so para escrever mais codigo. E ficar mais complexo. Não sou fã da arquitetura hexagonal. Cada pessoa defini sua propria lista de pacotes. Exemplo se ver outras aulas sobre hexagonal, vai ver nomes diferentes estrutura de pacotes, parece que não tem padrão, e sim o modo que a pessoa entendeu o Hexagonal.