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
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
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.
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
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¡
La mejor explicación práctica que he visto sobre arquitectura hexagonal. Muchas gracias!
Před rokem+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
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!!!!!
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"...
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.
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!
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.
Hace un tiempo encontre tu canal, y todo el contenido es excelente se te agradece mucho. Solo tengo una duda con respecto a como se estructura esta arquitectura, tengo entendido que las dependencias van de adentro hacia afuera DOMINIO(No depende de nada externo) APLICACION(Puede depender de dominio pero no de INFRA) INFRA(Pueden depender de dominio y aplicacion ) no se si mi pensamiento es muy purista. por ahi fue algo que se te paso en el ejemplo donde aplicacion depende de infra(porque los puertos y adaptadores los colocaste en infra). Saludos
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?
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.
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!
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 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.
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.
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?
Tengo una duda, la capa de dominio y casos de usos o de negocios no debería ser independiente de la tecnología de persistencia o interfaz con el usuario?, es decir en este caso seria código java puro, sin anotaciones que hagan referencia a Spring. Pues de esta forma si cambiamos el framework o el tipo de aplicación por ejemplo a una aplicación de escritorio o móvil, no tendríamos que cambiar nada la lógica de negocio porque no está amarrada a ninguna tecnología en particular lo único que tendríamos que hacer es cambiar los adaptadores y lo que esta después y que respondan a la tecnología de persistencias etc.
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!
Primeramente déjame felicitarte por el vídeo, soy nuevo subscriptor. Respecto a la dependencia entre capas tengo la duda de por qué la interface del input y output van en el paquete de infraestructura, no se supone que quien pone el contrato/puerto/interfaz es la capa de aplicación?. Y quien depende de dicha capa es la infraestructura. Si la dependencia lo dicta así, por qué se coloca la interfaz en otro paquete?. Es solo una forma de organizar los paquetes o realmente tienen que estar ahí?. Lo pongo como observación porque si queremos cambiar todo el paquete, no llevamos también la interfaz. Y la gracia es que podamos cambiar sin menor coste. Que no digo que no se haga porque finalmente quien implementa el adaptador al puerto está en la infraestructura.
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. 🙂
Simple, directo al grano y bien explicado. Muchas gracias!
Gran video, muchas gracias!
Que alegría verte de vuelta. Como siempre, otro vídeo de gran valor. Gracias por todo tu aporte y dedicación.
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
Se te echaba mucho de menos. Qué alegría verte de vuelta!
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.
Que bueno verte por aquí, grande. Saludos
Me alegra tenerte de vuelta, siempre tutos de gran calidad saludos desde Ecuador
Un placer volverte a tenerte por aquí! Muy buen video!
Me alegra volverte a ver de vuelta!
Que alegría que vuelvas! mil gracias
Me alegra que vuelvas a publicar contenido, contenido bien explicado, que hace que quieras aprender más sobre lo que has hablado. Gracias.
Albert, qué alegría volver a tenerte aquí! Muchas gracias!
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
Se te echaba de menos, que gran sorpresa, buen video.
Me alegro de tu vuelta Albert!!! hace poco revise uno de los videos antiguos por una dudas y me sirvio de mucho.
Me alegro de tu vuelta!!!
Gracias Fran!!!!
Albert, gran retorno con este video! se agradece mucho! . De ser posible hacer otro video más con arquitectura hexagonal. 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¡
Ey me alegra verte de vuelta , gracias
La mejor explicación práctica que he visto sobre arquitectura hexagonal. Muchas gracias!
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
Excelente, me alegra tu regreso.
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!!!!!
Felicitaciones Albert me alegro por tu nuevo video, como siempre muy bien explicado. Saludos.
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
Como te extrañaba gran Maestro, aprendo de otros pero siempre vuelvo para aprender de ud.
Es verdad profe un poco de gente en CZcams que no saben de programación explicando lo que no saben , usted si sabe
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!!
Excelente, no se nos pierda... Oportuno tema, como siempre... Saludos desde Panamá.
Buen video, justo en tema que ahora se me hace muy interesante. ❤
vale la pena. Es cierto. Es usted un crack y mejor profesor.
Muy buena explicación y ejemplo. Muchas Gracias !!!!
Me ha venido genial para entenderlo, gracias por existir!
que gusto verte de nuevo
Gran programador y muy bien explicado el video......
Se lo extrañaba por qui maestro, excelente video
La mejor explicación que he visto hasta el momento. Excelente
Impresionante la forma de explicar la arquitectura hexagonal. Muchisimas gracias por tu explicación.
Excelente, muy buen vídeo. Saludos cordiales desde Chile
Me ha resultado muy útil, refactorizando un proyecto que supuestamente usan está arquitectura y la verdad es que me has aclarado bastante
Muchas gracias por compartir sus conocimientos para todos
Excelente ejemplo me ayudó a acaparar muchas dudas sobre java/kotlin, muchas gracias
Volviste Albert que bueno !!! Abrazo !!
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"...
Te felicito por tu trabajo. grandiosa y muy util explicación.
Increible explicación!
nuevo suscriptor, este es una joya, muchas gracias
gracias por compartir tu conocimiento y hacerlo de una forma sencilla y clara
Despues de un año regreso el buen Albert saludos bro. gracias
Muchas gracias por regresar (y)
Ya se lo extrañaba maestro!
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.
Muchas Gracias, considero que este es un buen proyecto para aplicarle Vertical Slice
Gracias Albert!
Abrazo.
Me gusto mucho esta explicación
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!
Qué bueno !!! Gracias a ti tengo mi página con certificado ssl .. lo recuerdo muy bien … no se desaparezcas amigo 😅..
Hostia Albert, pensaba que te había pasado algo. Bienvenido de nuevo :)
i really apreciate your help with dowloanding this software
Hey man, It works great and without any problems.
Enhorabuena 👏!!!
Bienvenido!! 🚀 Buen tema!
El retorno del rey
Gracias Sendo!
Excelente video 😉
Interesante video, ojala pueda hacer videos sobre implementacion serveless, saludos.
muchas gracias!!
Buena explicaciónsobre ingeniería de software
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!
Welcome back!!!
Bravo!!!!
GRANDE CRACK!!!
"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.
Hace un tiempo encontre tu canal, y todo el contenido es excelente se te agradece mucho. Solo tengo una duda con respecto a como se estructura esta arquitectura, tengo entendido que las dependencias van de adentro hacia afuera DOMINIO(No depende de nada externo) APLICACION(Puede depender de dominio pero no de INFRA) INFRA(Pueden depender de dominio y aplicacion ) no se si mi pensamiento es muy purista. por ahi fue algo que se te paso en el ejemplo donde aplicacion depende de infra(porque los puertos y adaptadores los colocaste en infra). Saludos
QUE RICA DEPILADA DE CEJAS SE HIZO PROFE. 🙂
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.
Bien!!
Grande
Hola Albert, muchas gracias por la explicación, de pronto recomiendas alguna bibliografía para complementar?
No me gustó la implementación, pero eres muy bueno como arquitecto en la reutilización de código, aprendí algunas cosas interesantes
Hola, si que te haces esperar, pero me diste tiempo a ver hartos videos tuyos de dockers, kubernetes y cloud
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.
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!
💙
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!
El "EntityRepository" es como lo que viene siendo un "DAO" ??
bravisimo
14:00 ES EN SERIO!!!!
USE spring initializr!!!!!
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.
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.
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?
Que son los value object (vo)? Excelente video.. muchas gracias por compartir el repositorio..
Tengo una duda, la capa de dominio y casos de usos o de negocios no debería ser independiente de la tecnología de persistencia o interfaz con el usuario?, es decir en este caso seria código java puro, sin anotaciones que hagan referencia a Spring. Pues de esta forma si cambiamos el framework
o el tipo de aplicación por ejemplo a una aplicación de escritorio o móvil, no tendríamos que cambiar nada la lógica de negocio porque no está amarrada a ninguna tecnología en particular lo único que tendríamos que hacer es cambiar los adaptadores y lo que esta después y que respondan a la tecnología de persistencias etc.
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? 😊
Bienvenido
Observabilidad: extender usos de Prometheus y Jaeger en diferentes proyectos (agente y cliente caso Jaeger)
Primeramente déjame felicitarte por el vídeo, soy nuevo subscriptor. Respecto a la dependencia entre capas tengo la duda de por qué la interface del input y output van en el paquete de infraestructura, no se supone que quien pone el contrato/puerto/interfaz es la capa de aplicación?. Y quien depende de dicha capa es la infraestructura. Si la dependencia lo dicta así, por qué se coloca la interfaz en otro paquete?. Es solo una forma de organizar los paquetes o realmente tienen que estar ahí?. Lo pongo como observación porque si queremos cambiar todo el paquete, no llevamos también la interfaz. Y la gracia es que podamos cambiar sin menor coste. Que no digo que no se haga porque finalmente quien implementa el adaptador al puerto está en la infraestructura.