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
@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?
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!!
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!
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!
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.
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?
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?
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.
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 ?
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.
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
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
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).
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.
Estava a dias procurando um vídeo assim, que explicasse de forma simples como ficaria essa arquitetura com Spring. Muito bom! Parabéns!!
Muito bom amigo meus parabéns
Explicação excelente de ambos os videos, tanto o teórico como o prático. Parabéns!
Caramba, meu amigo.. que show hein ?
Sem lenga lenga, foi direto ao ponto..
Top. 👏🏻👏🏻👏🏻👏🏻
Obrigado por compartilhar seu conhecimento
Simple e direto ao ponto. Parabéns.
Didática SENSACIONAL
Obrigado pela didatica e explicação, os 2 viddeos com certeza me ajudaram no entendimento disso
show de bola amigo!! muito bom
Incrível! Muito obrigada 💪
Parabéns pelo conteúdo!
Muito obrigado pelo vídeo!!! Consegui entender e aplicar para o projeto que estou trabalhando.
Muito bom, sou dev PHP e consegui entender tudo, explicou muito bem!
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
Boa gustavo!
@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?
@User6497 faz sim!
Excelente!
Muito obrigado por compartilhar esse conhecimento.
Parabéns Danilo. Apresentação e código impecáveis. Agradecido pelo compartilhamento.
Ótimo video, mto bem explicado. Obrigado!
Vc poderia disponibilizar um exemplo aplicando testes unitários tbm?
Obrigado Danilo, seu trampo é o melhor desse RUclips!!!
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!!
Que bom Lucas. Fico feliz por ter contribuído com seu aprendizado.
Parabéns pelo conteúdo! Rápido e uma boa didática.
Muito bom. Um conceito muuuuito antigo(arquitetura hexagonal) e que agora entrou no "Hype". Mas bela explicação
Maravilhosa aula... Obrigada Mestre!
Que bom que gostou.
Amigo, sua didática é excepcional. Fez algo que pra mim é extremamente complexo, parecer simples. Parabéns! Mas continue seus ensinos por favor.
Opa, parabéns pelo vídeo... muito bom!!!
Muito legal, me deu uma visão massa. Muito obrigado!
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!
Que bom Leandro que achou o entendimento fácil. Mas não descarta os livros cara, são importantes.
Parabéns pelo vídeo! Didática excelente.
Ótimo conteúdo
Parabéns pelo vídeo! Me ajudou a entender um pouco mais sobre arquitetura hexagonal.
Valew mesmo. Muito bom.
Ótimo conteúdo Danilo. Parabéns!
valeu Paulo
Conteúdo top, Danilo!
Valeu
Curti! Vai me salvar num trabalho da faculdade.
Show Felipe
Muito bom Danilo!
Valeu
Excelente conteúdo!!
Valeu
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!
Valeu Vinícius. Vou tomar cuidado com isso para os próximos vídeos.
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.
Muito obrigado. Uma dúvida, onde eu botaria anotações do tipo oneToMany ? Na entidade ou no domínio ?
Pode fazer mais vídeos assim ? mostrar mais exemplos, sempre tive essa dúvida de como fazer clean arq com Spring
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?
Boa Marcel. Correto é retornar 201 mesmo. Acredito que faz sentido sim, ficar no domínio, mas depende muito do projeto.
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?
Valeu Batista. Sim, nas classes dto pra validar a entrada dos dados. Também pode adicionar na entidade, ao persistir no banco de dados
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?
Passar Produto como como parametro do construtor de ProdutoEntity não cria uma hyper-depedencia de classe? Neste caso viiolando o SOLID?
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.
Além disso aumentar o tamanho da fonte também. Vlw Edmilson.
É possível refatorar essa aplicação para que funcione sem o Spring ?
É 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.
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 ?
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.
@@DaniloCaneschi entendi obg!
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
por isso que JAVA tá virando uma liguagem chata. era tão simples (Controller, Service,Repository)
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
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).
Mas que raiva toda é essa? Kkkkkkkkk
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.