Ahora si entiendo que es la arquitectura Hexagonal, me gusto el ejemplo, vi otros cursos, pero se complicaban mucho , le metian de todo, este ejemplo es un buen ejemplo
Hola, es cierto que hay diferentes formas de implementar la arquitectura hexagonal, muchas empresas estructuran de forma diferente, en este caso podríamos mover tranquilamente el paquete y no causa impacto porque no esta ligado a esa capa en especifico sino mas bien solo a nivel de estructura. Gracias por tu comentario saludos!!
8:20 , la anotacion @Repository no tendría que ir en la interfaz "ProductCrudRepositoryMySQL" y la anotacion @Service en la clase ProductRepositoryMySQL? Me queda esa duda
Que locura de video, muchas gracias. Me queda una duda al final quien es el que hace el llamado o implementación del adaptador, en este caso la implementación del CRUD en MySQL?
Hola, cuando existe un sólo constructor no es necesario hacer la inyección mediante anotaciones ya que por defecto se inyecta vía constructor si lo hacemos de esa forma.
una Consulta. ¿para la creacion de unas 50 entidades por ejemplo. cual seria la estrutura de carpetas o es la misma? la ideas es seguir buenas practicas..
Hola, cuando tienes muchas entidades probablemente te toque usar o desarrollar algún componente que transforme de entidades de dominio a entidades de persistencia, por lo general la estructura funciona con pocas tablas. Ya con ese volumen de tablas se debería buscar la forma de de lo que menciono anteriormente, la idea es que únicamente crees entidades de dominio y que automáticamente se mapeen sus pares como entidades de bases de datos
Hola, bueno desconozco con NET como seria la mejor práctica, pero si es un tema apegado a una tecnología en especifico si debería ir en la capa de infraestructura, recuerda que la idea de la arquitectura hexagonal es desacoplar totalmente la tecnología usada y tener lo más limpio posible el dominio de la aplicación, saludos y gracias por tu comentario!!!
y en productRepositoryMySQL implementas la interfaz de ProductRepository pero no usas la de ProductCrudRepositoryMySQL, madre que lío llevo en la cabeza 😂
Hola, entender este tipo de arquitectura es un poco complejo en un inicio, si embargo con la práctica va a entender de mejor manera, a continuación te explico un poco de las funcionalidades de cada uno de ellos: - ProductRepository junto con ProductService en arquitectura hexagonal le llamamos adaptadores. - ProductRepository es la interfaz encargada de conecta lo exterior con el core de tu aplicación. - ProductoService es una Interface que se usa para desacoplar el código, pero tranquilamente se puede usar una clase en especifico (DomainProductService) con lo que en DomainProductService puedes usar directamente la referencia a ProductRepository. -En ProductRepositoryMySQL se implementa ProductRepository por el tema que mencioné antes conecta el JPA el framework de persistencia con el core. -En ProductController se usa ProductService por que es la abstracción DomainProductService, la idea de esto es no usar directamente la implementación en especifico (DomainProductService) porque sería acoplarse mucho a esa clase y eso no es recomendable en términos de buenas prácticas de programación.
Es normal que se repita el codigo por ejemplo en la capa de dominio con la clase entidad "Product" con la capa de infraestructura la clase de persistencia "ProductEntity" ??? Si se tuviera que actualizar un campo en BD como agregar un campo extra habria que hacer el cambio en ambos lados?? Siempre es asi para este tipo de arquitecturas?
Hola Bruno, pues de lo que he visto hay que hacer ese cambio en los 2 lugares, sin embargo también existen digamos como implementaciones para uso particular que hacen cada una de las empresas que usan Arquitectura Hexagonal en las cuales crean librerías propias para que por ejemplo todo lo que esté en el modelo se mapee automáticamente a clases de entidad. Pero como conocimiento general sería de la forma que indico. Saludos!!
Hola! Muy buen video! Lo que no me queda claro es porque las entities están en infraestructure y no en domain como en la imagen que se ve al principio?
Hola muchas gracias por tu comentario, en que minuto al inicio? pero bueno lo que busca la arquitectura hexagonal es separar el dominio y su reglas de negocio de todo lo externo, en este caso el tema de persistencia es un tema externo porque por ejemplo a futuro podríamos usar otro framework de persistencia o quizá otra base de datos, entonces estructurando de esta manera nuestro dominio no queda comprometido frente a otras tecnologías que cambien a futuro. Espero haber aclarado tus dudas. Saludos!!!
¿Cómo aplicas el patrón comando en Spring Boot? ¿Evitas hacer uso de la inyección de dependencias? Lo digo por si necesitas que el comando reciba un parametro para ejecutarse, y en el patrón de Comando ese parámetro va en el contructor del comando... Pero evidentemente con la inyección de dependencias no se puede ¿o sí?
Buen video, solo tendría una pregunta: En el paquete "infrastructure" en la clase Controller, devuelves el ResponseEntity con tipo "Product" el cual va ligado al paquete "domain" no estaría mal esta parte? Estás comunicando con el domain sin pasar por la capa de "application". Un saludo.
Hola gracias por ver el video y por comentar, podríamos crear DTO's para cada una de las entidades de dominio y hacer que estás sean las que transportan la información desde las vistas al servidor y viceversa, sin embargo como para el ejemplo no es restricción que los objetos de dominio sean los que transportan esta información. Saludos!!
La infraestructura puede llamar al dominio directamente sin pasar por la aplicación. El dominio solo puede llamarse a si mismo, la aplicación a si mismo y al dominio, y la infraestructura a si mismo a la aplicación y al dominio.
Porque la estructura de Springboot no la respetaste a la arquitectura Hexagonal?, en la capa de Dominio se encuentran las entidades, pero tu las creaste en Infraestructura, lo mismo con los Services, en arquitectura hexagonal indica que debe estar en dominio, pero en el ejemplo la agregaste en la capa de Aplicacion
La capa de dominio no debe saber nada de implementaciones de infraestructura. En el caso la entidad a la cual te referís esta cohesionada a otra clase adaptadora que se conecta a springboot, por eso en la capa de dominio existe un directorio de puertos que es una interfaz de como se comportan (firma) los repositorios.
@@pipevators Si bien es común que las entidades se alineen con las estructuras de datos de un ORM para facilitar la persistencia y recuperación de datos, es importante diseñarlas de manera que no estén acopladas directamente a detalles de implementación específicos. Puedes tener clases de entidades que representan conceptos del dominio y luego utilizar adaptadores o repositorios en la capa de infraestructura para manejar la persistencia utilizando el ORM.
La idea de usar puertos y adaptadores o arquitectura hexagonal es tener tu dominio lo más aislado posible del exterior y que a su vez la única forma de comunicarse con lo exterior sea mediante los puertos y adaptadores, de ahí se entiende que pone como core el dominio de tal manera que no se acople al exterior. Saludos!!
@@elivarl claro, si muy bien explicado, para usarlo con DDD, pero quizá la gente se confunda y piense que es lo mismo, Arquitectura hexagonal se puede usar en otros aspectos también. Estupendo 👌
@@elivarl UNA PREGUNTA, LA IMAGEN DEL MINUTO 0:27 ES LA ESTANDAR, PERO HE VISTO A OTROS DESARROLADORES METER LOS SERVICES, ENTITIES, Y REPOSITORIES EN LA CAPA APLICATION CUANDO DEBERÍAN ESTAR EN LA CAPA DOMAIN.¿SE PUEDE HACER ESO?
La verdad me parece que te complicas mucho, mucho de tu codigo es redundante y no explicas el porque? que suma a futuro repetir ese codigo?...otra cosa más, el DOMINIO no esta desacoplado de Infraestructura...xq? porque la estructura de las entidades las tienes en ambas capas DOMAIN(model) tambien la tienes en INFRAESTRUCTURA(entity), el dia que agregues o quites campos de la base de datos o generes, incluso cuando agregues FK o PK vas a hacer doble trabajo.
Primero que nada gracias por tu comentario, por otra parte ni el video ni el proyecto pretende ser un arquetipo de proyecto de tal manera que sigas la estructura a raja tabla simplemente es una forma de aplicar arquitectura hexagonal a un proyecto con spring. En efecto tu dominio debe estar separado de tu capa de persistencia NO los puedes mezclar porque también a futuro puedes cambiar de framework de persistencia, de motor de base de datos etc y si no lo tienes separado tu domino de tu capa de persistencia tendrás que también afectarlo, recuerda que tu dominio es el core de todos tus procesos de negocio (lógica de negocio) y por ende cada una tiene sus propios objetivos, probablemente y en la forma que lo explico si debas hacer cambios como dices, sin embargo en proyectos grandes sueles tener módulos que transforman entidades de dominio a entidades de persistencia con lo cual esto es super transparente. Saludos!!
Hola, claro lo podríamos hacer creando jar por cada proyecto y luego importarlos como dependencias pero sería muy confuso como introducción. Saludos!!!
@@ggAtr al estar separados hay mayor escalabilidad y cada proyecto es independiente el uno del otro, si lo miras desde otra perspectiva es casi como un microservicio
Ahora si entiendo que es la arquitectura Hexagonal, me gusto el ejemplo, vi otros cursos, pero se complicaban mucho , le metian de todo, este ejemplo es un buen ejemplo
Excelente!!!
Si Gracias , la explicación sencilla pero super... Asi es se explica... Gracias nuevamente.
Hola, muchas gracias!!
Muy buen video, muchas gracias por compartirlo.
Gracias por comentar!!
Buena explicación +1 subscriptor, gracias
Gracias, saludos
Excelente, buen aporte!
Muy bien explicado👌
Gracias por compartir!
El mejor ejemplo
Buena broo! gracias.
🤝
en la infra hay config de mysql , con Jpa uno se olvida de eso? Gracias por tu video
Disculpa no se que tanto sea cierto pero según documentación y otras opiniones los puertos van en la capa de aplicación no de dominio.
Hola, es cierto que hay diferentes formas de implementar la arquitectura hexagonal, muchas empresas estructuran de forma diferente, en este caso podríamos mover tranquilamente el paquete y no causa impacto porque no esta ligado a esa capa en especifico sino mas bien solo a nivel de estructura. Gracias por tu comentario saludos!!
@@elivarl gracias !
consulta y el DTO se usa en este caso por ejemplo para relacion de de 1 a muchos? veo que le pones maper pero no veo el DTO
8:20 , la anotacion @Repository no tendría que ir en la interfaz "ProductCrudRepositoryMySQL" y la anotacion @Service en la clase ProductRepositoryMySQL? Me queda esa duda
Que locura de video, muchas gracias.
Me queda una duda al final quien es el que hace el llamado o implementación del adaptador, en este caso la implementación del CRUD en MySQL?
Muchas gracias, los controladores son los que llaman a las implementaciones mediante las clases de servicio
Muy buen video, te hago una pregunta, por que a algunas interfaces las inyectas por constructor y no con el autowired?
Hola, cuando existe un sólo constructor no es necesario hacer la inyección mediante anotaciones ya que por defecto se inyecta vía constructor si lo hacemos de esa forma.
@@elivarl Gracias 👍👍
una Consulta. ¿para la creacion de unas 50 entidades por ejemplo. cual seria la estrutura de carpetas o es la misma? la ideas es seguir buenas practicas..
Hola, cuando tienes muchas entidades probablemente te toque usar o desarrollar algún componente que transforme de entidades de dominio a entidades de persistencia, por lo general la estructura funciona con pocas tablas. Ya con ese volumen de tablas se debería buscar la forma de de lo que menciono anteriormente, la idea es que únicamente crees entidades de dominio y que automáticamente se mapeen sus pares como entidades de bases de datos
y en Net core si trabajo con efCore o dataFirst todo ese tema de la migración lo haría en la capa Infraestructure... ?
Hola, bueno desconozco con NET como seria la mejor práctica, pero si es un tema apegado a una tecnología en especifico si debería ir en la capa de infraestructura, recuerda que la idea de la arquitectura hexagonal es desacoplar totalmente la tecnología usada y tener lo más limpio posible el dominio de la aplicación, saludos y gracias por tu comentario!!!
No entiendo, por qué productService y productRepository son dos interfaces con exactamente los mismos métodos. Para qué?
y en productRepositoryMySQL implementas la interfaz de ProductRepository pero no usas la de ProductCrudRepositoryMySQL, madre que lío llevo en la cabeza 😂
Hola, entender este tipo de arquitectura es un poco complejo en un inicio, si embargo con la práctica va a entender de mejor manera, a continuación te explico un poco de las funcionalidades de cada uno de ellos:
- ProductRepository junto con ProductService en arquitectura hexagonal le llamamos adaptadores.
- ProductRepository es la interfaz encargada de conecta lo exterior con el core de tu aplicación.
- ProductoService es una Interface que se usa para desacoplar el código, pero tranquilamente se puede usar una clase en especifico (DomainProductService) con lo que en DomainProductService puedes usar directamente la referencia a ProductRepository.
-En ProductRepositoryMySQL se implementa ProductRepository por el tema que mencioné antes conecta el JPA el framework de persistencia con el core.
-En ProductController se usa ProductService por que es la abstracción DomainProductService, la idea de esto es no usar directamente la implementación en especifico (DomainProductService) porque sería acoplarse mucho a esa clase y eso no es recomendable en términos de buenas prácticas de programación.
Es normal que se repita el codigo por ejemplo en la capa de dominio con la clase entidad "Product" con la capa de infraestructura la clase de persistencia "ProductEntity" ??? Si se tuviera que actualizar un campo en BD como agregar un campo extra habria que hacer el cambio en ambos lados?? Siempre es asi para este tipo de arquitecturas?
Hola Bruno, pues de lo que he visto hay que hacer ese cambio en los 2 lugares, sin embargo también existen digamos como implementaciones para uso particular que hacen cada una de las empresas que usan Arquitectura Hexagonal en las cuales crean librerías propias para que por ejemplo todo lo que esté en el modelo se mapee automáticamente a clases de entidad. Pero como conocimiento general sería de la forma que indico. Saludos!!
Hola! Muy buen video! Lo que no me queda claro es porque las entities están en infraestructure y no en domain como en la imagen que se ve al principio?
Hola muchas gracias por tu comentario, en que minuto al inicio? pero bueno lo que busca la arquitectura hexagonal es separar el dominio y su reglas de negocio de todo lo externo, en este caso el tema de persistencia es un tema externo porque por ejemplo a futuro podríamos usar otro framework de persistencia o quizá otra base de datos, entonces estructurando de esta manera nuestro dominio no queda comprometido frente a otras tecnologías que cambien a futuro. Espero haber aclarado tus dudas. Saludos!!!
¿Cómo aplicas el patrón comando en Spring Boot? ¿Evitas hacer uso de la inyección de dependencias? Lo digo por si necesitas que el comando reciba un parametro para ejecutarse, y en el patrón de Comando ese parámetro va en el contructor del comando... Pero evidentemente con la inyección de dependencias no se puede ¿o sí?
como le meto seguridad a una api rest creada con arq hexagonal?
Spring Security
Existe alguna arquitecta para hacer CRUDS?
Si es un simple crud puedes usar MVC
Buen video, solo tendría una pregunta: En el paquete "infrastructure" en la clase Controller, devuelves el ResponseEntity con tipo "Product" el cual va ligado al paquete "domain" no estaría mal esta parte? Estás comunicando con el domain sin pasar por la capa de "application". Un saludo.
Hola gracias por ver el video y por comentar, podríamos crear DTO's para cada una de las entidades de dominio y hacer que estás sean las que transportan la información desde las vistas al servidor y viceversa, sin embargo como para el ejemplo no es restricción que los objetos de dominio sean los que transportan esta información. Saludos!!
La infraestructura puede llamar al dominio directamente sin pasar por la aplicación. El dominio solo puede llamarse a si mismo, la aplicación a si mismo y al dominio, y la infraestructura a si mismo a la aplicación y al dominio.
Porque la estructura de Springboot no la respetaste a la arquitectura Hexagonal?, en la capa de Dominio se encuentran las entidades, pero tu las creaste en Infraestructura, lo mismo con los Services, en arquitectura hexagonal indica que debe estar en dominio, pero en el ejemplo la agregaste en la capa de Aplicacion
La capa de dominio no debe saber nada de implementaciones de infraestructura. En el caso la entidad a la cual te referís esta cohesionada a otra clase adaptadora que se conecta a springboot, por eso en la capa de dominio existe un directorio de puertos que es una interfaz de como se comportan (firma) los repositorios.
@@luxdev4719 entonces el diagrama del inicio está mal, ya que pone entity dentro de domain, debería ser model
@@pipevators Si bien es común que las entidades se alineen con las estructuras de datos de un ORM para facilitar la persistencia y recuperación de datos, es importante diseñarlas de manera que no estén acopladas directamente a detalles de implementación específicos. Puedes tener clases de entidades que representan conceptos del dominio y luego utilizar adaptadores o repositorios en la capa de infraestructura para manejar la persistencia utilizando el ORM.
Entiendo que la arquitectura hexagonal se basa más en puertos y adaptadores, lo que es dominio adaptadores en infraestructura es aplicar DDD :/
La idea de usar puertos y adaptadores o arquitectura hexagonal es tener tu dominio lo más aislado posible del exterior y que a su vez la única forma de comunicarse con lo exterior sea mediante los puertos y adaptadores, de ahí se entiende que pone como core el dominio de tal manera que no se acople al exterior. Saludos!!
@@elivarl claro, si muy bien explicado, para usarlo con DDD, pero quizá la gente se confunda y piense que es lo mismo, Arquitectura hexagonal se puede usar en otros aspectos también. Estupendo 👌
ENTIENDO QUE ESTA ARQUITECTRURA HEXAGONAL ES PARA PROYECTOS DE NEGOCIO REALES, SI ES PARA HACER UN CRUD, NO ES NECESARIO.
Correcto es para proyectos grandes, para un crud no es necesario, para eso puedes usar una arquitectura por capas, dominio, servicio y vista.
@@elivarl UNA PREGUNTA, LA IMAGEN DEL MINUTO 0:27 ES LA ESTANDAR, PERO HE VISTO A OTROS DESARROLADORES METER LOS SERVICES, ENTITIES, Y REPOSITORIES EN LA CAPA APLICATION CUANDO DEBERÍAN ESTAR EN LA CAPA DOMAIN.¿SE PUEDE HACER ESO?
No entendí u. U veo q los repositorios tienen los mismos metodos
No encuentro sentido a tu explicación la verdad
La verdad me parece que te complicas mucho, mucho de tu codigo es redundante y no explicas el porque? que suma a futuro repetir ese codigo?...otra cosa más, el DOMINIO no esta desacoplado de Infraestructura...xq? porque la estructura de las entidades las tienes en ambas capas DOMAIN(model) tambien la tienes en INFRAESTRUCTURA(entity), el dia que agregues o quites campos de la base de datos o generes, incluso cuando agregues FK o PK vas a hacer doble trabajo.
Primero que nada gracias por tu comentario, por otra parte ni el video ni el proyecto pretende ser un arquetipo de proyecto de tal manera que sigas la estructura a raja tabla simplemente es una forma de aplicar arquitectura hexagonal a un proyecto con spring. En efecto tu dominio debe estar separado de tu capa de persistencia NO los puedes mezclar porque también a futuro puedes cambiar de framework de persistencia, de motor de base de datos etc y si no lo tienes separado tu domino de tu capa de persistencia tendrás que también afectarlo, recuerda que tu dominio es el core de todos tus procesos de negocio (lógica de negocio) y por ende cada una tiene sus propios objetivos, probablemente y en la forma que lo explico si debas hacer cambios como dices, sin embargo en proyectos grandes sueles tener módulos que transforman entidades de dominio a entidades de persistencia con lo cual esto es super transparente. Saludos!!
1:08 Lenguague Ubicuo
me resulta raro, yo veo que se generan modulos, aca esto no lo haces.
Hola, claro lo podríamos hacer creando jar por cada proyecto y luego importarlos como dependencias pero sería muy confuso como introducción. Saludos!!!
@@elivarl pero porque se hacen eso de los modulos se desplegan por separado en los pods?
@@ggAtr al estar separados hay mayor escalabilidad y cada proyecto es independiente el uno del otro, si lo miras desde otra perspectiva es casi como un microservicio