Aquí tenéis disponible el código de ejemplo del vídeo de esta semana sobre Arquitectura Hexagonal con #Java #SpringBoot y #PostgreSQL . Buen fin de semana -> github.com/acoronadoc/java-springboot-hexagonal-architecture-sample
Muchas gracias, es muy dificil encontrar contenido de esta calidad con casos prácticos. Esto tiene mucho valor para los que estamos aprendiendo arquitectura. Saludos!!!!!
Volvió¡ Que bueno¡ Estoy aprendiendo mucho con sus videos¡ Usted esta muy adelantado a los temas y muy actualizado, dele tiempo a su canal y será millones¡ Desde Córdoba, Argentina todos los éxitos y gracias por tanto¡
Te felicito por tu trabajo. grandiosa y muy util explicación.
2 роки тому+7
Se te echaba de menos. Gracias por este pedazo de vídeo. Como decías, las arquitecturas hexagonales se terminan tergiversando por la simplificación del concepto. Gracias al ejemplo lo tenemos más claro. Temas interesantes: patrones CQRS, Event Sourcing y Sagas. También estaría interesante explicar en una serie, algunos de los consejos más útiles del código limpio
Mi querido Albert tu canal me ha servido de mucho para repasar temas. Ojalá te animes en un futuro a hablar y demostrar cosas no tan conocidas o poco habladas, que se encuentran difícilmente en internet, como el tema de Kubernetes de hacer actualizaciones progresivas sin tiempo de inactividad del servicio "Rolling updates"...
Encantado de volver a verte, yo creo que seria interesante repasar temas de monitorización (grafana, nagios, elastic...) y un poco de AWS. Muchas gracias por compartir
Acabo de encontrar tu canal y estoy viendo los vídeos anteriores. Solo puedo decir que todos tus videos son oro puro. Tienes conmigo un seguidor más , veo que dejaste de subir durante un tiempo, espero no haber llegado muy tarde y que no desistas de crear estos videos tan buenos! Muchas Gracias por compartir tu experiencia con el mundo, y apenas tenga oportunidad, más que suscribirme, me unirme a tu canal.
Este contenido me ha servido para aclararme un poco más con un problema que estoy teniendo en el mismo caso de un proyecto de CRM para una tienda y no consigo desde mi proyecto con Springboot inserte datos utilizando Hibernate H2 tiene como registros customers, products, price...
Excelente explicación!, apenas estoy aprendiendo y explicas muy bien, otra cosa es que no he visto muchos ejemplos del lado del front. y otros ejemplos he visto que todas las interfaces van en el dominio porque es el que define las reglas. tal vez como tu dices no he visto un estandar en el scafold de carpetas. un saludo desde colombia y aqui tienes un sub mas!
Muchísimas gracias por hacerte un tiempo a pesar de que ahora te cuesta más sacar espacio para esto, hacía tiempo que no veía nuevos vídeos por el canal, que bueno que lo vuelvas a retomar aún si ya no se puede al ritmo de antes. Me gusta mucho la forma en la que explicas, ayudándome mucho a entender algunos conceptos que me son nuevos, gracias desde Chile
La verdad que me ha gustado mucho el video, es largo pero necesario, con el ejercicico práctico se aclaran muchas dudas, ya que consultas por ahí y cada uno lo hace como quiere, respetando un poco los conceptos base, ... más o menos. Me asalta 2 dudas: i) Al usar el objeto de dominio en el adaptador de BBDD. Dado que pensaba que los objetos de dominio solo se usaban dentro de la capa application. ii) El uso de un repositorio genérico, que entiendo que puede ser muy corto cuando precises de búsquedas específicas, no se si sería mejor tirar por Spring Data Jpa. Además, que entiendo que si vas haciendo aplicaciones pequeñas, quizás no haya tantos repositorios.
Qué buena explicación hace falta más ingeniería de software, estamos plagados de información de las tecnologías como React, Angular, JavaScript, Vue.js, Etc. pero de esto muy poco y extremadamente importante, yo ya me he hecho cursos como clean code, me falta aprender programación funcional, patrones diseño, tengo esto por los momentos aplazados, ya que se me dio recientemente la oportunidad de estudiar en seguridad cero Ethical Hacking Professional luego seguiré mis estudios de todo lo que es arquitectura del software e ingeniería del software, si tienen alguna recomendación de que valoran más las empresas y se necesita estudiar se los agradecería, a darle átomos 🤜🤛🤓🚀
Que genial que vuelvas a generar contenido, hexagonal es un gran tema eso si en mi opinión los puertos no fueron implementados de la manera que significan de verdad los puertos de entrada son interfaces que interactúan con el dominio y los puertos de salida son los que interactúan con componentes externos al dominio lo mismo para las capa de application ejemplo: un repositorio sería un puerto de entrada y una interface que envíe un correo o ejecute una acción externa al dominio o sea no lo modifique sería un puerto de entrada. Pero como dijo en el video no existe una receta rígida para implementar hexagonal
"Si no es fácil de testear no se está haciendo bien" me quedo mucho con esa frase. La gran mayoría de arquitecturas hexagonales en las que trabajé o no tienen test o tienen test que son complicados de mantener o abusan de mocks.
mil gracias por la explicacion, en este caso si quisiera cambiar de base de datos el cambio se tendria que hacer creando la por ejemplo la clase MysqlRepository en el paquete outputadapter?
Profesor excelente video, me sirvio mucho para aterrizar ciertos puntos de los que no comprendia muy bien, sin embargo, el ejercicio aplica un crud, si quisiera agregar una logica mas compleja sobre alguna de las entidades de dominio, en que paquete deberia ir esta clase. Ejemplo una clase service que valide si el customer es de un pais en especifico se aplique otros impuestos en la orden. Agradeceria mucho si mas adelante nos puedas educar con un ejercicio algo mas complejo con reglas de negocios especificas. Muchas gracias!!
En la parte donde implementas los puertos de salida, para decir que la clase implementa la interfaz, en vez de usar "implements", usaste Spring con la anotación @Autowired. ¿Valen las dos formas o tiene alguna ventaja hacerlo así?
Hola Albert, muchas gracias por tan excelente video, tengo una pregunta, es buena practica mantener los servicios o la capa de aplicación libre de DTOS y mantener toda esta manipulación de DTOS y mappers en la capa de infraestructura o controllers? Muchas gracias.
Me ha parecido genial la explicación, a mi siempre me preocupa cómo estructurar los proyectos. La inyección de dependencia lo hace directo spring sin tener que configurar nada? Y el testing como se haría? Muchas gracias!
Muy buen video. A partir de ahora tienes un nuevo seguidor :) Pero quería comentar algo que no se si está bien... veo que en el caso de uso `CustomerUseCase` que se encuentra en la capa de Aplicación se está haciendo uso de un componente que se encuentra en infraestructura... que es el `EntityRepository` violando el principio de que solo las capas exteriores tienen conocimiento de las capas internas... se me está pasando algo? Yo por mi parte lo que haría seria simplemente mover esa interfaz de EntityRepository a Aplicación, aunque lo que solemos hacer es tener todas las interfaces de las entidades en el Dominio.... que tampoco se si es el lugar correcto. ¿Qué opinas de todo esto que te comento?
Buenos días. gracias por la explicación con el ejemplo queda mas claro. Una de las ideas de las arquitecturas limpias es que el dominio no dependa de ninguna librería, al usar lombok en el domain ¿ no estamos acoplando el domain a una librería ? Gracias, saludos!
Lo del hexágono no es que esté mal ni sea falso. Es simplemente un símil con 6 adaptadores. Igual que ponen un hexágono, podrían poner un heptágono, un pentágono o un cuadrado. Sino estás de acuerdo con lo del hexágono entonces no la denomines hexagonal, denomínala arquitectura de puertos y adaptadores, que es su otro nombre.
Buen video!, en un momento haces referencia a no crear repositorios por cada entidad. Pero me gustaría saber, si tenes alguna consulta compleja o especifica de algunas entidades (Siempre las hay en proyectos de la vida real), donde pondrías estas consultas? En un repositorio generico como en este ejemplo PostgresRepository? No crees que sería muy poco cohesivo?. Saludos!
Buen día, veo que en el caso de uso haces inyección de dependencia con la anotación de spring @Autowired, quería preguntarte si esta bien que se esté usando esta implementación de la tecnología, teniendo en cuenta que esta capa tampoco conoce del exterior? No sería necesario crear nuestra propia anotación como un wrapper en el dominio para no romper la arquitectura? o simplemente por estar trabajando con este framework se está haciendo la excepción?
@@diegos5112 si claro, hace poco lo que hicimos fue segregar la lógica de la aplicación y solo aplicamos spring framework en la capa de apps, de modo que desde allí hago la inyección de dependencias con @Beans en un archivo de configuración y de esta manera me evito tener que colocar anotaciones como @Inject o @Autowired en los casos de uso y servicios.
Muy completo el vídeo. Me choca que la interface del repositorio se encuentre en la carpeta de infra. En las arquitecturas límpias suelo ver la definición del repositorio en la capa de dominio y su implementación en la de infraestructura.
Lo del EntityRepository para todas las clases con esos métodos en común esta muy bueno, pero en caso de que varias tengas algunos métodos específicos adicionales, conviene hacer la EntityRepository y además otros Repository? O como se debería actuar en ese caso?
Yo aplico herencia y polimorfismo: 1. Crear IBaseRepo .java 2. Crear RepoBaseImpl .java Si quiero añadir una funcionalidad solo a un modelo: 1. Crear ICustomerRepo .java implements IBaseRepo. 2. Crear CustomerRepoImpl .java extends BaseRepo. Así tu repositorio de Customers contiene todos los métodos comunes con la implementación adicional. Esto sigue los principios: 1. Abierto cerrado 2. Sustitucion liskov Pero no cumple con el principio de responsabilidad única.
Aquí tenéis disponible el código de ejemplo del vídeo de esta semana sobre Arquitectura Hexagonal con #Java #SpringBoot y #PostgreSQL . Buen fin de semana -> github.com/acoronadoc/java-springboot-hexagonal-architecture-sample
PROFE CON SPRING INITIALIZR ES MAS RAPIDO. SE NOTA QUE UD ES DE LA VIEJA ESCUELA. 🙂
Es verdad profe un poco de gente en UA-cam que no saben de programación explicando lo que no saben , usted si sabe
Simple, directo al grano y bien explicado. Muchas gracias!
La mejor explicación que he visto hasta el momento. Excelente
Albert, qué alegría volver a tenerte aquí! Muchas gracias!
La mejor explicación práctica que he visto sobre arquitectura hexagonal. Muchas gracias!
Excelente, no se nos pierda... Oportuno tema, como siempre... Saludos desde Panamá.
Muchas gracias, es muy dificil encontrar contenido de esta calidad con casos prácticos. Esto tiene mucho valor para los que estamos aprendiendo arquitectura. Saludos!!!!!
Me alegra que vuelvas a publicar contenido, contenido bien explicado, que hace que quieras aprender más sobre lo que has hablado. Gracias.
Impresionante la forma de explicar la arquitectura hexagonal. Muchisimas gracias por tu explicación.
Excelente, muy buen vídeo. Saludos cordiales desde Chile
Muchas gracias por compartir sus conocimientos para todos
Volvió¡ Que bueno¡ Estoy aprendiendo mucho con sus videos¡ Usted esta muy adelantado a los temas y muy actualizado, dele tiempo a su canal y será millones¡ Desde Córdoba, Argentina todos los éxitos y gracias por tanto¡
gracias por compartir tu conocimiento y hacerlo de una forma sencilla y clara
Como te extrañaba gran Maestro, aprendo de otros pero siempre vuelvo para aprender de ud.
Te felicito por tu trabajo. grandiosa y muy util explicación.
Se te echaba de menos. Gracias por este pedazo de vídeo. Como decías, las arquitecturas hexagonales se terminan tergiversando por la simplificación del concepto. Gracias al ejemplo lo tenemos más claro. Temas interesantes: patrones CQRS, Event Sourcing y Sagas. También estaría interesante explicar en una serie, algunos de los consejos más útiles del código limpio
Mi querido Albert tu canal me ha servido de mucho para repasar temas. Ojalá te animes en un futuro a hablar y demostrar cosas no tan conocidas o poco habladas, que se encuentran difícilmente en internet, como el tema de Kubernetes de hacer actualizaciones progresivas sin tiempo de inactividad del servicio "Rolling updates"...
Muchas Gracias, considero que este es un buen proyecto para aplicarle Vertical Slice
Me ha venido genial para entenderlo, gracias por existir!
Albert, gran retorno con este video! se agradece mucho! . De ser posible hacer otro video más con arquitectura hexagonal. Saludos!
Que maravilla!días buscando documentación de la arquitectura hexagonal y en media hora me lo has dejado clarísimo!muchas gracias máster!!
Encantado de volver a verte, yo creo que seria interesante repasar temas de monitorización (grafana, nagios, elastic...) y un poco de AWS. Muchas gracias por compartir
Acabo de encontrar tu canal y estoy viendo los vídeos anteriores. Solo puedo decir que todos tus videos son oro puro. Tienes conmigo un seguidor más , veo que dejaste de subir durante un tiempo, espero no haber llegado muy tarde y que no desistas de crear estos videos tan buenos! Muchas Gracias por compartir tu experiencia con el mundo, y apenas tenga oportunidad, más que suscribirme, me unirme a tu canal.
Me ha resultado muy útil, refactorizando un proyecto que supuestamente usan está arquitectura y la verdad es que me has aclarado bastante
Este contenido me ha servido para aclararme un poco más con un problema que estoy teniendo en el mismo caso de un proyecto de CRM para una tienda y no consigo desde mi proyecto con Springboot inserte datos utilizando Hibernate H2 tiene como registros customers, products, price...
vale la pena. Es cierto. Es usted un crack y mejor profesor.
Me alegro de tu vuelta Albert!!! hace poco revise uno de los videos antiguos por una dudas y me sirvio de mucho.
Muy buena explicación y ejemplo. Muchas Gracias !!!!
Gran programador y muy bien explicado el video......
Gracias por todo el contenido interesante que se trata en tu canal, es de gran utilidad para los que nos iniciamos en el mundo laboral
Excelente ejemplo me ayudó a acaparar muchas dudas sobre java/kotlin, muchas gracias
Felicitaciones Albert me alegro por tu nuevo video, como siempre muy bien explicado. Saludos.
Que bueno verte por aquí, grande. Saludos
Me alegra tenerte de vuelta, siempre tutos de gran calidad saludos desde Ecuador
Que alegría verte de vuelta. Como siempre, otro vídeo de gran valor. Gracias por todo tu aporte y dedicación.
Despues de un año regreso el buen Albert saludos bro. gracias
Buena explicaciónsobre ingeniería de software
Excelente explicación!, apenas estoy aprendiendo y explicas muy bien, otra cosa es que no he visto muchos ejemplos del lado del front. y otros ejemplos he visto que todas las interfaces van en el dominio porque es el que define las reglas. tal vez como tu dices no he visto un estandar en el scafold de carpetas.
un saludo desde colombia y aqui tienes un sub mas!
Me alegro de tu vuelta!!!
Gracias Fran!!!!
Muchísimas gracias por hacerte un tiempo a pesar de que ahora te cuesta más sacar espacio para esto, hacía tiempo que no veía nuevos vídeos por el canal, que bueno que lo vuelvas a retomar aún si ya no se puede al ritmo de antes. Me gusta mucho la forma en la que explicas, ayudándome mucho a entender algunos conceptos que me son nuevos, gracias desde Chile
Qué bueno !!! Gracias a ti tengo mi página con certificado ssl .. lo recuerdo muy bien … no se desaparezcas amigo 😅..
Me gusto mucho esta explicación
Se te echaba mucho de menos. Qué alegría verte de vuelta!
Buen video, justo en tema que ahora se me hace muy interesante. ❤
La verdad que me ha gustado mucho el video, es largo pero necesario, con el ejercicico práctico se aclaran muchas dudas, ya que consultas por ahí y cada uno lo hace como quiere, respetando un poco los conceptos base, ... más o menos.
Me asalta 2 dudas:
i) Al usar el objeto de dominio en el adaptador de BBDD. Dado que pensaba que los objetos de dominio solo se usaban dentro de la capa application.
ii) El uso de un repositorio genérico, que entiendo que puede ser muy corto cuando precises de búsquedas específicas, no se si sería mejor tirar por Spring Data Jpa. Además, que entiendo que si vas haciendo aplicaciones pequeñas, quizás no haya tantos repositorios.
Qué buena explicación hace falta más ingeniería de software, estamos plagados de información de las tecnologías como React, Angular, JavaScript, Vue.js, Etc. pero de esto muy poco y extremadamente importante, yo ya me he hecho cursos como clean code, me falta aprender programación funcional, patrones diseño, tengo esto por los momentos aplazados, ya que se me dio recientemente la oportunidad de estudiar en seguridad cero Ethical Hacking Professional luego seguiré mis estudios de todo lo que es arquitectura del software e ingeniería del software, si tienen alguna recomendación de que valoran más las empresas y se necesita estudiar se los agradecería, a darle átomos 🤜🤛🤓🚀
Se te echaba de menos, que gran sorpresa, buen video.
i really apreciate your help with dowloanding this software
Increible explicación!
Que genial que vuelvas a generar contenido, hexagonal es un gran tema eso si en mi opinión los puertos no fueron implementados de la manera que significan de verdad los puertos de entrada son interfaces que interactúan con el dominio y los puertos de salida son los que interactúan con componentes externos al dominio lo mismo para las capa de application ejemplo: un repositorio sería un puerto de entrada y una interface que envíe un correo o ejecute una acción externa al dominio o sea no lo modifique sería un puerto de entrada. Pero como dijo en el video no existe una receta rígida para implementar hexagonal
Me sacas de dudas, es como creía que se implementaba, pero al ver que el lo hace de esta manera me ha surgido la duda. Gracias!
Me alegra volverte a ver de vuelta!
Excelente, me alegra tu regreso.
Gran video, muchas gracias!
Que alegría que vuelvas! mil gracias
Ey me alegra verte de vuelta , gracias
Se lo extrañaba por qui maestro, excelente video
nuevo suscriptor, este es una joya, muchas gracias
Gracias Albert!
Abrazo.
Muchas gracias por regresar (y)
Hostia Albert, pensaba que te había pasado algo. Bienvenido de nuevo :)
Interesante video, ojala pueda hacer videos sobre implementacion serveless, saludos.
"Si no es fácil de testear no se está haciendo bien" me quedo mucho con esa frase.
La gran mayoría de arquitecturas hexagonales en las que trabajé o no tienen test o tienen test que son complicados de mantener o abusan de mocks.
que gusto verte de nuevo
Hey man, It works great and without any problems.
Volviste Albert que bueno !!! Abrazo !!
El retorno del rey
Gracias Sendo!
mil gracias por la explicacion, en este caso si quisiera cambiar de base de datos el cambio se tendria que hacer creando la por ejemplo la clase MysqlRepository en el paquete outputadapter?
Profesor excelente video, me sirvio mucho para aterrizar ciertos puntos de los que no comprendia muy bien, sin embargo, el ejercicio aplica un crud, si quisiera agregar una logica mas compleja sobre alguna de las entidades de dominio, en que paquete deberia ir esta clase. Ejemplo una clase service que valide si el customer es de un pais en especifico se aplique otros impuestos en la orden. Agradeceria mucho si mas adelante nos puedas educar con un ejercicio algo mas complejo con reglas de negocios especificas. Muchas gracias!!
Bienvenido!! 🚀 Buen tema!
Enhorabuena 👏!!!
muchas gracias!!
Ya se lo extrañaba maestro!
Excelente video 😉
No me gustó la implementación, pero eres muy bueno como arquitecto en la reutilización de código, aprendí algunas cosas interesantes
En la parte donde implementas los puertos de salida, para decir que la clase implementa la interfaz, en vez de usar "implements", usaste Spring con la anotación @Autowired. ¿Valen las dos formas o tiene alguna ventaja hacerlo así?
Hola Albert, muchas gracias por tan excelente video, tengo una pregunta, es buena practica mantener los servicios o la capa de aplicación libre de DTOS y mantener toda esta manipulación de DTOS y mappers en la capa de infraestructura o controllers? Muchas gracias.
Hola, si que te haces esperar, pero me diste tiempo a ver hartos videos tuyos de dockers, kubernetes y cloud
Bravo!!!!
Me ha parecido genial la explicación, a mi siempre me preocupa cómo estructurar los proyectos. La inyección de dependencia lo hace directo spring sin tener que configurar nada? Y el testing como se haría?
Muchas gracias!
Hola Albert, muchas gracias por la explicación, de pronto recomiendas alguna bibliografía para complementar?
Welcome back!!!
Muy buen video. A partir de ahora tienes un nuevo seguidor :)
Pero quería comentar algo que no se si está bien... veo que en el caso de uso `CustomerUseCase` que se encuentra en la capa de Aplicación se está haciendo uso de un componente que se encuentra en infraestructura... que es el `EntityRepository` violando el principio de que solo las capas exteriores tienen conocimiento de las capas internas... se me está pasando algo?
Yo por mi parte lo que haría seria simplemente mover esa interfaz de EntityRepository a Aplicación, aunque lo que solemos hacer es tener todas las interfaces de las entidades en el Dominio.... que tampoco se si es el lugar correcto. ¿Qué opinas de todo esto que te comento?
Es que la interfaz debe estar en la carpeta de aplicación y su implementación en la infraestructura.
Buenos días. gracias por la explicación con el ejemplo queda mas claro. Una de las ideas de las arquitecturas limpias es que el dominio no dependa de ninguna librería, al usar lombok en el domain ¿ no estamos acoplando el domain a una librería ?
Gracias, saludos!
QUE RICA DEPILADA DE CEJAS SE HIZO PROFE. 🙂
14:00 ES EN SERIO!!!!
USE spring initializr!!!!!
Bien!!
GRANDE CRACK!!!
Lo del hexágono no es que esté mal ni sea falso. Es simplemente un símil con 6 adaptadores. Igual que ponen un hexágono, podrían poner un heptágono, un pentágono o un cuadrado.
Sino estás de acuerdo con lo del hexágono entonces no la denomines hexagonal, denomínala arquitectura de puertos y adaptadores, que es su otro nombre.
Buen video!, en un momento haces referencia a no crear repositorios por cada entidad. Pero me gustaría saber, si tenes alguna consulta compleja o especifica de algunas entidades (Siempre las hay en proyectos de la vida real), donde pondrías estas consultas? En un repositorio generico como en este ejemplo PostgresRepository? No crees que sería muy poco cohesivo?. Saludos!
También me pregunto cómo haría la inyección de dependencias en ese caso.
Hola albert , alguna documentación que me recomiendas leer para aprender más sobre arquitectura exagonal? 😊
si por ejemplo tenemos un API rest el controlador sería un input adapter que utiliza la interfaz de nuestro caso de uso ¿no?
Buen día, veo que en el caso de uso haces inyección de dependencia con la anotación de spring @Autowired, quería preguntarte si esta bien que se esté usando esta implementación de la tecnología, teniendo en cuenta que esta capa tampoco conoce del exterior? No sería necesario crear nuestra propia anotación como un wrapper en el dominio para no romper la arquitectura? o simplemente por estar trabajando con este framework se está haciendo la excepción?
La aplicación y el dominio deberían ser independientes del framework
@@diegos5112 si claro, hace poco lo que hicimos fue segregar la lógica de la aplicación y solo aplicamos spring framework en la capa de apps, de modo que desde allí hago la inyección de dependencias con @Beans en un archivo de configuración y de esta manera me evito tener que colocar anotaciones como @Inject o @Autowired en los casos de uso y servicios.
El "EntityRepository" es como lo que viene siendo un "DAO" ??
💙
bravisimo
Muy completo el vídeo. Me choca que la interface del repositorio se encuentre en la carpeta de infra. En las arquitecturas límpias suelo ver la definición del repositorio en la capa de dominio y su implementación en la de infraestructura.
Que son los value object (vo)? Excelente video.. muchas gracias por compartir el repositorio..
Lo del EntityRepository para todas las clases con esos métodos en común esta muy bueno, pero en caso de que varias tengas algunos métodos específicos adicionales, conviene hacer la EntityRepository y además otros Repository? O como se debería actuar en ese caso?
Yo aplico herencia y polimorfismo:
1. Crear IBaseRepo .java
2. Crear RepoBaseImpl .java
Si quiero añadir una funcionalidad solo a un modelo:
1. Crear ICustomerRepo .java implements IBaseRepo.
2. Crear CustomerRepoImpl .java extends BaseRepo.
Así tu repositorio de Customers contiene todos los métodos comunes con la implementación adicional.
Esto sigue los principios:
1. Abierto cerrado
2. Sustitucion liskov
Pero no cumple con el principio de responsabilidad única.
Observabilidad: extender usos de Prometheus y Jaeger en diferentes proyectos (agente y cliente caso Jaeger)