Introducción Arquitectura Hexagonal - DDD
HTML-код
- Опубликовано: 10 май 2016
- Hoy sentaremos los principios sobre la Arquitectura de Software y, más en concerto, sobre qué es la Arquitectura Hexagonal. Tras una primera temporada donde hemos hablado al respecto de los principios SOLID, y hemos visto los problemas del código acoplado en términos de testabilidad, vamos a pasar a dar un salto en términos de diseño de Software y nos centraremos en la Arquitectura de Software, o como lo denominaba Sandro Mancuso: "Macro-design".
Más info: codely.tv/screencasts/arquitec... 
Наука
Ya disponible el curso de Arquitectura Hexagonal donde entramos mucho más en detalle y lo ilustramos con ejemplos de implementación tanto en PHP como en Scala. Más información: pro.codely.tv/library/arquitectura-hexagonal/66748/about/
👍👍 llegó 👍 PP PP 👍 PP 👍👍👍👍👍👍👍pp 👍👍 PP l la 👍 lll 👍 lll l PP l PP PP
👍👍 llegó 👍 PP PP 👍 PP 👍👍👍👍👍👍👍pp 👍👍 PP l la 👍 lll 👍 lll l PP l PP PP
👍👍 llegó 👍 PP PP 👍 PP 👍👍👍👍👍👍👍pp 👍👍 PP l la 👍 lll 👍 lll l PP l PP PP
He leído y visto tantas explicaciones de arquitectura hexagonal, y finalmente logre comprenderla. ¡Muchas gracias, me suscribo!
Gracias!
Por si quieres más información, tienes un curso con ejemplos prácticos y mucha más info en pro.codely.tv/library/arquitectura-hexagonal/about/ 😊
Saludos!
Muchas gracias, excelentes tus videos. También espero los próximos episodios.
¡Qué didáctico! Ya estoy entendiendo este tema gracias a este video. Muchísimas gracias.
Bibliografía:
4:15 Uncle Bob - Clean Arquitecture
6:50 Fideloper - Hexagonal Arquitecture
Esperando el siguiente video con muchas ganas
Excelente vídeo. Ya estoy esperando con ansia el nuevo episodio.
+Daniel Moya Pérez Me alegro Daniel! Espero que te gusten :D
Cualquier cosilla que veas que no te cuadra o que harías diferente, feel free de comentarla! :)
Muy buen video.
Pero que hacer en el caso de que el framework provea funcionalidades como formularios o sistema de login. Por ejemplo, Symfony para poder usar el firewall, necesita que la entidad User extienda (si no recuerdo mal) de una interfaz de UserProvider. Es decir, en nuestro dominio tendríamos la entidad User acoplada a la impletación actual del FW. Entonces dejamos de usar estas herramientas que da el Symfony?
Muchas gracias!
Súper bien explicado, tienes un sub más 😎
Excelente vídeo y explicación
Visto en 08/05/2021
Muy bien explicado , gracias por tu aporte
Excelente video, me aclaro muchas dudas.
Se te ha entendido muy bien, gracias por el conocimiento.
Gracias a ti por el feedback!
Saludos!!!
Hola buen video, consulta:
Puedo de un caso de uso llamar a otro, por ejemplo tengo servicios que realizan acumulaciones otros que realizan canje, pero nace un tercero que es una reversa que debe cancelar las transacciones de canje y acumulacion que estan en dichos casos de uso, y despues generar nuevas a partir de las diferencias dependiendo de si una reversa es parcial o total, podria llamar en mi caso de uso de reversa a mi caso de uso de acumulacion y de canje??
Muy buen video, saludos desde México!!!
+Alan Neri gracias! 😊
Saludos!!
Según entiendo los casos son representados por servicios de aplicación, pero no me quedo claro los servicios de dominio.
Excelente explicación, espero verlo en nodejs pronto!
Ganaste un seguidor.
Gracias, eres muy bueno explicando.
Que fácil lo has explicado!
Cuales serían los 6 lados del hexagono? o porque le llaman así?
Muy guay pero como manejas la inyección de dependencias?
Gracias
Saludos, la serie de videos acerca de este tema va a continuar???
+Randy Hector ayer grabamos uno sobre composition over inheritance. Tema ligado al concepto de puertos y adaptadores 🙂
Genial, espero con ansias que se siga hablando de este tema y la lista de videos siga en aumento. Genial trabajo por cierto sigan asi.
Curso completo de Arquitectura Hexagonal: pro.codely.tv/library/arquitectura-hexagonal/about/
Por 30€ curso completo cubriendo todos los conceptos de Arquitectura Hexagonal 🙂
Hola tengo una duda, actualmente estoy utilizando como persistencia de datos el ORM Entity Framework no he terminado de entender donde se disparan los eventos, en la ejecución de los servicios de la capa de aplicación o en la capa de dominio?
Aquí tienes un vídeo donde comentamos justamente esto que planteas: ruclips.net/video/auEhX4WfCRA/видео.htmlm10s (minuto 13:10)
Ostras que rapidez, voy a mirar. Muchas gracias por la información y animo con el canal. SIEMPRE ES DE AGRADECER el conocimiento con los demás, así que , gracias de verdad. Saludos des de Mollet!!
Ojala pudieran explicar eso en php puro xD que me interesa pero no le entiendo nada
Lástima que esto se quedara solo en un vídeo y no siguiera con este tema, ya que lo explica muy bien. Faltó que hiciera un par de videos más mostrando donde crearía los "ports" y los "adapters" y los utilizaría. Ahora ya está en el yate y se ha olvidado ;).
Muy buena la del yate 😂😂😂. A pesar de haber lanzado CodelyTV Pro seguimos publicando en el canal 🙂. Toda la serie de antipatrones de test es lo último que hemos publicado: ruclips.net/video/XbkjUz20pOk/видео.html
Si te interesan temas de CQRS y DDD, justo tenemos el curso en CodelyTV Pro que le puedes echar un ojo 🙂
Curso completo de Arquitectura Hexagonal ya disponible 🎉
pro.codely.tv/library/arquitectura-hexagonal/about/
Por sólo 30€, curso paso a paso cubriendo todos los conceptos de Arquitectura Hexagonal 🙂
Me he metido un poco en esto de la arquitectura hexagonal, y ando un poco liado, se me esta haciendo muy difícil separar el dominio de la Base de Datos, tengo la sensación de estar haciendo las cosas 2 veces.
Tengo el dominio por un lado y por otro Base de Datos, que tiene una estructura igual.
Aquí empiezan las teorías.
Se hace una petición al Aplication Sevice, solicitando un usuario por la id, ¿este llama a al adaptador de persistencia y se instancia un objeto del modelo? Para eso el modelo y la base de datos tendrán de alguna manera que coincidir.
Una manera de coincidir sería que los dos objetos tuvieran una interfaz común y eso para cada uno de los objetos del modelo.
No se si estoy desvariando, pero vamos la sensación de estar duplicando cosas es patente.
Esperando tu siguiente video con impaciencia y muchas gracias por todo.
En futuros vídeos hablaremos de esto, pero en resumen, el esquema que plantearíamos para el ejemplo que comentas sería:
Petición llega a Application Service (AS) -> Éste llama al Servicio de Dominio (DS) `UsersFinder` -> Éste tiene inyectado una instancia concreta de la interface `UserRepository` (por ejemplo `MySqlUserRepository`) -> El DS llama al repositorio -> El repositorio obtiene los datos de la base de datos, construye la instancia de `User` y la devuelve.
Consideraciones:
* El DS se acopla a la interface `UserRepository`, en ningún caso conoce ninguna implementación concreta como la `MySqlUserRepository`.
* La interface `UserRepository` vive dentro del dominio
* La implementación `MySqlUserRepository` vive en infraestructura
* Quién decide qué implementación de `UserRepository` inyectar en el DS es el inyector de dependencias.
Si tienes dudas al respecto, te recomendamos que le eches un ojo al vídeo sobre el Principio de Inversión de Dependencias: ruclips.net/video/Uc8HKUXu63o/видео.html
Si quieres hacer un repo de ejemplo en GitHub para que le echemos un ojo y te demos feedback, encantados! :D
¡Saludos!
Muchas gracias por contestar, he ido investigando por mi cuenta, y tengo muchas ganas de ver evulucionar este tema.
El video es realmente muy bueno, solo te haré una crítica constructiva, este video es de bastantes conceptos por eso quise oírlo mientras conducía y se complica mucho con cualquier otro sonido; gracias por estos contenidos
Con el tiempo hemos mejorado invirtiendo en calidad de sonido. El vídeo tiene 7 años 😊
Se podría hacer esta estructura en angular?
Quizá tendrías que buscar como Designe Pattern.
Hola, muy buen vídeo.
Una pregunta, dentro de la arquitectura hexagonal, si tengo que "parsear" un xml o json a estructuras del dominio, debería tener-lo como funciones individuales dentro de cada objecto (por ejemplo en Device) o sería mas bien una clase separada con toda la funcionalidad?
Como se actúa de normal con el tema del parseado?
Muchas gracias.
Creo que haré una clase abstracta Parser y que hereden las implementaciones (JSON XML con diferentes librerías) y el objecto encargado de recibir los mensajes que tenga una objeto Parser.
Buenas Xu An!
Nuestra opinión sobre lo que planteas: El código de marshaller/serialización NO debería estar en el modelo de dominio. Esta fuente de información (XML, JSON, etc.) entendemos que proviene de una fuente de información externa y, como tal, debería ser algo perteneciente a la capa de infraestructura y no de dominio. De esta forma, si cambia la definición por parte de este servicio externo, nuestro dominio NO cambiaría, sólo el adaptador de este servicio de terceros.
Además, en nuestra opinión, preferiríamos tener una interface con la que interactuar y que ésta sea implementada por las distintas opciones (interface `Device\Infrastructure\DeviceMarshaller` e implementaciones `Device\Infrastructure\DeviceJsonMarshaller` y `Device\Infrastructure\DeviceXmlMarshaller`). Incluso entendemos que estas implementaciones no estarían ligadas tanto al estándar de definición que sigan (XML o JSON), si no a la fuente real de datos. Así entonces, asumiendo que vienen de un sistema externo de terceros llamado "CodelyTvWarehouse" y "OtroMolonWarehouse", tendríamos algo como `Device\Infrastructure\CodelyTvWarehouseDeviceMarshaller` y `Device\Infrastructure\OtroMolonWarehouseDeviceMarshaller`.
Si necesitas más info sobre esto, te recomendamos que veas el vídeo de Dependency Inversion Principle: ruclips.net/video/Uc8HKUXu63o/видео.html
Si subes el código a un GitHub o algo, encantados de dar feedback al respecto! :)
Ah perfecto. Me parece también buena idea nombrar las clases dependiendo del origen de los datos y no del tipo de parseado.
Me interesa mucho el tema del DDD, que libro me recomendáis: Domain-Driven Design Distilled (Vernon Vaughn) o Domain-Driven Design:Tackling Complexity in the Heart of Software (Evans Eric), alguna otra opción?
Muchas gracias por vuestra respuesta.
Saludos.
Segundo 5 y quiero ser honesto.
No voy a entender un carajo, pero lo voy a ver, gracias xD
Dónde habéis estado el resto de mí vida??
Buenas tardes, excelentes vídeos, gracias por compartir, una pregunta siguiendo el ejemplo de registro de usuario: Seria correcto tener lo siguiente: un application service que se llame UserApplicationService (Con las operaciones crud) que invoque a un UserDomainService (Con las mismas operaciones crud) que invoque a un UserRepository cuya implementacion es mysql, pongo esta pregunta porque tengo varias dudas (En este ejemplo no se tiene ninguna lógica de negocio mas que solo guardar consultar y eliminar información)
1. Es correcto usar un aplication service y un domain service que tengan los mismos 4 metodos (insertar, actualizar, borrar, consultar) o en este caso me sobra alguno de los 2?
2. Que reglas se deben seguir para nombrar un domain service? cuando usar un domain service? es siempre obligatorio?
3. En este caso que son solo operaciones crud es necesario tener un aplication y domain service?
4. Los objetos de dominio deben ser inmutables?
Mil gracias y quedo atento
En mi opinión para hace crud (puro) estas arquitecturas no tienen sentido, por la complejidad que conlleva el uso de abstracciones. Entiendo que no estás modelando bien el problema y por eso tienes un modelo que aplica solo crud (modelo anémico posiblemente)
Enlace a Post de Fideloper: fideloper.com/hexagonal-architecture
Buena explicacion pero el enfoque es mas procedural que OO. Ya que el dominio deberia estar diseñado con la OO en mente. Y la capa de aplicacion solo contener los casos de uso particulares de una aplicacion. Por otro lado, si la capa de aplicacion define la atomicidad ya es dependiente de una tecnologia cuando se supone no deberia serlo. Al entender que dominio y aplicacion son agnosticas, estan libres de tecnologias/frameworks. Podria ser necesario añadir una capa por encima de la de aplicacion para definir solamente la transaccionalidad (que ya nos crea una dependencia tecnologica).
Es sencillo... la arquitectura de software es un conjunto de componentes con responsabilidades unicas, sus relaciones y su lugar de despliegue...No es necesario hablar de clases cuando se habla de arq de sw...
La arquitectura hexagonal ni existe, ni es hexagonal y tampoco es arquitectura
Hablas mucho