Hola que tal espero disfruten este video. Recuerde también que como siempre el link del código fuente está en la descripción para que pueda descargarlo y hacer uso del mismo o si tienes alguna duda sobre el video por favor házmelo saber que con mucho gusto lo resolveré. Saludos.
Hola, gracias por el video. Entre la version sin modulos y la version con módulos, existen dos diferencias que me resultaron importantes: La logica del negocio en el segundo se traslada de la capa de applicacion a la capa de dominio, que me parece mas logico y el mapper pasa de dominio a la de aplicacion
Hola vengo investigando este tema de arquitectura hexagonal hace unos días, es como el 7mo o 8vo video que veo sobre el tema. Cosas que noto es que no hay un consenso sobre como nombrar paquetes y sufijos de clases, cada chef con su receta pero me gusta tu approach, tiene sentido y concuerda más o menos con las cosas que vengo escuchando en otros videos. Lo que me resulta curioso y no me termina de cerrar es que los Servicios de dominio no implementen interfaz y entonces veo como que el handler acoplado de cierta manera al dominio, o sea vi que otra gente si hace la interfaz lo toma como un "port" de entrada e incluso lo poenen en un paquete que .port.in y lo mismo veo en controller con el handler, el handler no veo que implemente interfaz. También el tema de agrupar más de un endpoint en los controllers, personalmente lo dividiría en clases diferentes para cumplir con SRP de SOLID. Te hago una consulta con respecto a los tests que no incluiste, al hacer el unit test de TaskCreateService, ¿mockearias tanto TaskRepository como TaskSuperComplexService o solamente TaskRepository ?
Hola @alejandrohierro8947 oye que buen comentario me alegra mucho el análisis que hiciste y como he mencionado en varios videos que he hecho de diferentes arquitecturas las arquitecturas no están cerradas ni son una única receta como lo mencionaste. Son un conjunto de conocimientos que pones en ellas y que al final haces lo que más valor te agrega. Voy a tratar de responder a todo lo que mencionaste y a tu pregunta. Si vez el video de la anterior arquitectura hexagonal que hicimos que no estaba modularizada vas a poder ver alli que los servicios estaban en los uses cases en el aplicationy allí tenían una interface para los servicios. Pero que pasa y como trate de mencionar en este video para este software que los servicios y las clases son tan pequeños no hace mucho sentido y no se va a notar que realmente aporte mucho valor el tener clases aparte para ello. Pero cundo son software muy grandes y que al final es lo que buscan las arquitecturas limpias no es mantenible tener varios servicios en un interface o tener miles de interfaces para una sola implementación yo trabaje en un proyecto core de Colombia en mi experiencia pasada y la verdad agradecí eternamente que no estuviesen los servicios en interfaces, sino en servicios aparte y clases segmentadas porque esa clase que implementa esos servicios hubiese tenido 100000 mil líneas de código porque el proyecto era demasiado grande y tenían muchas reglas de negocio. Y no, no crean una dependencia porque los handler son simplemente un comunicador no están trabajando con lógica que es lo que se busca cuando no quieres tener acoplamiento si le cambias el nombre a la clase no va a afectar en nada o si vas a cambiar el retorno pues tendrías que llevarlo hasta el controlador y cambiar el retorno que al final crear un software completamente desacoplado todo de todo creo que es algo complejo en alcanzar. También el tema de los controladores como bien lo mencionas está separado por lógica de negocio, pero claro bien si quieres separarlo más no hay ningún problema, pero tampoco la idea seria tener solo una única clase por endpoint porque mira que al final no tenemos lógica en los controladores literalmente solo llaman los habdlers diferente de otros controladores que usa la gente que le meten mucha lógica o captura de excepciones. Y por último el tema de los test si mencione que iba a anclar el video de testing que tengo, pero claro al final debes mockear todo tanto los repositorios como el servicio y el servicio en si el TaskSuperComplexService debería tener su propia clase de test validando esa lógica tan compleja ajajja. Espero haber resuelto todas tus dudas si tienes algo más por mencionar siéntente en la libertad de mencionarlo y seguiremos conversando. Saludos y nuevamente gracias por comentar el video. Te voy a dejar el video del testing por aqui por si te intereza checarlo ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-YTc3bba1bXU.html
Saludos mi hermano. Me alegro muchísimo que te estén siendo de ayuda los videos. Eso me motiva más a seguir publicandolos. Recuerda que estamos haciendo directos los viernes por si deseas unirte y hacer preguntas en vivo. Bendiciones.
Los Value Object son solo un objecto de valor inmutables y que hacen que tengan un root y finalmente nace los aggregates gracias a los Value Objects. Revise PEEAA Las validaciones se hacen con la JSR 330 en los Request por cada campo
Muchas gracias por tu comentario @carlosmollapaza9267 tienes toda la razon sobre la inmutabilidad de los value object lo tendre en cuenta para actualizar el repositorio. Saludos.
Amigo, hiciste el video de como crear proyecto multi módulo? me gustaría verlo porque no me está saliendo, quiero que uno de esos módulos tenga spring boot y no se si tengo que crear primero el proyecto spring boot y luego importarlo como módulo o qué.
Un saludo, Alejando. Mira al final no saque el tiempo para hacer el video. Pero en este directo que hice hace poco, hice el tema de la modularización y lo estábamos explicando. Como funciona. A Partir del 1.16.51 podrás encontrar lo que buscas. No es solo ponerlo como proyecto, aparte el gestor de dependencias debe gestionarlo y saber como lo trata. Por favor hazme saber si esto te funciona. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-skHgBW9cGWo.html
Hola @sanchez-emir me alegro que te haya gustado. Si te fijas en el video pasado hicimos la misma arquitectura pero toda en una misma gestión de dependencias de maven. Ahora lo hicimos separando por cada una de las capas de la arquitectura en módulos qué tienen su propia gestión de dependencias. Esto ayuda a tener el código mucho más escalable y salvaguardar más la arquitectura. Normalmente en los proyectos es muy buena práctica asignar una guardia del proyecto el cual se encarga de que todo este bien y no se esten rompiendo principios de buenas prácticas o como tal definiciones de negocio. Ahora el por que no puedo de ir separado es por que ya cuando lo quieres llevar a producción como lo desplegarias? Si cada uno es un proyecto independice con su propio purto y despliegue primero ya no sería una arquitectura hexagonal y segundo o llevaría más gastos. La mato y ventaja de esta modularizacion es que por ejemplo existen herramientas de CI/CD qué podríamos usar para que digamos si hubo algún cambio en uno de los poms no deje desplegar y el pipeline se rompa entre otras muchas más prácticas. En conclusión aunque están separados por micro proyectos y poms independientes todos conviven en la misma jerarquía padre del pon principal y son en conjunto un proyecto qu. Si lo hacemos en proyectos aparte ya no tendría sentido y ya pasaría a ser otra arquitectura. Espw o haberme echo entender. Muchas gracias por tu comentario. Saludos.
Que tal buenas noches. Si al final en directos continué subiendo contenido se me ha dificultado seguir subiendo contenido entonces he tidaro más por crear contenido de los directos. Aquí vas a poder ver otras variantes que fui haciendo en los directos con ventajas y desventajas de la misma. Saludos github.com/JamiltonQuintero?tab=repositories
Excelente video, aunque tengo una pregunta, siguiendo con el patrón cqrs ¿Cómo sería en el caso de que en una obtención de datos también se afecte el estado de la aplicación? me refiero que por lo menos para obtener ciertos datos requiera de aplicar reglas de negocio y validaciones (que para este caso es mejor crear un servicio como le mencionabas en el video) pero si además tengo que actualizar el estado de la aplicación de acuerdo a esas reglas de negocio. Lo pregunto ya que según el patrón están los commands y los querys para cada flujo, pero si en un query tengo por x motivo afectar el estado de la aplicación? Se podría decir que todo lo que afecte el estado de la aplicación es un command aunque la intención fuese obtener datos?
Es que si y tienes que modificar tu base de datos ya no puedes hacerlo como get porque estás rompiendo el verbo correcto para el crud., Alli deberías usar o un post si es un recurso nuevo o un put si es un recurso existente. O sea si tocas tu base de datos es un comando, pero si debes hacer lógica de negocio eso no cuenta como cambio de estado en tu aplicación es bussines logic que es normal en los servicios de dominio que puedes invocar en los casos de uso sin problema y sin romper el CQRS
Ten presente que los candidatos a post es cuando debes tener en cuenta es. Cambie mi dominio(base de datos) ees un comando aplique reglas pero solo para tomar decisiones en candidato al retorno y dar formato etc. Query
Por cierto buenas noches jajaja muchas gracias por el video me alegro mucho que te gustara me da mucha emoción que aun esté rodando este video por ahí jhaja
Hola bro, una pregunta, las pruebas de integración en que modulo se harían? si las hago en el modulo de infraestructura no me encontraría el contexto de spring-boot.
Hola bro que tal. Mira de hecho si las pruebas de integración van es en la infraestructura porque recuerda que estas pruebas le pegan es a un controlador. Entonces no necesitas mockear datos. Estos van es hacia nuestros services. Lo único que deberías mockear son el caso en el que tu flujo completo haga un llamado a un micro servicio externo, esa lógica la debes mockear. En resumen, van 100 por ciento en la infraestructura. Mañana puedo montar un ejemplo de un flujo base de una prueba de integración a un repo para que te puedas guiar. ¿Te parece?
Hola te cuento que hace poco estoy empezando a implementar esta arquitectura hexagonal, pero tengo un pequeño error en la capa de infraestructura tengo entendido que dentro de esa capa tiene que haber un clase de configuración pero al levantar la app me arroja el siguiente error *The dependencies of some of the beans in the application context form a cycle*
Hola @Nblopez13 saludos. Revisa como estas usando el Jpa y que estas mapeando o si te falta alguna notacion que estes omitiendo o que estes agregando adicional. Estu puede ser causando por los mappers manueales que estan en infraestructura que mapean los dominios o como te digo alguna notacion especifica que te haga falta Trata de revisar lo siguiente: Diagnóstico del Ciclo: A partir de Spring 5.1, el error debería mostrarte cuál es el ciclo que está causando el problema. Verifica el stack trace para identificar los beans involucrados. Uso de @Lazy: Una solución temporal que puedes probar es utilizar la anotación @Lazy en la declaración de tus beans. Esto puede romper el ciclo permitiendo la creación de beans. Clase de Configuración: Si estás usando una clase con la anotación @Configuration en la capa de infraestructura, verifica que los beans definidos dentro de esta clase no estén causando el ciclo. Inyección por Constructor: Considera cambiar la inyección de dependencias a través de campos con @Autowired por inyección a través del constructor. Esto puede ayudarte a identificar y evitar ciclos de dependencia. Por favor trata de detallar mas aqui si agregaste nuevas clases o hiciste algo adicional que este generando este error para que juntos logremos resolverlo. Recuerda, esto le podria estar apsando a mas personasl y la idea es que quede aqui plasmado para todos. Saludos
Muchas gracias por la pregunta @DiegoSilvaLimaco, ya que es una pregunta muy interesante. No deberíamos ponerlos con validaciones del framework porque justamente el framework hace parte de una externalidad o eventos que no podemos controlar, Si Mañana sale algún error algún bug o por defecto se desea cambiar el framework esas validaciones se pierden y segundo en nuestro dominio estaríamos generando dependencias de una externalidad. Recuerda que el fin de haber hecho esta arquitectura modular justamente es eso poder guardar mejor la arquitectura de temas como este. Mira que si queseras hacerlo a través de frameworks deberías instalar la dependencia en el pom del dominio y ahí ya se habría roto la arquitectura hexagonal. Pero es una pregunta muy buena y muy interesante. Más bien te invito ahi a tener un dominio rico y vivo. Dominios que encapsulen su lógica y no sean anémicos. Te dejaré por aquí un artículo sobre dominios anémicos por si no estás familiarizado con el término. Saludos y muchas gracias por tu pregunta. Bendiciones 😃 www.ceiba.com.co/ceiba-blog/programacion-orientada-a-objetos-como-lograr-que-un-diseno-nos-ensene/
