Aprenda DDD + ImplementaçÃĢo com Arquitetura Hexagonal
āļāļąāļ
- āđāļāļĒāđāļāļĢāđāđāļĄāļ·āđāļ 6 āļ.āļ. 2025
- ðĪĐ Seja membro deste canal e ganhe benefÃcios:
/ @giulianabezerra
ð PÃĄgina Pessoal:
home.giulianab...
ð Conheça tambÃĐm os meus conteÚdos em outras plataformas:
Blog: / giulianabezerra
Curso de Java: bit.ly/3SKsBLz
Curso de Spring Batch: bit.ly/3ZgQXOB
Curso Avançado de Spring Batch: bit.ly/44PV2u1
Curso de Testes com Spring Boot: bit.ly/3sOig6w
Curso de AdonisJS: bit.ly/3ZhRXlu
ParabÃĐns pelo Ãģtimo conteÚdo. Voto sim pelo vÃdeo de arquitetura hexagonal tenho certeza que vai ser incrÃvel tal qual os demais conteÚdos do canal!
Excelente vÃdeo! Quero mais vÃdeos de arquitetura hexagonal. Muito obrigado, Giuliana!
Sobre a arquitetura Hexagonal, jÃĄ que perguntou ð Seria incrÃvel termos conteÚdos sobre!! E mais uma vez muito obrigado pelo conteÚdo.
Ela ÃĐ sempre muito clara em suas explicaçÃĩes. Uma referÊncia âĪ
Muito bom vÃdeo. Vc tem uma excelente didÃĄtica. Na expectativa para ver um material seu sobre arquitetura hexagonal
essa mina ÃĐ monstra em questÃĢo de conteudo kkk
No inÃcio, durante a explicaçÃĢo tÃĐcnica baseada nos livros, eu nÃĢo estava entendendo. Mas quando chegou na parte do cÃģdigo ficou bem mais claro. Excelente abordagem.
Na faculdade eu tinha muita dificuldade em entender esses conceitos dos livros, ficava sempre muito abstrato. Futuramente gostaria de ver uma explicaçÃĢo assim sobre arquitetura hexagonal, assim como as outras arquiteturas, se possÃvel.
Muito bom conteÚdo, obrigado!
ParabÃĐns pelo conteÚdo, muito bom!
Faz um vÃdeo sobre Hexagonal!
Excelente conteÚdo, parabÃĐns!
Valeu!
Obrigadaa! ððĪ
Muito bom seu vÃdeo, por favor, faça um para mapeamento e como identificar entidades, objeto de valor, agregados e raiz de agregados.
Ãtima sugestÃĢo!
parece que leu minha mente, estava pensando em procurar um conteudo sobre ddd e hexagonal com spring e me aparece seu video
Adoraria o vÃdeo mais explicativo sobre a arquitetura haxagonal
Sempre Ãģtimo conteÚdo, Giuliana. Obrigado
E sim, por favor, traga o conteÚdo sobre arq. hexagonal :)
Muito bom o video, como todos os outro do canal, parabÃĐns. Tem uns dias que descobri o Modulith do spring e estou estudando para criar uma poc para melhorar algumas coisas na empresa.
Sim, ÃĐ bem interessante, e essa parte de eventos muito bacana tbm
giuliana, vocÊ poderia fazer um vÃdeo mostrando como vocÊ aborda documentaçÃĢo? como vocÊ faz pra entender, por exemplo, uma biblioteca em Java com pouca familiaridade
eu, enquanto iniciante, acho extremamente importante e nÃĢo vejo muitas pessoas comentando sobre
se possÃvel, tambÃĐm seria legal recomendaçÃĢo de leitura
Obrigada pela sugestÃĢo! JÃĄ anotei aqui pra falar a respeito ð
Ãtimo conteÚdo! Por favor, grave mais videos :)
ParabÃĐns pelo conteÚdo! :) Gostava de ver um video sobre hexagonal mas tambÃĐm comparar com outras arquiteturas e quando escolher qual. Valeu
ParabÃĐns, Giuliana! O vÃdeo sobre DDD foi simplesmente excelente, muito claro e bem estruturado. Fiquei especialmente interessado nos conceitos que vocÊ abordou e gostaria de sugerir que vocÊ trouxesse conteÚdos sobre arquiteturas como Hexagonal, Clean Architecture e a tradicional Arquitetura em Camadas. Acredito que seria um complemento perfeito ao tema do DDD e ajudaria ainda mais a comunidade a entender como aplicar esses padrÃĩes em projetos reais.
AlÃĐm disso, gostaria de saber se vocÊ tem alguma dica de como começar a leitura do livro sobre DDD e, principalmente, como aplicar os conceitos na prÃĄtica durante a leitura. Qual seria a melhor abordagem para absorver o conteÚdo e utilizÃĄ-lo no meu dia a dia de desenvolvimento?
Muito obrigado pelo excelente trabalho!
Obrigada! Sobre clean arch eu tenho um vÃdeo no canal, sobre hexagonal anotei aqui pra fazer. Em relaçÃĢo ao livro, acho que sÃģ vale a pena começar quando vc estiver num ambiente corporativo e jÃĄ tiver alguma experiÊncia nele. A leitura ÃĐ chata entÃĢo se vc tiver uma motivaçÃĢo , projeto no trabalho por exemplo, fica mais fÃĄcil terminar. Durante a leitura sugiro que vÃĄ fazendo anotaçÃĩes para revisar depois, pois ÃĐ bem provÃĄvel que nÃĢo fique tudo claro na primeira leitura e serÃĄ necessÃĄrio revisar. E ter paciÊncia, o livro acaba sendo beeem abstrato, entÃĢo tentar exercitar os conceitos ajuda a consolidar todo o conhecimento (esse vÃdeo ajuda nisso)
Giuliana, boa tarde! Por favor, tenho interesse em aprender mais sobre arquitetura hexagonal. Muito obrigado por compartilhar seu conhecimento.
Sou da turma torcendo por um vÃdeo da arquitetura hexagonal hahahað
Muito bom o conteÚdo, traz vÃdeo sobre hexagonal por favor, seria bom um exemplo com comunicaçÃĢo com uma api externa
Por favor, trÃĄs as varias Arquitecturas! Estou a adorar Professora :)
Ãģtimo conteÚdo.
Muito bom , gostaria de ver esse vÃdeo de arquitetura hexagonal.ðð
Esse assunto ÃĐ muito bom. Eu jÃĄ criei um projetinho com arquitetura hexagonal e DDD a um tempo atrÃĄs pra pÃīr em prÃĄtica. Mas o que me trÃĄs aqui ÃĐ que depois tentei fazer um outro projeto que utiliza esse conceito, mas agora com Spring WebFlux e nÃĢo consegui achar uma forma de manter fora do domÃnio o framework. E agora nesse exato momento estou começando um outro onde quero usar o spring security nessa arquitetura e me vi sem saber novamente como manter o framework fora do domÃnio ðĐðĪ·ââïļ
Video Top! Faz um prÃģximo sobre Arq Hexagonal
Seria interessante mesmo trazer um vÃdeo sÃģ sobre o modelo Hexagonal
Seria interessante um conteÚdo sobre hexagonal.
Faz um vÃdeo de Arquitetura Hexagonal
Muito bom! Obrigado. Inscrevi-me
Muy bueno y preciso,good
is my favorite DDD
na sua camada de domÃnio tem referencia do Spring, isso nÃĢo quebra alguns princÃpios?
Na teoria sim, na prÃĄtica acho que vale o senso crÃtico. Pq o cÃģdigo referenciado ÃĐ uma anotaçÃĢo em uma interface. Esse ÃĐ um acoplamento fraco, se precisar mudar o âdetalheâ basta criar a implementaçÃĢo nova da interface. EntÃĢo nÃĢo vejo como algo negativo pq ÃĐ fÃĄcil mudar sem mexer em vÃĄrios lugares do projeto
@@giulianabezerra boa, vlw a explicaçÃĢo.
agregados tem acesso direto a repositÃģrios?
Poder pode, mas os mais puristas vÃĢo dizer que nÃĢo. Se for pela interface nÃĢo vejo grandes problemas, melhor do que criar outros objetos/abstraçÃĩes pra fazer isso que adicionam complexidade. Pensando no modelo rico ÃĐ algo bem interessante em certos cenÃĄrios. E quem for contra, gostaria de saber o porquÊ aqui nos comentÃĄrios, discussÃĢo saudÃĄvel ÃĐ claro (como sempre nesse canal) ð
ParabÃĐns pelo conteÚdo, mas fiquei com uma dÚvida. Uma repository deve ser chamada dentro de um objeto de domÃnio?
EntÃĢo, em teoria nÃĢo. Mas se vc pensar bem, chamar a interface pode pq a implementaçÃĢo, que em tese teria o cÃģdigo do framework, estaria dentro do pacote de infraestrutura. EntÃĢo nÃĢo acho problemÃĄtico nesse caso ter essa interface de repositÃģrio dentro do domain, pq se for necessÃĄrio usar outra ferramenta ÃĐ sÃģ criar a implementaçÃĢo nova dessa interface no pacote de infraestrutura.
braba demais
Como vocÊ falou perto do final do vÃdeo, isso nÃĢo parece arquitetura hexagonal (Ah que eu conheço) e a parte do DDD tambÃĐm tÃĄ diferente da forma que eu aprendi, confesso que deu uma bugada na minha mente, mas foi bom o vÃdeo atÃĐ pra pegar coisas novas.
Pois ÃĐ, atÃĐ os caras mais experientes usam variaçÃĩes das arquiteturas, algo a refletir (projeto apresentado no spring IO). A gente nÃĢo deveria se limitar a apenas aplicar as receitas de bolo sem pensar de forma crÃtica, entÃĢo eu tbm costumo aplicar variaçÃĩes em todas essas arquiteturas, variaçÃĩes conscientes ÃĐ claro.
Like ð
essas arquiteturas ddd, clean arch etc sÃģ funcionam 100% em tutorias, porque num projeto real onde os requisitos estÃĢo mudando o tempo todo, acaba sendo muito trabalhoso manter o cÃģdigo seguindo a arquitetura com prazo de entrega curto, logo o "melhor" (mais rÃĄpido) padrÃĢo/arquitetura de projeto ÃĐ o bom e velho mvc
Toda arquitetura âfuncionaâ, ÃĐ cÃģdigo, a questÃĢo ÃĐ se os benefÃcios superam os contras. No mundo gohorse aà de fato nada resolve problema algum, pq o problema ÃĐ o go horse. Infelizmente esse ÃĐ o modelo predominante na maioria das empresas pequenas de ti (nas grandes nÃĢo costuma ser assim, provavelmente ÃĐ por isso ÃĐ que elas crescem)