Muchas gracias por la explicación, todo fue muy claro. Puedo hacerte una pregunta, por que creaste una interfaz para el caso de uso, si ya este tiene toda la lógica de negocio basado en las interfaces que recibe en el constructor y desde la capa de infrastructure puedes utilizar directamente el caso de uso, que ventaja tiene crear interfaces a los casos de uso? muchas gracias.
Videazo!, gracias. Bien explicado.. Sin tanto rollo y es verdad.. No importa si programe o no con Java, lo lograste!, es súper entendible. Again. Gracias!
Gracias a ti Makito! Me alegra que te haya gustado, y sobre todo que te haya parecido bien explicado y relativamente sencillo, que era mi propósito principal. Un saludo y muchas gracias por tu comentario!
Hoy mismo lo cuelgo que lo he ido dejando y dejando.... y aún lo tengo pendiente. Te avisaré por aquí también. Gracias por el feedback, es el primer vídeo y mi mayor esfuerzo iba en que se entendiese bien y conseguir explicarlo bien, que no siempre es fácil. Gracias!
Perdona! Lo dejé en algún comentario, pero se me olvidó ponerne en la descripción. Ahí va el repo: gitlab.com/jaimesempere/hexagonal-tutorial El blog... uf lo tengo pendiente, lo siento, lo subiré cuando pueda, que aún tengo pendiente hacer el set up del blog, lo tengo solo en local. Disculpas!
Hola! Sí, tengo pendiente publicar el artículo y el repositorio, no me ha dado tiempo aún poner en marcha el blog. A lo largo de esta semana lo hago sin falta, y te dejo aquí los links. Mil disculpas!
Siendo 100% estrictos, o "más papistas que el Papa", el comentario no es desacertado. Incluso nuestro capa de servicio/aplicación tampoco debería llevar dependencias de lombok, ni tampoco depender del framework, así como tampoco nuestros puertos. Lo único que podría de llevar dependencias tipo lombok o de framework o de base de datos es nuestra capa de infraestructura. ¿Por qué? Por lo comentado en el vídeo: hexagonal busca que estas dos capas y puertos sean totalmente independientes y que podamos hasta cambiar de framework. Ahora bien, como siempre, hay veces que no debemos o no hace falta ser "más papitas que el Papa". Si tu equipo o proyecto ha decidido usar lombok (lombok tendrá sus cosas, pero ayuda bastante a legibilidad del código y a quitarte mucho boilerplate; si bien hay que usarlo con precaución a veces, como comento en el vídeo del patrón Builder), no le veo un gran problema. Se trata también de consensos y convenciones acordadas. Por otro lado, si quisiéramos quitarnos lombok el día de mañana, es darle al click derecho sobre la clase que use lombok y pinchar en el submenu lombok > delombok, para tener un código sin lombok (sí, habría que ir clase por clase, pero tampoco lo veo un drama en caso de necesidad). Como siempre, si conocemos las reglas y las implicaciones que tienen, podemos decidir si queremos ser más flexibles o no en ciertos aspectos. Un purista purista en hexagonal, igual te diría que nada de lombok. Por mi parte, no le veo un gran contra meter lombok en el dominio y/o aplicación (con cierta precaución y cierto mimo, y bajo ciertos consensos del equipo), aportando las ventajas comentadas (menos boilerplate y menos 'ruido'). La decisión es tuya, y de tu equipo. Un saludo! pdta. espero que con esta parrafada no se te vayan las ganas de comentar en otros vídeos 😁
De lo mejor que he visto en Java y arquitectura Hexagonal. Se nota que tienes mucha experiencia real.
Muchas gracias por la explicación, todo fue muy claro. Puedo hacerte una pregunta, por que creaste una interfaz para el caso de uso, si ya este tiene toda la lógica de negocio basado en las interfaces que recibe en el constructor y desde la capa de infrastructure puedes utilizar directamente el caso de uso, que ventaja tiene crear interfaces a los casos de uso? muchas gracias.
Excelente y magistral video. Recomiendas algun libro o curso para aprender tus conocimientos? 😅
El enlace al repositorio: gitlab.com/jaimesempere/hexagonal-tutorial
El artículo lo colgaré en los próximos días
Videazo!, gracias. Bien explicado.. Sin tanto rollo y es verdad.. No importa si programe o no con Java, lo lograste!, es súper entendible.
Again. Gracias!
Gracias a ti Makito!
Me alegra que te haya gustado, y sobre todo que te haya parecido bien explicado y relativamente sencillo, que era mi propósito principal.
Un saludo y muchas gracias por tu comentario!
Gran explicación, estupendo vídeo, muchas gracias
Gracias a ti por comentar! Buscaba eso, que fuese una explicación sencilla de entender, así que gracias!
Muy buen video, gracias por el contenido esta muy bien explicado!
Solo falto el enlace del repo, pero muchas gracias por compartir tu conocimiento
Hoy mismo lo cuelgo que lo he ido dejando y dejando.... y aún lo tengo pendiente. Te avisaré por aquí también. Gracias por el feedback, es el primer vídeo y mi mayor esfuerzo iba en que se entendiese bien y conseguir explicarlo bien, que no siempre es fácil. Gracias!
Ahí va el repo: gitlab.com/jaimesempere/hexagonal-tutorial
Próximamente el artículo del blog, que tengo pendiente montar por fin el blog
En q parte aplicarias la logica de negocios? Luego de mapear la entidad a objeto de dominio?
Muy buena explicación pero estaría mejor si dejaras link a repositorio y al blog
Perdona! Lo dejé en algún comentario, pero se me olvidó ponerne en la descripción.
Ahí va el repo: gitlab.com/jaimesempere/hexagonal-tutorial
El blog... uf lo tengo pendiente, lo siento, lo subiré cuando pueda, que aún tengo pendiente hacer el set up del blog, lo tengo solo en local. Disculpas!
@@ProgramadorProfesional gracias
Hola, muchas gracias por su contenido, prodia compartirme el link a la información mostrada, muchas gracias
Hola! Sí, tengo pendiente publicar el artículo y el repositorio, no me ha dado tiempo aún poner en marcha el blog. A lo largo de esta semana lo hago sin falta, y te dejo aquí los links. Mil disculpas!
@@ProgramadorProfesional tranqui muchas gracias por responder, estaré al pendiente de su canal para seguir aprendiendo
Hola, tengo entendido que la capa de dominio no deberi tener dependencias externas como loombok ni depender del Framework. Que ran cierto es esto?
Siendo 100% estrictos, o "más papistas que el Papa", el comentario no es desacertado.
Incluso nuestro capa de servicio/aplicación tampoco debería llevar dependencias de lombok, ni tampoco depender del framework, así como tampoco nuestros puertos.
Lo único que podría de llevar dependencias tipo lombok o de framework o de base de datos es nuestra capa de infraestructura.
¿Por qué? Por lo comentado en el vídeo: hexagonal busca que estas dos capas y puertos sean totalmente independientes y que podamos hasta cambiar de framework.
Ahora bien, como siempre, hay veces que no debemos o no hace falta ser "más papitas que el Papa". Si tu equipo o proyecto ha decidido usar lombok (lombok tendrá sus cosas, pero ayuda bastante a legibilidad del código y a quitarte mucho boilerplate; si bien hay que usarlo con precaución a veces, como comento en el vídeo del patrón Builder), no le veo un gran problema. Se trata también de consensos y convenciones acordadas. Por otro lado, si quisiéramos quitarnos lombok el día de mañana, es darle al click derecho sobre la clase que use lombok y pinchar en el submenu lombok > delombok, para tener un código sin lombok (sí, habría que ir clase por clase, pero tampoco lo veo un drama en caso de necesidad).
Como siempre, si conocemos las reglas y las implicaciones que tienen, podemos decidir si queremos ser más flexibles o no en ciertos aspectos. Un purista purista en hexagonal, igual te diría que nada de lombok. Por mi parte, no le veo un gran contra meter lombok en el dominio y/o aplicación (con cierta precaución y cierto mimo, y bajo ciertos consensos del equipo), aportando las ventajas comentadas (menos boilerplate y menos 'ruido').
La decisión es tuya, y de tu equipo.
Un saludo!
pdta. espero que con esta parrafada no se te vayan las ganas de comentar en otros vídeos 😁