⬣👨🏻💻 ARQUITECTURA HEXAGONAL | DE 0 A DIOS DE LA GUERRA [EXPLICACIÓN + PROYECTO CON JAVA Y SPRING]
Vložit
- čas přidán 18. 03. 2023
- ¡Bienvenidos a este emocionante tutorial sobre Arquitectura Hexagonal! En este vídeo, te llevaré de 0 a Kratos, el Dios de la Guerra, mientras exploramos la Arquitectura Hexagonal con un ejemplo de un proyecto completo explicado paso a paso realizado con Java y Spring 💪👨🏻💻⬣
La arquitectura hexagonal, también conocida como arquitectura de puertos y adaptadores, es un patrón de diseño de software que promueve la separación de preocupaciones y la independencia de componentes. Su principal objetivo es facilitar el mantenimiento y la escalabilidad del software al permitir que las partes del sistema evolucionen de manera independiente. A continuación, se presenta una descripción más detallada de la arquitectura hexagonal.
Fue propuesta por primera vez por Alistair Cockburn en 2005 como una solución a los problemas comunes de acoplamiento y cohesión en el diseño de software. El enfoque se basa en la idea de que una aplicación debe estar compuesta por distintos componentes interconectados, cada uno con responsabilidades claramente definidas.
-----------------
🤓 MIS CURSOS 100% GRATUITOS:
🔴 CURSO COMPLETO DE HTML5: • 🔴 CURSO COMPLETO DE HT...
🔵 CURSO COMPLETO DE CSS3: • 🔵 CURSO COMPLETO DE CS...
🟡 CURSO COMPLETO DE JAVASCRIPT: • 🟡 CURSO COMPLETO DE JA...
👨🏻💻 CURSO DE SQL / MYSQL: • 👨🏻💻 CURSO DE SQL / MY...
-----------------
💬 MIS REDES SOCIALES:
🕊 TWITTER: / d_espanadero
📸 INSTAGRAM: / danielespanadero
☕️ GITHUB: github.com/DanielEspanadero
🖇 LINKEDIN: / daniel-espanadero
Creado por Daniel Españadero Fernández
Suelo ser una persona que compra muhos cursos en Udemy, pero esta vez no encontre ninguno que me convenciera de arquitectura hexagonal con Spring, vengo a youtube y veo esta joya, sin duda alguna hermano, mereces todo el reconocimiento del mundo, luego con el ordenador un poco trabado, pero continuaste, amigo, me suscribo y tienes nuevo seguidor.
Es un honor recibir este tipo de comentarios. Detrás de un vídeo de estas características hay cientos de horas de investigación, preparación, grabación y edición. Todo con un PC bastante limitado en cuanto a recursos. La satisfacción de ver que ayuda a la gente hace que todo haya valido la pena. Un abrazo!
@@danielespanadero Un abrazo para ti también amigo!
Muy bien explicado, muchas gracias por tu generosidad de compartir tu conocimiento y experiencia.
¡Hola Vladimir! Muchísimas gracias por tu comentario tan positivo. Me alegra mucho saber que encuentras la explicación clara y útil. Compartir conocimientos y experiencias es una de mis mayores pasiones, y me encanta poder ayudar a personas como tú en su proceso de aprendizaje.
No olvides suscribirte al canal y activar las notificaciones para estar al tanto de nuevos videos y contenidos. Si tienes alguna pregunta, sugerencia o tema que te gustaría ver en futuros videos, no dudes en compartirla en los comentarios. ¡Tu opinión es invaluable para continuar mejorando y enriqueciendo nuestra comunidad! ¡Un fuerte abrazo y nos vemos en el próximo video! 😃🙌🚀
Explicas excelente, muchas gracias por tu contenido de calidad
Muchas gracias a tí por comentar. Un fuerte abrazo! 😁🤘🏻
Gran contenido, esta muy bueno la verdad
Muchas gracias por tu comentario Luis, un abrazo!! 🙌🏻
Buenisimo, No lo había escuchado completo, pero Gracias por este video
Muchas gracias por tu comentario, Elkin. La verdad es que es el vídeo que más me costó realizar de todo el canal y del que más orgulloso estoy. Un fuerte abrazo!
Excelente contenido, por sigue subiendo videos de Spring Boot, explicas preciso y práctico!!!
Muchas gracias! Mi idea es seguir explicando cosas de Spring Boot ya que es lo que actualmente utilizo en mi trabajo y personalmente me gusta mucho por su robustez y facilidad a la hora de trabajar con el. Pronto iré subiendo más contenido. Un saludo! 🤘🏻
Felicitaciones!! Muy completo y entendible.
Gracias por compartir conocimientos!!
Muchas gracias por tu comentario Andres! Es un honor hacer que algo tan complejo como es la arquitectura hexagonal sea fácil de comprender. Un fuerte abrazo y nos vemos en futuros vídeos! 🤘🏻
Te agradezco muchisimo este video es el primero que veo completo de tu canal y esta super bueno, me sirve bastante para practicar.
Espero que sigas haciendo mas videos de este tipo, animo y felicidades!!
Muchas gracias por tus palabras, David. Leer este tipo de comentarios son los que me motivan a seguir adelante. Suscríbete para estar al tanto de lo que voy subiendo ya que se viene muy buen material. Un fuerte abrazo!
Muchas gracias por la dedicación a la hora de compartir tus conocimientos.
Muchas gracias a tí por comentar. Un fuerte abrazo! 🙂🙌🏻🙌🏻
Gracias! Excelente contenido
¡Muchas gracias por tu amable comentario Joel! Me alegra saber que el contenido te resultó útil. Si tienes alguna pregunta o tema específico sobre arquitectura hexagonal que te gustaría que explorara en los próximos videos, no dudes en compartirlo. ¡Tu feedback es crucial para seguir mejorando! Y, si te gustó el video, compártelo con tus amigos o colegas a quienes también podría interesarles. ¡No olvides suscribirte para no perderte los próximos contenidos! 😊
Todo un crack ❤❤❤
Muchas gracias Christian! Un abrazo! 🙌🏻
Enhorabuena! He descubierto tu canal y creo que me voy a quedar para largo, muchísimo contenido de aprendizaje!
Muchas gracias por tu comentario, Vaz. Es un honor que te resulte de interés el contenido que realizo. Si en algún momento te surge alguna duda, no tengas reparo en preguntar, creo que tambien forma parte del aprendizaje. Un abrazo! 🙂
excelente explicacion y demo muy bueno
Gracias a tí por comentar Kevin, intentaré seguir manteniendo el nivel de calidad en el futuro, un fuerte abrazo! 🙂🙌🏻
Buen video! Explicas muy bien.
Muchas gracias por tus palabras. Un abrazo!
Una persona que se ve que le pones muchisima dedicacion a tus videos y se agradece un monton que compartes tu conocimiento
Muchas gracias por tu comentario. Leer tus palabras motiva a seguir creando este tipo de contenido. Un fuerte abrazo! 🙂🙌🏻🙌🏻
Da gusto oírte macho, enhorabuena !
Muchas gracias por tus palabras, Emilio. Es un honor leer comentarios así de vez en cuando. Un abrazo! 😁🙌🏻🙌🏻
Exageradamente bien explicado con casos practicos y aclaración para dejar correctamente definido los conceptos. Todo un capo. Muchas gracias.
Gracias a tí por ese comentario, es la gasolina que me motiva a seguir creando este tipo de contenido. 😇🤘🏻
excelenete explicaciony buena practica
Muchísimas gracias por tu comentario Jose Alberto. Me alegra enormemente que la explicación te haya parecido excelente y que consideres útil la práctica mostrada en el vídeo. Mi objetivo es siempre proporcionar contenido de valor que ayude a entender y aplicar estos conceptos de la mejor manera posible, si tienes alguna duda o inquietud, o si hay algún otro tema que te gustaría que cubriera en futuros vídeos, no dudes en comentarlo. Un fuerte abrazo! 🙌🏻
Muchas gracias amigo, tu video es el mejor que he visto, muy bien explicado, sigue así amigo llegaras muy lejos.
Un abrazo desde chile!!!
Muchas gracias por tu comentario y por el apoyo. Un fuerte abrazo desde Barcelona, España. 😇🤘🏻
Excelente canal y video
Muchas gracias, Alex. Es un honor leer comentarios como este. Un fuerte abrazo!
Muchas gracias
Gracias a tí por comentar. Un abrazo!
noo que buen contenido gracias por la info! nuevo suscritor.
Muchas gracias por tu comentario, me motiva mucho a seguir creando este tipo de contenido! 🤘🏻
Buenisima explicacion!!!
Muchas gracias, un fuerte abrazo! 🙂🤘🏻
excelente contenido
¡Muchas gracias deverse! Realmente significa mucho para mí recibir comentarios como el tuyo. Crear este contenido es un placer inmenso, ya que no solo tengo la oportunidad de compartir conocimientos con personas como tú, sino que también aprendo mucho en el proceso de preparación de los videos. La arquitectura hexagonal es un tema apasionante y me entusiasma seguir explorando sus posibilidades. Si tienes alguna pregunta, sugerencia o tema relacionado que te gustaría ver en futuros videos, no dudes en hacérmelo saber. ¡Juntos podemos seguir aprendiendo y compartiendo! Un abrazo! 🙌🏻🤘🏻
Excelente tutorial, es de los pocos tutoriales que al terminar no tengo problemas con versiones o errores.
Esas explicaciones como la Inmutabilidad estan perfectas para comprender mejor los conceptos.
Me gustaría ver un nuevo proyecto más avanzado para aprender mejor otros conceptos, metodologías, Arquitecturas, Crear un Api propia o incluso conectar con el frontend.
Muy buenas, muchas gracias por tu comentario. Este tipo de feedback ayuda a crear cada vez mejor tipo de contenido. La idea es ir subiendo el nivel y no quedarme en los conceptos básicos que enseña todo el mundo en CZcams. Poco a poco irá llegando ese tipo de material. Un abrazo! 🙌🏻
excelente explicacion compa , se agradece
Ya eres VIP del canal jejeje. Un fuerte abrazo y espero seguir viendote por aquí. 🙌🏻
@@danielespanadero Claro , andaré por aquí más seguido , hay mucho material que se me hace interesante :D
Todo muy bien, me gustó la implementación, me gustaría ver la misma arquitectura implementada ahora en otros entornos, como node o incluso python, gracias por el video 👍
Muchas gracias por tu comentario Antonio!! Pues sí que estaría bien verlo en otras tecnologías jeje. Un fuerte abrazo! 🙌🏻
Saludos desde Colombia, muchas gracias por su labor; es de alto valor social y si llegares a necesitar un médico en el área de medicina interna y cuidado intensivo, le serviré con el mayor gusto y gratuitamente, así como has servido gratuitamente...
Un abrazo fuerte
Muchas gracias por su comentario Alex, es un honor leer esas palabras viniendo de una persona con esas habilidades, aunque espero gozar de tanta salud que no necesite nunca sus servicios jeje.
Un fuerte abrazo! 🙂
te ganaste otro subscriptor buen hombre
Muchas gracias por el apoyo, Sergio. Un abrazo! 😎🤘🏻
Me toco leer mucho sobre arquitectura hexagonal y terminaba muy abrumado con la información; la introducción de este video me ayudo mucho a entender toda la información que había leido. Muchas gracias por hacerlo tan simple.
Muchas gracias por tu comentario, Oscar. Es un honor apreciar que todo el trabajo que me llevó hacer este vídeo da sus frutos y es de utilidad para casos como el tuyo. Un fuerte abrazo! 🙂❤️
Grandioso, te felicito por tu forma de enseñar me ha gustado mucho.
Le implemente dos tipos de bases de datos mientras seguia tu tutotial, deje dockerizado el MySQL y le deje opcional tambien base de datos en H2, cuestión de que un usuario X quiera solo probar y no quiera manejar persistencia, no deba instalar MySQL en su maquina o dockerizar.
Interesante tu canal ya estoy suscrito, sigo aprendiendo de programación y tecnologias, saludos desde colombia.
Muchas gracias por tu comentario. Es un honor haber leido tus palabras y me motivan a seguir creando este tipo de contenido. Me parece muy interesante tu implementación y mucho más eficiente. Saludos desde Barcelona, España.
Buena Kratos jejej 😅 esta entendible la explicacion
Muchas gracias por tu comentario. La verdad es que, leer este tipo de cosas, sube el nivel de motivación para seguir haciendo este contenido. Un fuerte abrazo!
Has el de DDD. Este video estuvo muy bueno gracias por tan buen contenido. jamas habia entendido esto, hasta que ud lo explico mas detallado y sin complique
Muy buenas, lo tengo en la lista de videos por hacer, en cuanto saque un rato me pongo a grabarlo. Un abrazo y muchas gracias por tu comentario! 🙌🏻
@@danielespanadero Apoyo la mocion jajajaja,a mi tambien me encantaria uno de DDD, CQRS y EDD, se que lleva su tiempo, pero estaria buenisimo
Saldrán, es más subo la apuesta y tambien quiero hacer un vídeo bastante completo sobre microservicios, actualmente trabajo en un proyecto para Volkswagen donde usamos microservicios y creo que son muy utiles conocerlos ya que te abren puertas en todo el mundo. Como bien dices lleva tiempo, pero los haré sin falta! Un abrazo 😁
Buenas DIF, primeramente, agradecerte por tu tiempo y por la ayuda proporcionada, muchas gracias!
Me gustaría comentarte que podrías ahorrarte muchísimo tiempo con tema getter/setters y otros métodos utilizando la dependencia lombok.
Por otra, y ya sería mucho pedir pero, dado que eres una persona con experiencia, crees poder hacer una parte 2, aplicando una mejora de anotaciones para la optimización y rendimiento del aplicativo? (Gestionar las consultas con @transaccional, tema @autowired, etc) Sería un detalle por tu parte y ayudarías mucho a reflejar un desarrollo más actual.
Sea como fuere, mil gracias nuevamente!
¡Muy buenas Miguel! Antes que nada, quiero agradecerte por tus amables palabras y por tomarte el tiempo de compartir tus pensamientos y sugerencias. He respondido un comentario similar de jcodigoc, te recomiendo pasarte por su pregunta y mi respueta ya que amplio algunas cosas interesantes que tuve en cuenta a la hora de realizar este vídeo.
En cuanto al uso de *Lombok* , estoy completamente de acuerdo contigo en que puede ser muy útil para simplificar nuestro código, especialmente eliminando la necesidad de escribir manualmente los métodos getter y setter. Sin embargo, he experimentado algunos problemas de compatibilidad con Lombok en el entorno de Java 8, y estos problemas podrían generar confusiones durante un tutorial de estas características.
Respecto a tu sugerencia de una segunda parte centrada en la optimización y rendimiento, incluyendo anotaciones como *@Transactional* y *@Autowired* , me parece una excelente idea. Quiero enfatizar un punto importante que mencioné en el vídeo. En el contexto de la arquitectura hexagonal, es fundamental que las capas de dominio y aplicación no tengan dependencias directas con el framework. Esto es para asegurar la portabilidad y el desacoplamiento del código. Dicho esto, ciertamente hay formas de utilizar estas anotaciones de manera efectiva y apropiada en la capa de infraestructura, y creo que sería interesante explorar esto en un vídeo futuro.
Te agradezco mucho tus sugerencias y las tendré muy en cuenta para los próximos vídeos. De nuevo, muchas gracias por tus comentarios y tu apoyo. Un abrazo!
Excelente video, de verdad! Pero más me intriga cómo cambiaste los íconos del IDEA!! Lo necesitamos... lo necesito!!
Muchas gracias por tu comentario Hector! Para los iconos del IDEA utilizo un plugin llamado Atom Material Icons. Un abrazo! 🤘🏻
Gracias por tu excelente video, por favor publica un curso, merece ser pagado
Muchas gracias por tu comentario, Joe. Pues posiblemente el día de mañana haga alguna cosa de pago, pero por ahora quiero crear en mejor contenido posible en CZcams, 100% gratuito. Un fuerte abrazo y espero seguir viendote por aquí.
¡Hola! Quería expresarte mi profundo agradecimiento por tu excelente vídeo de explicación teórica y práctica de arquitectura hexagonal. Es uno de los mejores que he visto, y sinceramente, no entiendo por qué no tienes más seguidores. Tu contenido vale millones y estoy seguro de que has ayudado a muchas personas a comprender este tema de manera clara y efectiva. ¡Sigue haciendo un gran trabajo!
Muchas gracias por tu comentario, Luis. La verdad es que es algo que he hablado con otros CZcamsrs más grandes y el motivo es que el contenido avanzado, como es este caso, no tiene tanta repercusión en CZcams ya que no es tan demandado ni tan compartido como el que se dedica a hacer CRUDs o a explicar los métodos de X lenguaje. Espero que poco a poco eso vaya cambiando.
Lo dicho, muchas gracias por tu comentario, me da energía para seguir adelante con este tipo de temas. Un fuerte abrazo!
Me adhiero al comentario, contenido de mucho valor, muchas gracias por tomarse el tiempo y el trabajo de prepararlo y explicarlo
Muy buenas Mauricio. Gracias por el reconicimiento, espero seguir viendoos a ambos en los comentarios de futuros vídeos, da gusto ver que se está formando una comunidad tan sana. Un fuerte abrazo!
Hola!! He visto tu video y me encantó, tienes una nueva subscriptora. Por favor sería posible que hicieras este mismo video pero con Typescript con NodeJs?
Muchas gracias por tu comentario, May. Pues tomo nota, en cuanto saque tiempo para grabarlo me pongo a ello. Un abrazo!
¡Buenas! Acabo de descubrir este vídeo tratando de empezar con Java y Spring para un proyecto voluntario en el cual colaboro en la parte de back end y antes de los 10 minutos he tenido que pausar para comentar que me ha enganchado ya cómo está explicado!! :D Buena explicación de conceptos que son un tanto difíciles de interiorizar cuando estás empezando a programar, ¡un saludo!
No te haces a la idea de la alegría que me da leer tus palabras. Me alegro mucho de que te haya servido y espero que puedas aplicar satisfactoriamente estos conceptos en tu proyecto. Un fuerte abrazo!
@@danielespanadero ¡Gracias a ti por el contenido y enhorabuena por el resultado de tu trabajo compartido con la comunidad! ¡Mucho éxito! :)
Muy buen vídeo. En cuanto al IntelliJ, una de las principales ventajas es que te importe y te sugiera los métodos y las clases que justo quieres y en tu caso no hace absolutamente nada, es como si estuvieras programando en Eclipse. Deberías mirarlo. Una vez más, excelente vídeo.
Muchas gracias por tu comentario. Tienes razón de hecho el motivo por el que me pasé a intellij es por lo facil que lo pone a la hora de ser utilizado. En mi caso yo diría que no funciona cuando grabo la pantalla porque las prestaciones de mi ordenador son bastante limitadas y el hecho de estar grabando, codeando y con otros programas abiertos, consume bastantes recursos. Espero en breves poder mejorar mi equipo. Hasta entonces intentaré hacerlo lo mejor posible con lo que tengo. Un fuerte abrazo! 🙌🏻
CONCUERDO, TIO DIF HAY QUE USAR MAS EL INTELLISENSE, EN VEZ DE TIPEAR LETRA POR LETRA, ESO LO PUEDO ENTENDER DE UN OLD SCHOOL PERO UD ES JOVEN. JEJE.
TIO DIF, SUBA MAS TUTORIALES DE SPRING BOOT, SOBRE TODO SOBRE LOS DTOs, Y SUS VARIAS FORMAS DE MAPEAR CON O SIN LIBRERÍAS.
PD: SU PC ESTABA LENTO PORQUE SEGURO HABÍAN MUCHOS PROGRAMAS ABIERTOS Y 4GB DE MEMORIA ES POCO.🙂
Este año va a ser un gran año en cuanto a tutoriales de Spring Boot en este canal. Tengo pendiente cambiar de PC en cuanto ahorre un poco, pero quiero comprarme uno que sepa 100% seguro que no me va a dejar tirado para todas las funciones que realizo con el PC, por eso seguramente lo aplace para el año que viene. Un fuerte abrazo!
Buenas en el min 1:22:00, dudas cuando extiendes de JpaRepositorysi donde he puesto el interrogante puede ir otra Tipo, la respuesta es si, pero ese Tipo hace referencia al ID de esa entity. Pongamos que PersonaEntity tiene como ID: String DNI; en este caso pondriamos JpaRepository
Gracias y muy buen video.
Muchas gracias por este invalueable aporte, relamente uno de los más completos que he visto. Solo tengo una duda, cuando trabajamos con micro servicios, en donde y como deberíamos trabajar con los objetos que posee los otros miscroservicios, por ejemplo, si tengo un micro servicio con otros objetos y necesito trabajar con un objeto DTO que invlucra información de este micro y el otro, en donde y como trabajo con ese DTO? se tiene que trabajar en aplicación o en infraestructura? me surge esta duda ya que para que un micro cumpla su cometido depende de otro, estos objetos que involucran información de varios, me queda la duda como deberíamos trabajarlos, te agradecería si me ayudas con esa duda.
Lo otro sería como lo haría en un FrontEnd, por ejemplo de Angular como se implementaría, no se si me puedes ayudar con una descripción general para tomar en cuenta este ejemplo y poder implementarlo en el Front.
Gracias nuevamente.
Muy buenas, en cuanto a la parte del frontend, con Angular concretamente, no le veo mucho sentido el uso de arquitectura hexagonal ya que Angular aporta su propia manera de organizar el contenido. Aun así, podría ser interesante probarlo.
En cuanto a lo que comentas sobre trabajar con microservicios utilizando arquitectura hexagonal, piensa que cada uno de los microservicios sería independiente del resto, comunicandose a través de los adaptadores en la capa de infraestructura. Así que tendrías que crear el DTO correspondiente en la capa de aplicación de cada microservicio.
No se si he respondido correctamente a tu pregunta, estoy desde el móvil en el metro y se me complica ver tu pregunta completa y responder a la vez. Si te queda cualquier duda, no tengas reparo en decirmelo. Un abrazo! 🙂🤘🏻
DIF me gusta muchísimo tu canal y tu contenido me parece que es de buena ayuda pero como recomendación deberías hacer más didácticas tus explicaciones como colocando captures de código para cada concepto o imágenes de explicación para que no sea tan tediosa la información de golpe, de resto muy buen video
Muy buenas Sergio, muchas gracias por tu comentario y por el feedback. Me ayuda mucho a mejorar y lo tendré muy en cuenta de cara al futuro. Es verdad que al principio es mucha información de golpe y puede ser abrumador. Aun así espero que te haya podido ayudar. Muchas gracias de nuevo y un fuerte abrazo! 🙂🤘🏻
DIF muchas gracias por tus aportes en conocimientos, no sé si te lo habian dicho ya pero cuando estás creando, la estructura de carpetas , no es necesario hacer refactor , ejemplo: creas un package domain , luego click derecho en domain->new->package com.hexagonal.tasks.domain.models , ahi se crea bien, luego si vas a crear otro package dentro de domain, en este caso ports, haces lo mismo te paras en domain->new->package y te aparece la ruta com.hexagonal.tasks.domain.models , en este punto debes borrar models y escribir ports com.hexagonal.tasks.domain.ports . Asi automaticamente se te organiza en la carpeta, espero me haya hecho entender, saludos
🤣🤣 al minuto 25 me di cuenta que ya lo habias solucionado jaja🙏
Muy buenas Sebas, muchas gracias por tu comentario. Ultimamente me pasa cada día que descubro pequeñas cosas como esta sobre intellij que facilitan bastante la vida. En este caso, lo descubrí mientras realizaba el vídeo jeje. La verdad es que era bastante tostón tener que estar haciendo refactor todo el rato y va muy bien hacerlo de esta forma. Es un honor recibir comentarios como el tuyo ya que aportan bastante y ayudan a que todos aprendamos de todos, no dudes en hacerlo si en otra ocasión si ves que algo se puede optimizar. Un fuerte abrazo desde Barcelona! 🙂🤘🏻
La hostia, mas sencillo imposible. Los de codelytv mezclan mucho ddd cqrs con la portsadapters pero aqui se entiende bien.
Esta guapo que menciones que no existe un orden concreto para los ports, ya que puedes meterlos hasta en la infra
¡Muy buenas Leñiedor! Me alegra enormemente saber que has encontrado útil el tutorial y que has logrado entender bien la arquitectura hexagonal. Intento explicar estos conceptos de una manera que sea fácil de digerir, por lo que tu feedback es muy valioso.
Tienes toda la razón, la belleza de los "ports" en esta arquitectura es su flexibilidad y cómo se pueden adaptar a las necesidades de tu aplicación, incluso pudiendo estar en la capa de infraestructura si eso tiene sentido para tu proyecto. Lo remarcaré en futuras ocasiones! Un fuerte abrazo! 🙌🏻
Acabo de devolver un curso de Udemy tras ver tu vídeo. Explicas muchísimo mejor y encima no se hace monótono. Deberías pensar en hacer algún tipo de curso de pago! Un saludo :)
Muchas gracias por tu comentario, Joan. Fijate si es un honor leer tus palabras que hasta lo he compartido en LinkedIn:
www.linkedin.com/posts/daniel-espanadero_motivaci%C3%B3n-en-estado-puro-muchas-gracias-activity-7131301563318300672-t01v?
Lo dicho, muchas gracias por tus palabras y es posible que en el futuro haga cosas en Udemy, aunque por ahora solo subiré a CZcams 100% gratuito y con la máxima calidad que pueda. Bienvenido y espero seguir viendote por aquí. Un fuerte abrazo!
Te recomiendo lombok para la gestion de constructores , getters , setters y demas
Muchas gracias, tomo nota. Un abrazo! 😇
hola gracias la info...si pudieses subir a tu github sería genial
Muchas gracias por tu comentario, aquí te paso el repositorio de GitHub (No olvides dejar una estrella para dejarlo bien posicionado y que más gente pueda llegar a verlo):
github.com/DanielEspanadero/arquitectura-hexagonal-java
Si has seguido el vídeo no te va a costar nada implementarlo en cualquier proyecto. Un fuerte abrazo!
Gran vídeo, Dani. Te acabo de descubrir. Me subo al barco.
Muchas gracias por tu comentario Marcos! Leer estas cosas me anima y motiva a seguir creando este tipo de material. Un fuerte abrazo! 🤘🏻
@@danielespanadero Me alegro! Tengo que ojear (y digo ojear porque creo que en ese área llevo buen conocimiento), el último vídeo de Git. Sobre este, puede haber debates respecto a algunas cosas de la implementación. 😅😅😅😅😅😅
@@ciltocruz Pues si que hay debate 😅😅 Incluso dependiendo de donde saques la info, puede variar la forma en la que se realiza la implementación. La clave está en conocer los conceptos básicos y adaptarlos a tus necesitadas. Tengo pendiente poner en la descripción del vídeo o en un comentario fijado diferentes artículos que he ido viendo sobre arquitectura hexagonal y que se pueda apreciar los diferentes ejemplos que se suele poner.
@@danielespanadero Pues sí. Eso estaría interesante, ver diferentes puntos de vista y sobre todo el por qué. Yo, por ejemplo, de tanto que he visto y leído ya no sé si es mejor hacer un CRUD separado (como haces tú) o en un mismo servicio (como he visto en mil sitios diciendo, "pero hombre, cómo vas a separar un CRUD, si son operaciones sobre una entidad, que está relacionado con la responsabilidad"). Yo a las 2 cosas les veo sus peligros, uno atenta contra la limpieza y el otro parece esa persona que pasa la fregona cada 10 minutos porque ha entrado una mota de polvo 😅😅😅, pero fíjate que veo más peligro a separarlo todo. SOLID vs ¿sentido común? La gestión de dependencias se hace complicada y en spring, al menos, es transparente poniendo la notaciones, pero en otros lenguajes como PHP, instanciar 10 clases para poder ejecutar un endpoint de un API que requiere de varios puntos o servicios con repositorios y demás, es complejo de mantener. Y lo mismo a mi se me escapa algo y alguien me tiene que dar dos guantazos para verlo claro.
También veo que hay mucha confusión entre la hexagonal y el DDD que, creo, que éste último segrega más (organiza distinto y segrega más el código). Quizá mi cerebro tiene una ensalada de todo esto. jajaja
¡Un saludo, Dani!
@@ciltocruz Al final, todo tiene sus pros y sus contras. La ventaja que yo le veo a separar las cosas es que creas capas de abstracción que te facilitan la reutilización de código a lo largo de un proyecto de una forma optimizada. Y la ventaja que le veo a no separar las cosas es que es más fácil de leer el funcionamiento de una interfaz sin necesidad de estar dando vueltas por el proyecto y tirando del hilo para ver que hace. En mi caso, en el trabajo suelo dejarlo todo junto y separo las interfaces por tareas, aunque si hay algo que sé que se va a reutilizar, procuro ponerlo por separado para usarlo en diferentes partes de la app. De hecho tenemos un microservicio dedicado solo a almacenar las interfaces que se reutilizan por todo el proyecto.
Como bien dices, hay que usar el sentido común y no estar leyendo en manual de turno para aplicar algo al pie de la letra. Por otro lado, es interesante conocer todos estos conceptos de clean code y clean architecture aunque no los apliques al pie de la letra en tu día a día. 🙂
Gracias por la explicación con el ejemplo queda mas claro. Cuando creas tu dominio y generas los accesos(get/set) a las propiedades del objeto, veo que muchos proyectos en java usan lombok de tal forma se evitan de la verbosidad de los get/set y constructores, pero mi duda es si ahí el domain esta acoplado a una librería como lombok ¿ que opinas de usar lombok en el domain ?
Saludos!
Muy buenas Gabriela, pues no habría ningún problema en usar lombok en cualquiera de las capas puesto que es solo una herramienta de generación de código en tiempo de compilación y no introduce ninguna dependencia en tiempo de ejecución. En otras palabras, lombok no introduce ninguna dependencia adicional que afecte la funcionalidad del dominio en tiempo de ejecución. Me parece una gran herramienta que ayuda a evitar la verbosidad de los getter y setter, en mi caso no lo utilizo por que alguna vez me ha dado problemas con la versión 8 de Java, pero varias personas me lo han recomendado en los comentarios, así que miraré bien por que tengo esos problemas de compatibilidad e intentaré solucionarlos. Un fuerte abrazo y espero verte por otros vídeos del canal! 🙂🤘🏻
Hola DIF, Que buen video, me ha gustado mucho la implementación que haz realizado. Gracias por el contenido. Quisiera dejarte una pregunta de algo que no me ha quedado del todo claro: Por que razón los in (Use case) y out (port) existen o son creados en la capa de dominio ? Y En que casos se crea una lógica de dominio. Agradecería mucho tu explicación con respecto a esto. Feliz Dia.
Analizando el código, me surge otra duda. Por que en la capa de aplicación Implementas e Inyectas las mismas interfaces. No basta solo con Inyectarlas y desde el controlador llamar al servicio. A lo anterior he llegado a una conclusión pero no se si es la correcta : Se implementa y se inyecta para así obligar a mi aplicación depender de la lógica ( casos de usos ) que tiene mi dominio. se cumple la regla de que una capa inferior no puede ni debe depender de una capa superior pero si que podemos hacer que una capa superior dependa de una inferior como lo es Infraestructura -> depende de -> Aplicación -> depende de -> dominio. Espero haber sido claro. @Dif puedes por favor decirme si estoy en lo correcto ?
Muy buenas metocodigo, muchas gracias por tu comentario y tus preguntas, realmente muestran tu interés en entender la arquitectura hexagonal en profundidad.
Con respecto a tu primera pregunta, quiero decirte que los casos de uso y los puertos también te los puedes encontrar en la capa de aplicación sin ningùn problema, de hecho varios comentarios en este vídeo van en ese sentido, quiero recopilar varios artículos al respecto donde lo implementen en una capa y en otra y los motivos que dan. A la hora de realizar el vídeo estuve dudando en si ponerlos en la capa de dominio o en la de aplicación (En ambos casos se cumpliría la regla de dependencia). El motivo por el que yo personalmente me decanté por la capa de dominio es que los in (Use case) y out (ports) son los responsables de ejecutar la lógica de negocio.
Los puertos definen los contratos o interfaces que permiten la interacción entre la capa de dominio y las otras capas, facilitando así la separación de responsabilidades y permitiendo que la lógica de dominio se mantenga independiente de los detalles de implementación de las otras capas.
Los casos de uso (in) son las acciones que el sistema puede realizar y generalmente corresponden a requerimientos de negocio. Los puertos de salida (out) permiten a la lógica de dominio interactuar con el exterior, por ejemplo, para la persistencia de datos o para interactuar con servicios externos.
En cuanto a tu pregunta de en qué casos se crea la lógica de dominio, esta se crea cuando hay reglas de negocio que deben ser aplicadas ya que la capa de dominio es el núcleo de tu aplicación y contiene la lógica empresarial crítica. El motivo es que los detalles sobre cómo se aplica esta lógica no deben depender de los detalles de la infraestructura, UI, o de cualquier marco externo, por eso se implementan en la capa de dominio.
Por último, en cuanto a tu pregunta sobre por qué en la capa de aplicación inyectas las mismas interfaces, quiero decirte que estás en lo correcto con tu conclusión, la implementación e inyección de interfaces asegura que la lógica de dominio (los casos de uso) sean la principal dependencia en tu aplicación, una puntualización que quiero hacer es que la capa de infraestructura si que podría depender de la capa de dominio sin problema y sin romper la regla de dependencia, aunque estoy más de acuerdo con el planteamiento que has realizado. En referencia a eso, una cosa mejorable en el ejemplo que puse es que por no alargar mucho el vídeo, creé implementaciones en la capa de infraestructura donde se accedo a la capa de dominio directamente, aunque no es incorrecto y se cumple con la regla de dependencia, personalmente pienso que es mejor práctica lo que comentas de Infraestructura -> depende de -> Aplicación -> depende de -> dominio.
Espero que esto aclare tus dudas. No dudes en preguntar si tienes más cuestiones, a mi me viene bien ya que gracias a esto, en un futuro haré una segunda parte donde aclare y mejore este vídeo, gracias a comentarios como el tuyo, todos aprendemos. Un fuerte abrazo! 🙂
Holi cuando creas un paquete dentro de otro si quieres crearlo al mismo nivel simplemente en el nombre et sale la ruta completa de carpetas, eliminas la ultima y la creas en el nivel inferior.
Muchas gracias por el aporte. Un fuerte abrazo. 🙂🤘🏻
🌟🌟🌟🌟🌟
🫡
clave
Mil gracias!
Es uno de los vídeos mas claros que encontré sobre la arquitectura hexagonal, pero me surge una duda, ¿en que capa y como debo manejar los DTOs? por que veo que en el vídeo que se están devolviendo modelos.
Muchas gracias por tu comentario, Richard. En principio se pueden añadir DTOs en la capa de aplicación para no conectar la capa de dominio con la de infraestructura directamente. Sería una forma de mejorar el ejemplo que puse, aunque de ambas formas está correcto. Un saludo.
Hola una consulta, he estado desarrollando un proyecto utilizando tu video como referencia para la arquitectura (muy bueno por cierto), pero tengo un conflicto con el que se me dificulta pensar la solución adecuada. ¿Qué pasa si uno de mis models tiene dependencias? Cuando estoy creando el entity no es lo mismo obtener un atributo de tipo Objeto de mi clase model , para asignarla al atributo del tipo ObjetoEntity de la clase Entity que estoy creando. Hablo del "fromDomainModel()". ¿Qué se hace en estos casos? Espero puedas responderme. 😃
Para cuando subes el de domain driver desing?
Será un vídeo bastante largo, me esperaré a tener un pc nuevo para poder grabarlo de manera cómoda con 32bg de ram y no con 8 como estoy ahora. Espero que como muy tarde a mediados de 2024. Igualmente tengo bastentes vídeos que preparar antes de ese. Actualmente estoy haciendo uno para desplegar aplicaciones de Java con Spring Boot + MySQL. Espero verte en el. Un abrazo!
Hola! me encanto tu contenido pero me quedan dudas, si quiero trabajar con un proyecto modular, como haces con las entidades con relación bidireccional? o todos los modelos que se comunican con la bd estarían en un solo módulo?
Muy buenas Jesus, en principio todas las entidades tienen que estar en la capa de infraestructura, así que pueden comunicarse entre sí sin ningún problema. No se si te refieres a eso con tu pregunta o es otra cuestión. Un saludo.
Buenas! Es correcto que los ports estén en la capa de Domain? He visto varios artículos donde la ponen en Application, a mi personalmente me gusta mas en Domain pues le veo mas sentido a que el propio dominio defina las interfaces a implementar por la capa de aplicación, cual es tu opinión o porque es mejor esta organización? Muchas gracias y grandísimo video, un saludo!
Yo lo he visto implementado en ambas capas. Al igual que tú, me decanté por la capa de Domain, pero podrían ir perfectamente en la de Application. En ninguno de los casos rompe la regla de dependencia.
Muchas gracias por tu comentario. Un fuerte abrazo! 😇🤘🏻
Hola, que bien cuanto haz avanzado. Seria interesante saber de ti y por tu experiencia como es que nuevas tecnologías de AI como Chat-GPT o CopilotX, pueden ser implementadas en tu trabajo. Pues para mi es interesante pues recién comienzo en esto de la programación. Y pues tu ejemplo de un año es perfecto de alguien que pues apenas lleva un año en esto y salen estas nuevas tecnologías que pueden dar un giro a la forma de hacer las cosas en programación, etc.. sus pro o cons.
Suponiendo que no hubieras ido a los bootcamps, crees que tu solo siendo autodidacta hubieramos avanzado igual, mayor o menor?
Gracias
A que te dedicabas antes?
¡Hola H. S! Me alegra mucho que me hayas hecho estas preguntas. Primero, quiero decirte que la llegada de la inteligencia artificial, como Chat-GPT y CopilotX, ha sido realmente emocionante y transformadora para mí. Aunque trato de no depender demasiado de ellas, aprovecho al máximo su potencial para seguir aprendiendo y creciendo cada día. Es cierto que su uso en el trabajo puede ser delicado debido a la información sensible con la que trabajamos, pero en ocasiones puntuales, recurrir a estas herramientas es de gran ayuda, incluso más que buscar en Stack Overflow.
Respecto al bootcamp, aunque quizás no me proporcionó un conocimiento profundo en sí, me brindó algo muy valioso: la oportunidad de establecer contactos y conocer a personas maravillosas en este campo. En ese sentido, me siento agradecido por haber participado en lo que yo llamaría un "bootcamp" entre comillas, ya que en realidad fue un curso para autodidactas.
Sin esa experiencia, creo que aún podría haber aprendido a un ritmo similar, pero no habría tenido la oportunidad de formar parte de esta increíble comunidad y asistir a eventos emocionantes. Así que, aunque el conocimiento es fundamental, no hay que subestimar el valor de las relaciones humanas en nuestro camino de crecimiento y aprendizaje.
Espero que mi experiencia te inspire en tu propia aventura en el mundo de la programación. ¡Mucho ánimo y éxitos en tu viaje! 🙂🙌🏻
Antes de ser programador he hecho de todo, hostelería, electricista, mozo de almacén... En los ultimos años estuve trabajando de frutero antes de ser programador.
@@danielespanadero Gracias por responder, Gracias por los consejos.
desde la infraestructura estas importando cosas del domain, a mi parecer es capa por capa y debería ser directamenta a application, y de application hacia el domain, y los repos se deberían organizar aparte de los services ya que los repos son para cuando se va a modificar información y los services para cuando se desea obtener información.
claro que es una aplicación pequeña, me ha servido mucho gracias..
Estás en lo correcto. Es mejor dominio -> aplicación -> infraestructura. Lo hice así para no alargar mucho el vídeo ya que sería igualmente válido al no romper la regla de dependencia. Muchas gracias por el aporte. Un abrazo 🙂🤘🏻
Tengo una consulta, que paso si tengo más servicios, todos los deberia de hacer en el ApplicationConfig?
Muy buenas, siempre y cuando se trate del mismo proyecto no hace falta. Puedes añadir los servicios que necesites. Un saludo
Gracias por la explicacion, pero tengo una duda, porque las clases Services las declaras en la capa de Aplicacion, si en el diagrama de arquitectura hexagonal debe ir en Dominio?
¡Muy buenas Nicolas! Gracias por tu comentario y tu pregunta, me ha ayudado mucho a aprender e investigar sobre el tema, te respondo por lo que he podido leer hasta ahora, pero profundizaré más al respecto.
En la arquitectura hexagonal, puede haber algo de confusión acerca de dónde ubicar ciertos componentes debido a cómo diferentes personas interpretan y aplican el patrón.
En este caso, la confusión puede surgir debido a la forma en que la palabra "servicio" se utiliza en diferentes contextos. En algunos casos, "servicio" se puede referir a un "servicio de dominio", que, como bien dices, pertenece a la capa de dominio. Sin embargo, también existe el concepto de "servicio de aplicación", que es el tipo de servicio que se mostró en el vídeo.
El servicio de aplicación es el punto de entrada para las operaciones que vienen desde fuera del núcleo de la aplicación, como las solicitudes de la interfaz de usuario o las llamadas a la API. Estos servicios de aplicación pueden utilizar uno o más servicios de dominio para realizar su trabajo.
Me parece un tema muy interesante a tratar, me informaré bien y haré un vídeo al respecto explicando la diferencia y la finalidad de cada uno de los servicios y aclarando posibles dudas que queden sobre este vídeo al respecto. Un abrazo! 🤘🏻🙂
Segui todo el tutorial pero estoy teniendo un error de nullpointer exception, te queria preguntar, es necesario setiar la base de datos de MySQL creando las tablas para que funcione la aplicacion?
¡Muy buenas! Efectivamente, el error de NullPointerException puede surgir si estás intentando acceder a un objeto o a una propiedad de un objeto que es null. En el caso de una aplicación que utilice una base de datos, como MySQL, si no se han inicializado correctamente las tablas de la base de datos, es posible que intentes acceder a datos que, efectivamente, no existen y obtendrás un NullPointerException.
Además, te recomendaría que revises tu código para asegurarte de que estás manejando correctamente los casos en los que un objeto puede ser null. Una buena práctica es utilizar las Optional class en Java para evitar estos errores.
Espero que esta respuesta te sea útil y pueda ayudarte a solucionar tu problema, cualquier cosa no dudes en comentarlo, estoy aquí para ayudar! Un fuerte abrazo! 🙌🏻
Hay un punto que se viola la arqutectura Hexagonal, he mamado mucho de este ejemplo y veo una fisura
GetAdditionalTaskInfoUseCaseImpl situado en la capa de Dominio(en este caso no, pero debería) está dependiendo directamente de ExternalServicePort la cual extiende en un adaptador estando en infraestructura.
Osea tenemos una Impl que "mama" directamente sin servicio intermediario de un Adaptador, eso es una dependencia directa que la Hexagonal busca quitar
Habría que meter un servicio intermediario en la capa de Application.
Grax por el ejemplo le he dado un trillón de vueltas, lo usaré como base para todo.
Consultando mas a fondo en el ultra purismo al ser solo una dependencia de out tampoco es una falta grave, sinó leve, se recomienda la creación del servicio pero tampoco es algo que rompa 100% con la impermeabilidad
Muchas gracias por tu aporte, Perez. Estás en lo correcto, lo suyo sería añadir un DTO (Data Transfer Object) en la capa de aplicación para no depender desde la capa de infraestructura directamente de la capa de dominio. No lo hice para no alargar el vídeo más de la cuenta ya que no es del todo incorrecto (No te cargas la regla de dependencia), pero lo tenía que haber comentado. Lo dicho, muchas gracias por el aporte y un fuerte abrazo!
Creo que ya lo tengo montado paso código, acepto collejas
1-Creamos servicio
public class AdditionalTaskInfoService implements GetAdditionalTaskInfoUseCase {
private final ExternalServicePort externalServicePort;
public AdditionalTaskInfoService(ExternalServicePort externalServicePort) {
this.externalServicePort = externalServicePort;
}
@Override
public AdditionalTaskInfo getAdditionalTaskInfo(Long id) {
return externalServicePort.getAdditionalTaskInfo(id);
}
}
2-Modificamos las impl's creo que así funciona bien:
public class GetAdditionalTaskInfoUseCaseImpl implements GetAdditionalTaskInfoUseCase {
private final AdditionalTaskInfoService additionalTaskInfoService;
public GetAdditionalTaskInfoUseCaseImpl(AdditionalTaskInfoService additionalTaskInfoService) {
this.additionalTaskInfoService = additionalTaskInfoService;
}
@Override
public AdditionalTaskInfo getAdditionalTaskInfo(Long id) {
return additionalTaskInfoService.getAdditionalTaskInfo(id);
}
}
3-Finalmente modificamos el @Bean que nos modificaba la clase en infraestructura:
@Bean
public GetAdditionalTaskInfoUseCase getAdditionalTaskInfoUseCase(AdditionalTaskInfoService externalServicePort){
return new GetAdditionalTaskInfoUseCaseImpl(externalServicePort);
}
No logro ver el problema. Podrías explicarlo nuevamente? Entiendo que en la implementación de GetAdditionalTaskInfouseCaseImpl hay una dependencia con ExternalServicePort, pero dicho archivo corresponde a la capa de dominio, por lo que no logro ver el inconveniente.
La L de Liskov, no la L que te fumas los sábados por la tarde jajaajjaja, me ha matao... Qué grande
Es un buen gancho para que la gente se acuerde de ello, jeje. Un saludo! 🙂🤘🏻
Muy buen video, que temas usas en intellij?
Muchas gracias por tu comentario. Pues utilizo varios plugins. Si te refieres concretamente a los iconos, el plugin se llama Atom Material Icons
Un saludo. 😎🤘🏻
para crear un proyecto con mas de 50 entidades como seria la estructura de carpetas, siguiento buenas practicas
Muy buenas, Elkin. Muy buena pregunta. La respuesta es compleja, ya que siempre todo depende de los requerimientos. Por ejemplo, ahora estoy trabajando en un proyecto personal (voy subiendo el avance a CZcams) que terminará con más de 50 entidades, seguro. Estoy utilizando el clásico MVC. El motivo es que no tengo intención de escalarlo mucho y, por otro lado, si necesitara ayuda, es la arquitectura más conocida. Aunque debo decir que sería interesante el uso de monolitos modulares con DDD, ya que es una arquitectura bastante limpia, dividida por capas y fácil de escalar a microservicios si fuera necesario en el futuro. Espero haberte ayudado. Un fuerte abrazo!
Es jodido, he llorado
Gracias
Al principio cuesta un poco, pero vale la pena aprender este tipo de cosas. Un abrazo!
En este caso, donde irían los DTO y los Request Objects??
Si quieres que las dependencias sean *dominio -> aplicación -> infraestructura* , deberían de ir en la capa de aplicación para acceder a ellos desde la capa de infraestructura.
Creo que los casos de uso van dentro de application he estado leyendo, estoy en lo correcto o no
Sí, estás en lo correcto Carlos.
En la Arquitectura Hexagonal, los Casos de Uso representan las distintas formas en las que tu sistema interactúa con el mundo exterior.
Si bien la lógica específica de un caso de uso se encuentra a menudo en la capa de aplicación, también puede haber lógica en la capa de dominio que la respalda. Por ejemplo, si tienes una regla de negocio que dice que los usuarios no pueden retirar dinero si su saldo es demasiado bajo, entonces el método withdraw en tu objeto de dominio Account podría implementar esta lógica.
Un saludo!
una pregunta, es mejor segmentar las carpetas por roles como "controladores, servicios, etc" o segmentarlo por componentes como "usuarios, productos, etc" y en cada una colocar sus respectivos controladores dtos daos etc
Pues depende mucho de lo que vayas a hacer y del contexto. En proyectos grandes es mejor segmentar por componentes y estos a su vez dividirlos en diferentes capas. En proyectos pequeños o medianos no es necesariamente malo utilizar una arquitectura de MVC.
@@danielespanadero gracias, rey. podrias pasar el repo del proyecto? quiero analizarlo afondo que no he podido entender bien el bean de configuración:c
Hola he revisado tu repositorio y esta muy bien, sin embargo nose donde poner el DTO o pieso que la clase Task del dominio puede ser el DTO, segun DDD Task es el modelo de dominio TaskEntity es el mapeo ORM y el DTO es el objeto de trasnferncia de datos, nose donde poner el DTO, ya le he dado muchas vueltas.
Por favor si pudieras responder acerca del DTO, muchas gracias.
¡Muy buenas Carlos! Me alegra que hayas revisado el repositorio y encuentres valor en él. La confusión acerca de dónde colocar los DTOs es bastante común, así que intentaré aclarar esto.
Los DTOs son modelos que se utilizan para transferir datos entre subsistemas, procesos o capas. No tienen comportamiento y su propósito principal es estructurar datos para su transmisión.
En el contexto de la arquitectura hexagonal, los DTOs puedes encontrartelos tanto en la capa de dominio como en la capa de infraestructura. Aunque si quieres que tu aplicación tenga el siguiente camino Infraestructura -> depende de -> Aplicación -> depende de -> dominio, te recomiendo que estén en la capa de aplicación, esto permite que los detalles de la implementación de tu API puedan cambiar sin afectar a tu lógica de dominio.
Muchas gracias por todos tus comentarios, ya eres VIP del canal jeje. Un fuerte abrazo! 🙂
@@danielespanadero Que diferencia habría si pongo los DTO en la capa de dominio?
Tengo entendido que la SRP no tiene que ser una sola acción. TaskUserCase podría tener la responsabilidad del mantenimiento. Por lo cual podría contener las acciones básicas de mantenimiento.
Totalmente de acuerdo. A medida que más profundizo en SOLID mas me doy cuenta de lo que me falta por interiorizar estas cosas. Un abrazo! 🙌🏻🙌🏻
cual es el plugin para ver asi, las carpetas y archivos en IJ ? o es por la version de de IJ
Icons atom creo yo lo usé pero eso pone un poco lento el ide jajajajjaja a mí me pasó y sin esos iconos corre muy bien
Como comenta Emanuel, el tema se llama Icons Aton, es posible que ralentice el IDE, ademas en mi caso mi pc es bastante justo en cuanto a prestaciones... Aquí te dejo el enlace a la documentación: material-theme.com/docs/icons/atom-material-icons-plugin/
esta bien que el TaskService quede asi de gordo? no va encontra de los principios solid y clean q son base del hexagonal?
¡Hola Lorena! Tienes toda la razón en cuestionar si el TaskService gordo va en contra de los principios SOLID y Clean, que son fundamentales en la arquitectura hexagonal. Aprecio mucho que estés atenta a estos detalles.
En el vídeo lo hice de esa manera ya que quise enfocarlo más en la arquitectura que en el código, y compacté el TaskService para no alargar el video. Sin embargo, te sugiero dividir el TaskService en interfaces más pequeñas y específicas, lo cual te ayudará a implementar el principio de segregación de interfaces y hacer que tu código sea más limpio y mantenible.
Si te interesa explorar más sobre cómo aplicar los principios SOLID y Clean en tus proyectos, tengo este vídeo dedicado a ese tema:
czcams.com/video/KtxNclOV4jk/video.html
No olvides suscribirte al canal y darle like al video si te gustó. ¡Tu feedback es esencial para que sigamos aprendiendo juntos y creciendo esta increíble comunidad! ¡Un fuerte abrazo y nos vemos en el próximo video, Lorena! 😊🎉🚀
No entiendo el archivo de ApplicationConfig y el tema de los Bens. Alguien me podría explicar mejor?
Muy buenas, en cuanto pueda haré un vídeo al respecto. 🙂
DIF muy buen video pero me queda una duda, en el appconfig probando la logica ahi veo que si elimino el metodo de taskRepositoryPort el proyecto funciona perfecto, y al construirse no sale ningun error como con los otros metodos, realmente que esta haciendo este metodo?
Muchas gracias por tu comentario, Jose David. Técnicamente no debería de funcionar el proyecto, puesto que TaskRepositoryPort se importa en varios sitios, es posible que si ya lo tenias compilado cuando lo borraste o el ide lo guardó en caché no te de error (Me ha pasado alguma vez).
Aquí te paso los ficheros donde se importa o se implementa TaskRepositoryPort:
- src/main/java/com/exagonal/tasks/infrastructure/config/ApplicationConfig.java
- src/main/java/com/exagonal/tasks/application/usecases/RetrieveTaskUseCaseImpl.java
- src/main/java/com/exagonal/tasks/application/usecases/UpdateTaskUseCaseImpl.java
- src/main/java/com/exagonal/tasks/application/usecases/DeleteTaskUseCaseImpl.java
- src/main/java/com/exagonal/tasks/infrastructure/repositories/JpaTaskRepositoryAdapter.java
- src/main/java/com/exagonal/tasks/application/usecases/CreateTaskUseCaseImpl.java
Si quieres realizar alguna comparación con tu proyecto, aquí te dejo el repositorio de GitHub donde almaceno este proyecto (No olvides dejar una estrella para que llegue a más gente, jeje):
github.com/DanielEspanadero/arquitectura-hexagonal-java
Un fuerte abrazo!
@@danielespanadero dale dif muchas gracias por tu respuesta probaré bien y miraré el código como lo tengo, gracias por tomarte el tiempo
hay muchas cosas que no entiendo, yo entendy la arquitectura hexagonal como tres capas esta la capa dominio la capa aplicacion y la capa infraestructura, cuando la entendí la capa dd aplicacacion es un medio para conectar el dominio con infraestructura, es decir el dominio nunca tiene conexion directamente con infraestructura y estoy viendo que vos implementas la interfaz TaskRepositoryPort en JpaTaskRepositoryAdapter, no me queda muy claro porque eseas dos capas se estarian cominucando, hay varias cositas que no entiendo y para mi parecer hay que refactorizar, yo creo que la interfaz TaskRepositoryPort no deberi air en el dominio
Estimado Luis, gracias por tomarte el tiempo de dejar tu comentario. Me esforzaré por abordar todas tus inquietudes de manera detallada.
En primer lugar, es fundamental reconocer que conceptos como la arquitectura hexagonal, los principios SOLID y los patrones de diseño, no son aplicables de manera rígida e inflexible. Es necesario adaptarlos según las particularidades de cada proyecto y, en algunos casos, puede que no sea adecuado aplicarlos. Efectivamente, he visto proyectos en los que la capa de infraestructura no interactúa directamente con la capa de dominio, pero esto no implica necesariamente una mala práctica, ya que no se rompe la regla de dependencia.
A lo largo del vídeo, reitero que no existe un único enfoque correcto y menciono en cierto momento la posibilidad de utilizar un DTO en la capa de aplicación para que actúe como intermediario entre la capa de dominio y la capa de infraestructura. Mi objetivo en este caso no solo fue adaptar la arquitectura hexagonal a un CRUD sencillo, sino también presentarlo de manera didáctica para que aquellos que no estén familiarizados con el tema puedan comprenderlo, en lugar de limitarse a copiar y pegar.
Me gustaría conocer tus opiniones sobre qué aspectos del proyecto te gustaría ver refactorizados. Nuevamente, te agradezco por compartir tus pensamientos y espero que sigamos enriqueciendo esta conversación. ¡Un cordial saludo!
como se llama el tema del IDE para que muestre las carpetas de colores?
Muy buenas Nahuel, te respondo a la prengunta del otro comentario ya que creo que es muy interesante.
La inyección de dependencias a través del constructor es preferible, pero puedes usar @Autowired en el campo en casos sencillos, como es el caso del vídeo.
En cuanto a tener todos los métodos en una sola interfaz e implementarla en TaskService, esto no necesariamente rompe la arquitectura hexagonal. La arquitectura hexagonal es más acerca de cómo las capas de tu aplicación interactúan entre sí y cómo están separadas.
Sin embargo, tener una interfaz muy grande puede ir en contra de algunos principios de diseño, como el Principio de Responsabilidad Única (Single Responsibility Principle, SRP) y el Principio de Segregación de Interfaces (Interface Segregation Principle, ISP). Si consideras que tu interfaz se está volviendo demasiado grande o compleja, es recomendable dividirla en interfaces más pequeñas y especializadas, lo que facilita la comprensión, el mantenimiento y la prueba de tu código.
El tema del IDE para ver las carpetas de colores se llama Icons Aton, quí te paso la documentación: material-theme.com/docs/icons/atom-material-icons-plugin/
Un saludo!
@@danielespanadero Muchas gracias, ojala puedas hacer mas videos sobre Java y Spring, este video me gusto ya que aprendi algo nuevo y me encuentro en un punto donde no tengo muy claro que aprender exactamente ya que vengo aprendiendo Java desde hace tiempo. Un video sobre microservicios seria genial. Un saludo diff y gracias por el tema
Tengo la duda aunque sé que no es buena idea, pero la arquitectura hexagonal también funciona para monolitos, solo es una duda, ya que únicamente la e visto aplicada en microservicios
Es cierto que la arquitectura hexagona se utiliza muchísimo en microservicios. Sin embargo, no está limitada a ellos ya que, en un monolito, también es posible aplicar una arquitectura hexagonal para lograr una estructura de código más limpia y modular. Esto puede hacer que sea más fácil de mantener y, en última instancia, facilitar una transición a microservicios si eso es algo que se desea en el futuro.
Un saludo Marco! 🙂
Por cierto Marco, me parece muy interesante tu canal, te has ganado un suscriptor, sigue así!! 🙂
@@danielespanadero igual mi estimado
Buen vídeo pero por favor ahorra para un nuevo ordenador. No entiendo cómo puedes trabajar así.
Creo que 2024 va a ser el año en el que me acabe comprando un ordenador competente. Estoy demorando bastante porque para mis necesidades, me hace falta una buena máquina. Un fuerte abrazo y muchas gracias por tu comentario.
inttente realizarlo usando lombok y me da el error de dependencias ciclicas
The dependencies of some of the beans in the application context form a cycle:
los usecaseImpl añadi la etiqueta @Component entonces ya los pude usar en mi service, sin problema
Muy buenas Carlos, a mi también me pasa que a veces me da problemas el uso de lombok, me alegro de que lo hayas solucionado. Otra opción sería crear un bean en la configuración del proyecto para evitar el uso del framework en la capa de aplicación y hacerlo en la de infraestructura. Lo bueno es que lo has resuelto por tu cuenta, eso es importante en el mundo del desarrollo de software. Un abrazo y enhorabuena! 🙌🏻🙌🏻🙌🏻
A ver... varias cosas. Si a la hora de crear el proyecto con Spring metes una dependencia de Lombok te vas a ahorrar muchas lineas de código.
Por otra parte, si en ven de beans en las configuración utilizases la anotación @Autowired también te vas a ahorrar unas cuantas lineas.
Ya por ultimo... las comparaciones a null casi que mejor (a partir de Java 8, que es lo que utilizas) con Objects.isNull...
¡Muchas gracias por tus comentarios y aportes *jcodigoc* ! Te responderé por partes para asegurar que se tocan todos tus puntos y ayudar a otras personas que puedan tener las mismas preguntas.
*Lombok:* Entiendo tu punto sobre el uso de Lombok para reducir líneas de código. Sin embargo, "menos líneas de código" no es sinónimo de "mejor código". En ocasiones, la simplicidad y claridad pueden ser más beneficiosas que la concisión. Además, he tenido ciertos problemas de compatibilidad con Lombok en el entorno de Java 8, que pueden resultar en errores de compilación. Aunque puedes argumentar que la mayor parte del tiempo Lombok sólo ahorra la tarea de generar getters y setters, en el contexto de un video tutorial, prefiero evitar posibles complicaciones técnicas, en la mayoría de casos solo me ahorraba hacer *click derecho -> generate getters and setter* 😅.
*@Autowired:* Usualmente utilizo @Autowired en mi día a día y en la mayoría de mis videos sobre Java con Spring. Sin embargo, en el contexto de la arquitectura hexagonal, sólo la capa de infraestructura puede tener dependencia del framework (en este caso, Spring). Las capas de dominio y aplicación deben permanecer independientes del framework. Por esta razón, decidí utilizar la inyección de dependencias a través del constructor en lugar de @Autowired. Ambos métodos tienen sus pros y contras y su elección depende de las necesidades específicas del proyecto. Aquí hay algunas ventajas de la inyección a través del constructor:
_-> Inmutabilidad:_ Los campos pueden marcarse como finales.
_-> Simplicidad:_ Las dependencias son explícitas.
-> Prevención de NullPointerException: Se asegura que la clase tiene todas las dependencias necesarias antes de su uso.
_-> Facilita las pruebas:_ Permite el paso fácil de dependencias mockeadas en pruebas unitarias.
_-> Integración con otras herramientas:_ Herramientas como Lombok y las versiones más recientes de Spring favorecen esta práctica.
*Objects.isNull:* En cuanto a la preferencia de usar Objects.isNull para las comparaciones a null, admito que es más una cuestión de costumbre que de una elección deliberada. Sin embargo, apreciaría que compartas tu punto de vista sobre por qué consideras que Objects.isNull es una opción superior.
Espero que estas explicaciones ayuden a aclarar mis decisiones en el video. ¡Gracias de nuevo por tomarte el tiempo para comentar y compartir tus ideas! Un abrazo!
bueno viniste a comentar de manera un poco prepotente y te pusieron en tu sitio... xD
Pinche comentario prepotente, haz de ser de los insportables programadores que se creen mejor que otro
Se debe ser respetuoso al comentar y mucho más con alguien que no es soberbio...
DDD
DDD es la abreviatura de "Deliciosos Donuts de Dinamarca". 🍩🇩🇰
@@danielespanadero Me referia que hagas el video de DDD con Arquitectura hexagonal jeje
Tus repository estan teniendo dependencias de la capa de dominio como los modelos y los puertos, esto no va en contra de la regla de dependencia? ya que estas pasando por ensima de la capa de aplicación y estas consumiendo directo a la capa de dominio. no me queda muy claro eso, de igualmanera en lugar de usar DTOs en los controladores, estas usando los modelos de la capa de dominio, buno, creo que el video es mas para aprender la estructura de carpetas que si esta buena pero de ahí los componentes, como usarlos y la regla de dependencias, no me parece que esten bien. Igual considero que el video esta bueno.
Hola Hugo, muchas gracias por tu comentario y por señalar tus preocupaciones sobre la arquitectura hexagonal que presenté en el video. Tienes razón en que la regla de dependencia es importante y, en algunos casos, parece que no se sigue del todo en mi ejemplo. Hice esto de manera intencional para mantener el código más simple y fácil de entender desde una perspectiva didáctica.
Es cierto que la regla de dependencia establece que las capas internas no deben depender de las capas externas, lo que significa que la capa de dominio no debe depender de las capas de aplicación e infraestructura. En la práctica, puedes optar por estructurar tu código de la forma que mencionas: con la capa de aplicación dependiendo de la capa de dominio, y la capa de infraestructura dependiendo de la capa de aplicación.
Estoy de acuerdo en que usar DTOs en los controladores en lugar de los modelos de dominio es una buena práctica y permite separar mejor las responsabilidades y mantener la lógica del dominio independiente de la lógica de los controladores. Sin embargo, opté por no incluir DTOs en este ejemplo para evitar un código más verboso y complicado, lo que podría dificultar la comprensión del concepto de la arquitectura hexagonal para aquellos que lo están aprendiendo por primera vez.
En futuros vídeos, tengo previsto abordar estas preocupaciones y mostrar una implementación más rigurosa de la arquitectura hexagonal, siguiendo las mejores prácticas en cuanto a la regla de dependencia. Agradezco mucho tus comentarios, ya que me ayudan a mejorar el contenido y aclarar cualquier confusión que pueda surgir. ¡Un fuerte abrazo y gracias de nuevo por tu valioso aporte! 🤘🏻
La regla de dependencia va desde la capa mas externa a la capa interna. En este caso infra > application > domain. Infra al ser la mas externa PUEDE importar cosas tanto de Application como de Domain. Application solo de Domain, y Domain únicamente a si mismo.
De hecho el Repositorio de Infra debe conocer a la Entity de Domain.
En 2:42 dices "Las capas mas internas no pueden depender de capas externas" y que este enunciado pertenece al principio D de SOLID. Ese enunciado no es exactamente correcto pues no mencionas sobre la dependencia en abstracciones.
El principio D de SOLID dice: "Entities must depend on abstractions, not on concretions. It states that the high-level module must not depend on the low-level module, but they should depend on abstractions.", lo cual no es exactamente lo mismo a tu primer enunciado. Puede estar confundiendolo con Clean Architecture (Robert C. Martin) donde sí menciona que se debe depender de otras clases en la misma capa o en capas más profundas.
Muchas gracias por tu comentario, Franck. Está muy bien y me gustaría felicitarte por contrastar la información de los términos que vas viendo, creo que es una habilidad muy importante. El siguiente paso es no solo limitarte a leerlo, sino también a entenderlo.
Me gustaría recomendarte que leas sobre la 'Regla de dependencia' en arquitectura hexagonal y lo compares con la definición que tú mismo me has aportado sobre la 'D' de SOLID.
Si después de eso ves algo que no te cuadra, siempre estoy abierto al debate. ¡Un abrazo! 🙂
Felicidades por el video, es genial discutir estos temas @@danielespanadero.
En Hexagonal Architecture en realidad no hay capas. O si de todas maneras quieres definitivamente identificar capas serían sólo 2. La capa externa y la capa interna. Este concepto no está relacionado a ningún otro enfoque como Clean, Onion, etc. La regla de dependencia justamente habla de módulos no de capas y ahí la confusión.
Sí deseas separar lo que llamé inicialmente como "capa interna" en otras multiple capas como en Clean o Layered Architectures ese ya es un tema del BIZ y no tiene nada que ver con Hexagonal.
Proyecto
|
|_ index.html
|_ styles.css
|_ main.js
Y ya
Pd: es broma.
En verdad debería de ser así en la mayoría de casos, el problema es que al ser humano le gusta venirse arriba con la sobre ingeniería. 🤣🤣
Creo que el DDD no es una metodología.
¿Que es DDD?
si lo es,
TDD es el simple hecho de programar las pruebas primero
se complementa con BDD y DDD
BDD es basicamente seguir los requerimientos, puede tomarse como una extension de TDD
DDD es definir que todo gire entorno al dominio, que se puede traducir en diseñar sobre el papel el sistema con ayuda de todos los involucrados(devs, pm, stakeholders,etc), y pues te ayuda a definir lo que vas a programar.
LO MALO ESQUE VENDRA A DECIRNOS OTRA PERSONA EN 3 MESES QUE LA MEJOR ARQUITECURA ES ESTA.... LA NUEVA ...Y TODOS VAMOS ACORRER
Entiendo tu comentario, David. Aunque la cosa no va así. No hay una mejor arquitectura y nadie con dos dedos de frente podrá decir que "X" o "Y" arquitectura son LA MEJOR. Todo depende del caso concreto de tu aplicación. Es más, en la mayoría de mis proyectos personales utilizo el típico MVC de toda la vida en un monolito. Pero si tuviera que crear algo que está destinado a recibir miles o millones de peticiones por segundo, tendría que replantearme elegir otras opciones. Espero haberte aclarado un poco el tema. Un abrazo desde Barcelona, España. 🙂🙌🏻🙌🏻🙌🏻
Espero ya se haya comprado otra PC 🤣
Estoy en ello. Vivir solo en una ciudad como Barcelona dificulta mucho poder ahorrar, me gustaría que fuera este año. Aunque en el trabajo me han proporcionado una muy buena y les preguntaré si me dejan utilizarla. Un abrazo! 🙂🙌🏻
Con todo respeto, no veo el sentido abordar un tema con malas prácticas y mucho menos por querer hacerlo más simple o académico, lo ideal es aplicar buenas prácticas así se vuelva más complejo y verboso, y explicar un tema a novatos sin seguir las reglas que realmente aplican a esa arquitectura, no tiene ningún sentido.
¿Que mala práctica ves? Creo que una cosa es simplificar y otra llevar a cabo malas prácticas y das a entender que confundes los terminos. No puedo explicar algo de manera compleja y verbosa a alguien que nunca ha visto el termino. Lo suyo es simplificar, que no quiere decir llevar a cabo malas prácticas.
Soy una persona abierta a las criticas constructivas en pro de mejorar, pero si lees tu comentario, no dices nada. Da la sensación de que eres el típico que dice: "Vaya mierda de código", en lugar de decir: "esta parte se puede optimizar si en lugar de hacer esto, haces esto otro".
Hola DIF, gracias por esta clase maestra. Una preguntilla, tienes o tendrás algún video de una API en Spring Boot que aplique Spring Security con JWT para todo el tema de la seguridad en las aplicaciones?
Saludos Crack!
Muchas gracias por tu comentario, Roberto. Tengo pendiente hacer un vídeo solamente con Spring Security (Como mínimo hay que hacer un CRUD con varios endpoints para probarlo, así que tambien será de Spring Boot), ya tengo hecho el roadmap del vídeo, lo que me falta es sacar tiempo para grabarlo. En cuanto pueda lo haré. Un saludo y no olvides estar suscrito para enterarte de cuando subo el vídeo.