Arquitectura HEXAGONAL en JAVA y Spring Boot: Guía DEFINITIVA para DESARROLLADORES
Vložit
- čas přidán 18. 06. 2023
- Repositorio con plantilla:
github.com/JamiltonQuintero/N...
------------------------------
¡Bienvenidos todos! En el video de hoy, nos adentraremos en el fascinante universo de la Arquitectura Hexagonal, una estrategia de diseño de software que se caracteriza por su flexibilidad y capacidad para adaptarse a diferentes escenarios.
En este video, desglosaremos los fundamentos de la Arquitectura Hexagonal, explorando cuándo es más conveniente usarla y cuándo es mejor optar por otras alternativas. A través de un ejemplo práctico desarrollado en Java con Spring Boot, demostraremos cómo esta arquitectura puede ser una poderosa herramienta en tus proyectos de software.
Durante nuestro recorrido, compartiremos diversos trucos, tips y consejos sobre cómo implementar la Arquitectura Hexagonal de forma efectiva, sacándole el máximo partido a sus características.
Resaltar que este video es el inicio de una serie en la que profundizaremos más en el tema, por lo que te invitamos a suscribirte y a estar pendiente de los próximos contenidos.
Además, para facilitar tu aprendizaje y práctica, proporcionamos un enlace al repositorio del proyecto en la descripción del video.
No importa si eres un desarrollador novato buscando expandir tus horizontes o un experto tratando de mantenerse al día con las últimas tendencias en arquitectura de software, este video está diseñado para proporcionarte una comprensión clara y completa de la Arquitectura Hexagonal.
Recuerda, como desarrollador, comprender y aplicar buenos principios de arquitectura es crucial para escribir código eficiente, mantenible y de alta calidad.
¡Disfruta del video y prepárate para adquirir nuevos conocimientos!
🌎 Mis Redes Sociales
Sigueme en Linkedin : / jamilton-alonso-quinte...
¿Qué tal te pareció este video? ¿Tienes alguna duda? Házmelo saber aquí en los comentarios y con gusto la resolveré. 😁😀
si en la capa de aplicacion, los services implementan los metodos del domain, exactamente de que se encargan los casos de uso, sigo sin entender esa parte 🙃
@cristianandresblandonguzma4669 que tal cristian un saludo bien especial, el tema es al final la separación de responsabilidades. Una mala practica que solemos tener cuando estamos migrando de una arquitectura layer en la que estamos acostumbrados a tener una clase de 2k o 3k de líneas, es difícil entender y ver la utilidad de esta separación. La finalidad de esta separación es tener servicios de dominio que pretender tener responsabilidades uncias a nivel de lógica de negocio y los servicios de los uses cases son servicios más enfocados en orquestar los llamados a esos servicios de dominio, no tener una arquitectura layer donde tendremos todo expuesto en los uses cases. A que voy entonces los servicios de uses cases deberían ser muy orientados a un patrón facede donde solo llamen servicios u orquesten llamados concretos ojo que para un crud es difícil ver esta lógica como lo mencione en el video esto es especialmente mas útil en escenarios más grandes donde tenemos muchoooo código y donde de hecho la arquitectura hexagonal es mas fuerte en proyectos grandes. Para un crud no le vamos a encontrar utilidad.
Por favor hazme saber si esta respuesta te ayudo a entender mejor esta parte si no puedes unirte a uno de los envivos y podría explicarte mejor con ejemplos. Saludos y gracias por tu comentario
Humildad, comprensión, sin fanatismos absurdos y sin seguir modas como borregos.
Con los pies en la tierra (no siempre caben algunas arquitecturas).
Gracias por el video y por tu tiempo, un saludo.
Un saludo muy especial mi estimado. No pudiste haberlo descrito de mejor forma. No hay mejor solución, solo hay soluciones a problemas y cada una tiene su cabida. Si te sirve mvc y te aporta valor a con toda es mejor no complicarse o forzar soluciones. Mil gracias a vos por ver el video y tomarse el tiempo de comentar. Bendiciones.
Hey parce, que buena explicación detallada sobre la arquitectura hexagonal.
Gracias por compartir tu conocimiento. 👍
Eyy Juannn que más mi rey. ombre que bueno que te haya gustado tengo que hacer un update de esta arquitectura con cosas adicionales que he aprendido. a recuerda verte la segunda parte que es una extención o mejora que es hacerla modular. Bendiciones y gracias por tu comentario. Saludos
Excelente! buena metodología de enseñanza de básico a lo complejo 🎉
Hola cesar mil gracias por tu comentario y me alegra mucho que te haya gustado. Bendiciones
Tu video se gana un 10 de 10 la verdad estaba super perdido del tema y con esto ya cubre las dudas que tenia bro muy buen contenido.
Hola @MeditationMind2 un gran saludo. Me alegro demasiado que te haya gustado este video y que te sea de tanta utilidad. Mil gracias por comentar. Un fuerte abrazo.
Enhorabuena por el vídeo, de las mejores exposiciones que he visto sobre arquitectura hexagonal. No obstante, me gustaría comentarte un par de puntos a ver qué opinas.
1. Los mappers DTO-model deberían estar en el controller. Por un lado me ha parecido raro que el controller solo tenga una línea, casi es una pasarela que no hace nada. Pero además pensando en que pudiera haber otra entrada al servicio de creación de usuario(por ejemplo) te obligaría a cambiar dos capas o tener que crear una copia del request en la nueva entrada(eventos, por ejemplo). Parece más sensato hacer el map al modelo de dominio y que el servicio sea agnóstico de DTOs.
2. Los servicios deberían estar contenidos en la capa de dominio. Este punto es algo más personal pero me encaja más en esa capa ya que el servicio está íntimamente ligado al dominio e implementa el caso de uso de la aplicación.
Espero que estos puntos sean de ayuda, a mi tu vídeo me ha sido muy inspirador.
Gracias y enhorabuena!
Saludos Edu muy válidos tus puntos, de hecho si te miras la parte dos de este video hago una arquitectura hexagonal más limpia. En las arquitecturas hexagonales es tenemos dos orientaciones, una clean arquitecture completamente limpia y otra un poco más flexible. El tema de los dts de acuerdo que pueden estar en la capa de la infra. Quizá quise dejarlos en aplicación dejándoles un poco más de donde se estaban usando, pero siendo más puristas a la arquitectura hexagonal y teniendo en cuenta que estamos usando una librería si sería mejor dejarlo en la capa de la infra. Saludos y gracias por tu comentario me alegro de que te gustara este video. Saludos
Muy bien video @felicidades, cuando subirás la continuación ??
Hola @ricardobravo6925 me alegro mucho que te haya gustado el video. Ya lo tengo grabado, lo empiezo a editar y creería que el sábado más tardar domingo lo estaría subiendo así que ya sabes para qué estés pendiente. Saludos y gracias por comentar.
Excelente video, me interesa mucho esto de las arquitecturas en Spring Boot.
Hay algo que no me quedo muy claro, para que se usan los mappers de application y en que se diferencias con los dtos del dominio?.
Gracias por estos videos, quedo al pendiente de los proximos!!!
¡Muchas gracias por tu interés en las arquitecturas en Spring Boot! Los mappers de aplicación se utilizan para convertir los datos del dominio y no exponer mis entidades de dominio y como en esta forma de implementarla, nuestros servicios que conectan lógicas están expuestos en aplicación y no en dominio como en otras formas de la hexagonal. Y para no enviar nuestro dominio a los controladores como respuesta y como requerimientos, o sea patrones Dto al final, entonces para hacer un poco más rápida la transformación de datos uso el mapper también en la aplicación . Pero es como lo menciono muchas veces en el video, es tema de gustos y es más bien algo a nivel personal, realmente si deseas no usarlo puedes omitirlo, pero te vas a dar cuenta de que si deseas no implementarlo, pero estás usando Dtos para respuesta igual tendrás que hacer mapeo de datos y se vuelve tedioso. Espero esto resuelva tu duda. Gracias por comentar claro que si estaré subiendo un video creo que en próxima semana máxima dos. Saludos.
Muy buen video bro, una cosita, el link de limkedin se puede modificar en tu perfil, así te creas uno personalizado y más fácil de leer, saludos!!
Que tal mi bro un saludo. Me alegra un montón que te haya sido de utilidad el video y que haya gustado. Wooo mira no sabía ejejje muchas gracias por la info voy a buscar para recortarlo mil gracias.
Hola Jamilton. Excelente video, una consulta. Bajo esta arquitectura la capa de seguridad donde se genera por ejemplo el JWT token y toda la configuracion de seguridad, en cual paquete se deberi trabajar? Entiendo que infraestructura no?
tengo exactamente la misma duda. la parte de configuracion de springsecurity, los beans y tal, donde deben ir?
@@GROOVETECHSETS Saludos. Toda esta lógica va en la infraestructura. Más o menos el pensamiento que debemos tener al momento de determinar donde va algo es el siguiente. ¿Lo construí yo? Si la respuesta es, si es una lógica de dominio. Si para usarlo debes importar una librería en el gestor de dependencias o el paquete es un paquete de un externo ya ahí nos damos cuenta de que es un candidato para infraestructura, ya que tú no puedes controlar ese código es una externalidad es algo construido por otra persona como lo es el caso de spring security. Lo mismo que por ejemplo jpa. Miren que jpa va en la infra. La seguridad es lo mismo.
Saludos. Toda esta lógica va en la infraestructura. Más o menos el pensamiento que debemos tener al momento de determinar donde va algo es el siguiente. ¿Lo construí yo? Si la respuesta es, si es una lógica de dominio. Si para usarlo debes importar una librería en el gestor de dependencias o el paquete es un paquete de un externo ya ahí nos damos cuenta de que es un candidato para infraestructura, ya que tú no puedes controlar ese código es una externalidad es algo construido por otra persona como lo es el caso de spring security. Lo mismo que por ejemplo jpa. Miren que jpa va en la infra. La seguridad es lo mismo.
Muy buenos videos amigo!!!. Tengo una duda espero que me puedas ayudar he visto tanto proyectos como videos en los que el puerto de persistencia en lugar de ponerlo en Dominio suele ponerse en Aplication en ports>inputs y suelen decir que también es valido. tengo entendido que en varias empresas adoptan esta arquitectura para sus problemáticas pero mi duda es. por que es valido poner el puerto de persistencia en application? es legibilidad, convención, etc?
Saludos, Sosa. Un gran saludo y muy buena pregunta. En general, hay empresas que no les gusta usar el dominio para no enredarse con todo el mundo de los dominios del DDD (Domain-Driven Design), porque al final se ven casi obligados a terminar usando DDD. Es importante entender que las arquitecturas son, por decirlo de alguna manera, un molde, un molde que no está exento de sufrir cambios, modificaciones o personalizaciones. Te vas a encontrar con millones de variantes de la hexagonal. ¿Cuál está mal? Probablemente ninguna... una arquitectura es una expresión del negocio, de la interpretación de una forma de plasmar o estructurar y al final es, de alguna forma, una especie de guía para los desarrolladores de cómo deberían distribuir sus clases a lo largo del sistema para que tenga consistencia. Esa consistencia la podemos dar nosotros. Si al arquitecto que definió esa solución le hace sentido y la ve escalable, pues funciona y está bien.
De hecho, algo curioso es que la arquitectura hexagonal oficial no habla de una carpeta de dominio. Esto se fue dando cuando se vio que al final la hexagonal compagina muy bien con las arquitecturas limpias. Las arquitecturas limpias sí hablan de una carpeta de dominio, y las hexagonales más modernas van orientadas a la clean architecture. Es por eso que vas a ver hexagonales con y sin dominio. Probablemente las hexagonales más maduras deberían tener su dominio ya que pretenden escalar mucho a nivel de dominios (y es el caso donde realmente deberíamos usar hexagonal). Las otras, probablemente, y te lo digo desde la experiencia, pudieron haber usado mejor una capa (layer) ya que si sus dominios no tienen tendencia al escalamiento, directamente deberían haber evitado la hexagonal... No hay bala de plata; cada arquitectura y, en general, cada solución tiene su caso de uso.
En sí, el puerto por otro lado lo que pretende es separar la capa del dominio/aplicación (principalmente el dominio) de externalidades o librerías y bases de datos. Por ende, todo lo que requiera una conexión externa, una base de datos o una librería externa, debería quedar en la capa de la infraestructura con el fin de no contaminar los dominios o tu business logic. Espero esta respuesta te sea de utilidad y te ayude a aclarar un poco más el panorama. Saludos y gracias por tu apoyo.
Una pregunta, revise el codigo y veo que usas 3 veces mapper para la creación y 2 para listar, mi duda es que di esto no afectará a al rendimiento cusndo se trabaje con objetos y cantidad mas grande
Si claro en el software todo tiene un precio. Si haces software seguros no pueden ser rápidos, si haces software rápidos no se puede pretender flexibilidad entre otros problemas, entonces allí lo que aplicamos querido @destroyergg9446 es que ocultamos la capa del dominio lo mismo las entidades de bases de datos. Tú no quieres exponer ni tus dominios puros ni tampoco tus entidades de bases de datos con todos los campos, ya que eso crea sistemas inseguros. Otra cosa es que estamos trabajando con Jpa como acceso a las bases de datos no puedes exponer simplemente tu entidad por controller te hacen un ijeccionfacilito. Entonces, al final, aunque parezca tedioso y mucha vuelta, lo que se crea es un envoltorio donde cada capa tiene su responsabilidad. Podríamos hacer algo diferente si se trabaja con JDBC template para acceso a datos y es tener dtos usar esos dtos para descargar la data en ese dto pasarlo al dominio, hacerle la lógica a ese dominio y retornar el mismo dto. Pero bueno, al fin y al cabo, son decisiones de arquitectura con las que tienes que vivir, nunca vas a lograr un sistema perfecto. Lo que se busca es llegar a los requerimientos de tu cliente. Espero te haya sido de utilidad esta respuesta para entender un poco más el porqué hice eso. Igual ojo no es regla de oro, fácilmente lo puedes omitir, es simplemente una forma en la que yo lo resolví, pero hay cientos de formas. Saludos y mil gracias por tu comentario.
Excelente video amigo! Una pregunta, pero en sí, la lógica de negocio pertenece a la capa de aplicación o de dominio?
Que tal @codingsavid6509 como vemos en este caso la lógica se está dando en el application. Si crees que la lógica es muy compleja y requiere varias implementaciones o sea varias clases llevátela a domain y ali creas un paquete service donde vas a almacenar las clases con mucha más lógica. Estoy preparando un video al respecto donde vemos como podemos quitar esa capa usecases y con otros patrones de diseño poder mejorar mucho más el flujo y hacerlo mucho más limpio. Espero poder montar el video pronto. Saludos y gracias por comentar me alegro de que te haya gustado.
@@JamiltonQOtengo una consulta más, crees que es buena práctica a nivel profesional crear una implementación completa por cada tabla de la base de datos que tenga? Es decir manejar a cada tabla como actor responsable de las operaciones que se ejecutan sobre la misma? Hay personas que critican este approach, yo en lo personas siempre lo usé pero algunos dicen que va en contra de lo orientado a objetos, yo justifico que al final el caso de responsabilidad más puro de cualquier comportamiento termina se termina traduciendo a queries de datos, por lo que cada tabla sería un actor con dicha responsabilidad, tú qué opinas? Una implementación completa por tabla o no?
Hola @codingsavid6509 , gracias por tu consulta. Crear una implementación completa por cada tabla de la base de datos puede funcionar en ciertos contextos, pero hay que tener en cuenta algunos factores.
Esto puede ser beneficioso en términos de claridad y mantenibilidad, ya que puedes ver claramente qué clase es responsable de qué operaciones en qué tabla. Esto sigue el principio de responsabilidad única y facilita la prueba de la aplicación.
No obstante, es importante considerar que este enfoque puede no alinearse siempre perfectamente con el diseño orientado a objetos, ya que las clases de implementación de la tabla pueden no corresponder a objetos del mundo real. Además, puede haber duplicación de código si las tablas comparten operaciones similares.
Además, si tu aplicación tiene una gran cantidad de tablas, este enfoque puede hacer que la aplicación sea más compleja y difícil de gestionar.
Por lo tanto, la elección de seguir este enfoque o no, depende en gran medida del contexto específico de tu proyecto. Si el modelo de base de datos se alinea bien con el modelo de objetos y el número de tablas es manejable, entonces puede ser una buena práctica. Si no es así, puede que tengas que buscar una solución más flexible y escalable, tal vez agrupando las tablas relacionadas bajo una misma implementación o utilizando un enfoque más basado en funciones o servicios.
Recuerda, en la ingeniería de software, a menudo no existe una única 'mejor' solución, sino que depende de los requisitos y limitaciones específicas de tu proyecto o que tanto valor te aporte el tener estos objetos comletos reflejados como diminios la pregunta reamente es. Considereas que te aporta valor? Crees que la mantenibilidad puede ser muy alta? Otros desarrolladores pueden entender facilmente el contexto del proyecto? si las respeustas son si adelante si no es mejor reducir un poco la complejidad recerda que no solo desarrollamos para nosotros en gran medida desarrollamos para otros desarrolladores. Espero que esto te sea útil y te ayude a tomar una decisión.
Muchas gracias por el vídeo Jamilton, algo que no me quedo claro, ¿estas comunicando la infraestructure directamente con el dominio al implementar en infraestructure el repositorio del dominio, sin pasar por aplicación? ¿eso esta bien?
Hola,
¡Gracias por tu pregunta! Entiendo tu inquietud acerca de la relación entre la infraestructura y el dominio.
En la arquitectura hexagonal, también conocida como patrón de puertos y adaptadores debemos mantener una clara separación entre la lógica de negocio (el dominio). La idea es que la infraestructura no se comunique directamente con el dominio. En lugar de eso, usamos interfaces (puertos) definidas en el dominio que abstraen los detalles de la infraestructura.
Cuando implementamos un repositorio, seguimos este principio. Definimos una interfaz para el repositorio en el dominio, describiendo las operaciones posibles, como guardar, buscar o eliminar, sin detallar cómo se realizan estas operaciones. Posteriormente, en la infraestructura, implementamos esta interfaz para interactuar con una base de datos específica o cualquier otro medio de persistencia.
Al hacer esto, nos alineamos con los principios de clean architecture, donde las dependencias fluyen desde la infraestructura hacia el dominio. Esto asegura que el dominio no dependa de detalles específicos de la infraestructura, manteniendo así la lógica de negocio aislada y facilitando la prueba, mantenimiento y evolución del sistema.
Ojo que no es necesario que estos pasen por el aplication o que estén en los casos de uso una cosa son los casos de uso y otra son los puertos y adaptadores. Existen dos formas de la arquitectura hexagonal una que es la normal y otra la orientada a la clean arquitecture la que usa ports and adapters. Y estos adaptadores son los que a través de interfaces como mencione anteriormente implementan o definen la implementación de as externalidades.
Por favor hazme saber si esta respuesta logro aclarar tu duda
@@JamiltonQO me quedo mas claro, muchas gracias
¿Se podría implementar esta arquitectura usando Spring MVC con thymeleaf para la UI?
¡Hola, José! Ante todo, te envío un cordial saludo. Tu pregunta es realmente interesante. Es cierto que hoy en día la tendencia es orientarse hacia la separación entre back-end y front-end. Muchas arquitecturas modernas se enfocan en permitir que el back-end se dedique exclusivamente a lo que mejor hace: procesar lógica de negocio, interactuar con bases de datos y proporcionar APIs. Por otro lado, se busca dejar la presentación y la interacción con el usuario al front-end, utilizando frameworks y herramientas dedicadas.
Este enfoque tiene varias ventajas, como facilitar la escalabilidad, permitir la evolución independiente del back-end y el front-end, y favorecer arquitecturas más desacopladas en lugar de monolíticas.
Dicho esto, si deseas implementar una arquitectura hexagonal con Spring MVC y Thymeleaf, ¡es completamente posible! En el contexto de esta arquitectura, Thymeleaf sería parte de tus adaptadores primarios. En la capa de infraestructura, en tus controladores, ya que estás haciendo uso de una externalidad o una librería. Esta organización te permitirá mantener una estructura clara y modular. Gracias por comentar y nuevamente un saludo muy especial.
Donde dice el artículo que define la arquitectura hexagonal que existen 3 zonas (dominio, aplicacion, infraestructura? Sólo define dos: aplicación y mundo exterior
Esto no es arquitectura de libro esto es arquitecturas que he aprendido a lo largo de los años en experiencias laborales. Además es una arquitectura hexagonal orientada a la clean arquitecture donde se aislá el dominio en una capa adicional que no es afectada por ninguna otra tecnología y la capa de la aplicación es reda como mera transacionalidad, pero nuevamente si te basas solo en un libro va a ser difícil que lo entiendas =) Saludos
Felicitaciones esto codigo esta muy bonito, esta muy bien estructurado, pero me surge la duda de porque en una arquitectura hexagonal tienden a ganular el servicio , es decir un caso de uso por ejemplo crear un Task lo ponen en un servicio aparte y no lo ponen como un servicio global como TaskService donde tengan create,edit,delete,get
Ey muchas gracias me alegro bastante que te guste esta estructura de código. Mira es un análisis muy bien hecho el que has abstraído y la razón es porque todas estas arquitecturas limpias se complementan bastante con todo lo que es clean code. Donde se busca tener clases método mucho más atómicos con responsabilidades más segregadas. Ya que tienen en negocios más complejos a crecer mucho a nivel de negocio y cuando lo tenemos en una sola clase Service que hace todo y al final no hace nada tienes que terminar separando estas clases. Pero de ahí va la lógica de que tengamos diferentes arquitecturas y la hexagonal es una arquitectura que está más orientada a caos de uso y modelos de negocio mucho más grandes. Pero el motivo principal es tener una responsabilidad única. Que aunque se crece más en clases el código queda más segmentado como bien lo mencionaste igual unas por otras.
@@JamiltonQO si me imagine que era por eso, resposabilidad unica y mas cuando se trata de proyectos colosales, me imagino que lo pones con esos casos de usos de manera didactica pero en grandes proyectos tiene mucho sentido ya que la logica de negocio tiende acrecer
@@JamiltonQO gracias por aclararme la duda, tambien trabajo con spring boot y java
@@gabrielpaz9914 exacto es que de hecho para esos casos de uso no tiene ningún sentido usar una hexagonal es muy poquito código pero en una app real donde tiende a crecer bastante las lógicas las reglas de negocio se agradece bastante la separación
@@gabrielpaz9914 no por favor pero si para eso estamos es un gusto poder resolver las dudas. A mira tu que bien que bien te felicito por estar por estos lugares y buscar mejorar la calidad de tu código sigue adelante
Buen día una pregunta sobre la capa de dominio, si quisiera llamar un servicio desde otro servicio que haría, cual sería la mejor forma de hacer esto?
Hola Mauricio, que tal todo. Tienes dos opciones uno es implementando la última letra de solid "Dependenci inversion" o sea a travez de interfaces y la muy conocida estrategia de service y service Impl o dos que hay gente que no está muy de acuerdo con esta regla yo en general no soy extremista si tengo que exponer una clase directa no me mortifico simplemente creas tu clase servicio la notas con @Service y la usas donde lo requieras o si quieres ir al purismo lo haces dependiendo de lo que sea si es una clase con lógica pura de dominio lo pones e el dominio si son transacciones la pones en un uses cases en el aplication. De hecho, la segunda parte de este video explico esto que estoy diciendo. Saludos, cuéntame si esta respuesta te fue útil o si lograste despejar la duda, por favor. Bendiciones
@@JamiltonQO Excelente, gracias por tu respuesta. ya tengo otra duda, la capa de dominio no de tiene la dependencia de spring, entonces no podría usar @Service o @Autowired
@@mauriciorestrepo8822 eso es muy muy cierto. Para ello lo que hacemos es que hacemos unos de los beans en springbot entonces esto inyecta la clase en el bean de spring y en el ciclo de vida sabe que de cargarlo en tiempo de compilación antes de que exista ose ejecute. Y de hecho mira que seguimos respetando la clean arquitecture porque no ensuciamos el dominio con un framework o librería ;)
github.com/JamiltonQuintero/ModularHexagonalArchitectureMaven/tree/master/infrastructure/src/main/java/com/jamiltonquintero/hexagonalmodularmaven/beanconfiguration
A y por cierto es con todo el gusto jajaja por aquí cualquier cosa a la orden
Excelente, muchísimas gracias
Estoy empezando, ¿se puede ir entonces de la capa de infraestructura directamente a la de dominio sin pasar por la capa application? Muchas gracias
me refiero a la hora de implementar la interfaces de Port
Hola que tal saludos. No entiendo a lo que te refieres de ir directamente a la capa del dominio hablando de los puertos. Es que tu puedes ir a la capa del dominio para ir por la interface que es la que se implementa en la infra y los DTos lo mismo si nececesitas un dto que esta en el dominio puedes llamarlo desde la capa infra pero no es que peudas digamos hacer logica en infra y llamarla en dominio ahi si estarias rompiendo la arquitectura todo deberia ser a travez de puertos o interfaces si requieres una logica de una externalidad la ahces en la infra. La implementas con una interface y en el dominio usas la interface que es tu puerto. No se si me hice entender xD
@@JamiltonQO muchas gracias! Te entiendo bien, osea, que resumiendo, no es obligatorio pasar por la capa intermedia ( de aplicación), a la fuerza. Que la implementacion de la interface-puerto se puede hacer directamente en la arquitectura
no tiene que ser escalonada si o si
@@LorenRuizG No no eso si siempre es obligacion la cominicacion siempre tiene que ser entre os dominios y los aplication a trevez de los puertos a lo que me refiero es que si digamos necesitas usar un DTO que esta en tu dominio en el aplciation lo puedes hacer. Pero en el flujo perfecto deberias tener por ejemplo un llamadodel controlador que esta en infra hacia el aplication, ese llama puertos que se implementan in infra lo que no deberias tener es implementaciones directas llamadas en infra que no pasen por el aplication por que eso quiere decir uno que estas rompiendo principio deDependency inversion lo ideal esq ue siempre lo hagas a travez de las interfaces. Dado el caso tu flujo sea muy pequeño create solo arqitectura hexagonal. Es que esta arquitectura hexagonal esta muy orientada a la clean arquitecture
que tiene un dominio y tiene el tema de los puertos. Es complciado de responder por aqui jaja cuando quieras te pasas por los directos y trato de darte un resumen rapido que sea quizas sea mas facil mostrandote flujos.
Jajajaja
=)