Introducción al curso

1

Introducción al curso de Profesional de Arquitectura de Software

Atributos de calidad

2

Definición

3

Atributos: Idoneidad funcional

4

Atributos: Eficiencia de ejecución

5

Atributos: Compatibilidad

6

Atributos: Usabilidad

7

Atributos: Confiabilidad

8

Atributos: Seguridad

9

Atributos: Mantenibilidad

10

Atributos: Portabilidad

11

Tensiones entre atributos

12

Analizando PlatziServicios

Patrones de arquitectura

13

Patrones monolíticos vs distribuidos

14

Patrones: Modelo Vista Controlador

15

Patrones: Capas

16

Patrones: Orientado a eventos / Provisión de eventos.

17

Patrones: Microkernel - Plug-ins

18

Patrones: Comparte-nada

19

Patrones: Microservicios

20

Patrones: CQRS

21

Patrones: Hexagonal - Puertos y adaptadores

22

Patrones: Diseño orientado al dominio

23

Combinando patrones de arquitectura

24

Analizando nuevamente PlatziServicios

Diseño de una arquitectura

25

Pararse en hombros de gigantes

26

Herramientas y partes de un diseño: Tipos de conectores

27

Conectores: Llamado asincrónico / sincrónico. Modelo Cliente servidor.

28

Conectores: Enrutador, difusión

29

Conectores: Pizarra, repositorio, colas, modelo PUBSUB

30

Escenarios y tácticas

31

Escenarios: Disponibilidad, detección, reparación

32

Escenarios: Reintroducción y prevención

33

Escenarios: Mantenibilidad

34

Escenarios: Prevenir efectos dominó y diferir enlace

35

Escenarios: Eficiencia de ejecución

36

Escenarios: Seguridad

37

Escenarios: Capacidad de prueba

38

Escenarios: Usabilidad

39

Validar las decisiones de diseño: Arquitectura en evolución

40

Último análisis a PlatziServicios

Modelado y documentación de arquitectura

41

Cómo comunicar la arquitectura: Vistas y Puntos de vista

42

Documentación vs implementación

43

Conclusiones del curso

No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Patrones: Hexagonal - Puertos y adaptadores

21/43
Recursos

También conocido como puertos y adaptadores.

¿Qué es la arquitectura hexagonal?

Aportes 17

Preguntas 7

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

  • La Arquitectura Hexagonal propone que nuestro dominio sea el núcleo de las capas y que este no se acople a nada externo. En lugar de hacer uso explícito y mediante el principio de inversión de dependencias nos acoplamos a contratos (interfaces o puertos) y no a implementaciones concretas.
  • A grandes rasgos, y si mucho detalle, lo que propone es que nuestro núcleo sea visto como una API con unos contratos bien especificados. Definiendo puertos o puntos de entrada e interfaces (adaptadores) para que otros módulos (UI, BBDD, Test) puedan implementarlas y comunicarse con la capa de negocio sin que ésta deba saber el origen de la conexión.

Hexagonal - Puertos y adaptadores

Nos ayuda a diseñar una aplicación que tenga bien claras cuáles son sus dependencias externas, es decir, cómo se va a consumir externamente y qué necesita del mundo exterior. Esto lo hace definiendo puertos que son su capa fina de comunicación con el exterior en dónde la aplicación sólo sabe su funcionalidad, pero no el cómo, y adaptadores que se van a encargar del cómo específicamente

Está bien la teoría pero hubiese estado mucho mejor haber llevado esto a clases en un framework mvc.

Con toda esta información no se como plasmarlo en mi código php

Patrones: Hexagonal - Puertos y adaptadores

Nos ayuda a construir un patron que tiene bien claras sus dependencias externas. Esto lo hace definiendo puertos que son su capa fina con el exterior, donde la aplicación sabe su funcionalidad pero no el como. Y existen adaptares que se encargarán del “Como” especificamente.


Si la App necesita acceso al file system o a la BD va a modelar un puerto que represente a sus datos y luego va a modelar un adaptador. Esta aplicación permite hacer tests de unidades muy fácilmente.


Ejemplos: Aplicaciones WEB

Patrón de arquitectura hexagonal / Puertos y adaptadores
Ayuda a diseñar una aplicación con dependencias externas claras.
Define puertos que son la capa fin con el exterior. La aplicación solo sabe su funcionalidad pero no el como y los adaptadores se encargan del como específicamente.
Ejemplo: Aplicación web

Sería genial un curso donde se ponga en practica ésta arquitectura

Yo les comparto este video de youtube que me ayudo muchísimo a entender el tema de la arquitectura hexagonal.

Esto lo comento por mera experiencia.
Esta arquitectura esta muy ligada con los ejemplos que vimos en la arquitectura de capas y MVC.
La principal diferencia que se tiene es que en le hexagonal requiere que el dominio declare los puertos (generalmente como interfaces lo cual abstrae por completo el problema de separar la implementación de la abtracción).
Son muy parecidos ya que en ambos separas las responsabilidades y en ambos casos el dominio desconoce los detalles de:

  • Quien lo llama o usa
  • Cómo se manejan los datos.
  • Como se ejecutan ciertos procesos (ej, envío de email o notificaciones)
  • Como se muestra la información (Por ejemplo, los servicios devuelve Array<Obj> y quien llamo al servicio [controller por ejemplo] generan un JSON o un CSV).

Para mi es una de las arquitecturas más limpias. El principal inconveniente es que genera muchos archivos y se vuelve complicado de manejar. Además de que es más complicado de implementar en lenguajes que no tienen validación de tipo de datos.

Como nota final, eta arquitectura es muy buena cuando tiene servicios complejos. Si estas realizando un API CRUD muy sencilla quizá sea un overkill manejar esta arquitectura

Ni Nueva Ni Arquitectura Ni Hexagonal, aqui

Hola estos son un ejemplo de scaffolding que me parecieron interesantes (spring boot) usando este tipo de arquitectura hexagonal:

application/
rest/ # el controller
request/ # aquí irán todos los objetos dto para la petición
response / # los dto de la response
domain/
repository/ # interfaz del repository
service/
Exception.java
Foo.java
infrastructure/
configuration/ # La configuración de las distintas bases de datos (MongoDB, Cassandra…).
# También configuración de los Beans (Services en este caso).
repository/ # Implementación de la interfaz repository para los distintos repositorios, también mappers, Modelo de datos, etc.
Application.java

🤖
La Arquitectura Hexagonal propone que nuestro dominio sea el núcleo de las capas y que este no se acople a nada externo. En lugar de hacer uso explícito y mediante el principio de inversión de dependencias nos acoplamos a contratos (interfaces o puertos) y no a implementaciones concretas.

Ayuda a diseñar una aplicación con dependencias externas claras.

en mi opinión, esto es mas de lo mismo solo que con nombres rinbombantes… en si aplicando meyer/liskov + solid + mvc podes llegar a un buen diseño de arquitectura. De echo en el libro mismo dice que el hexagono no tiene un proposito solo fue una elección para que le quede libre las caras de up y down. Pero bueno es mi opinión…

La arquitectura Hexagonal se enfoca en aislar el **núcleo de negocio** de la infraestructura, facilitando la **extensibilidad** y **mantenibilidad** del sistema al poder agregar o cambiar adaptadores sin afectar la lógica principal. Vamos a usar un ejemplo de un **sistema de pedidos** para un e-commerce, donde se gestionan los pedidos y su procesamiento. ``` /order-management-system │ ├── /src │ ├── /application # Capa de aplicación (casos de uso) │ │ ├── /ports # Interfaces (puertos) que definen los casos de uso │ │ │ ├── /inbound # Puertos de entrada (interacción del mundo externo) │ │ │ │ └── OrderService.ts # Ejemplo de puerto de entrada para gestionar pedidos │ │ │ └── /outbound # Puertos de salida (interacción con el exterior) │ │ │ └── OrderRepository.ts# Ejemplo de puerto de salida para repositorios de pedidos │ │ ├── /services # Implementación de los casos de uso │ │ │ └── OrderManagementService.ts # Ejemplo de implementación de la gestión de pedidos │ │ └── /exceptions # Excepciones de la aplicación │ │ │ ├── /domain # Capa de dominio (lógica de negocio) │ │ ├── /models # Modelos y entidades del dominio │ │ │ └── Order.ts # Ejemplo de la entidad Pedido │ │ └── /services # Servicios de dominio (reglas y políticas de negocio) │ │ └── OrderProcessingService.ts # Ejemplo de lógica de procesamiento de pedidos │ │ │ ├── /adapters # Adaptadores (interfaz con el mundo exterior) │ │ ├── /inbound # Adaptadores de entrada │ │ │ ├── /rest # Adaptador para REST API │ │ │ │ └── OrderController.ts# Controlador de pedidos expuesto en API REST │ │ │ ├── /cli # Adaptador para CLI (Command Line Interface) │ │ │ │ └── OrderCLI.ts # Interfaz de línea de comandos para gestionar pedidos │ │ │ └── /events # Adaptador para escuchar eventos externos │ │ │ └── OrderEventListener.ts # Listener de eventos para la gestión de pedidos │ │ ├── /outbound # Adaptadores de salida │ │ │ ├── /persistence # Adaptadores para interactuar con la base de datos │ │ │ │ └── OrderRepositoryImpl.ts # Implementación del repositorio de pedidos │ │ │ ├── /message-queue # Adaptador para interactuar con un sistema de mensajería │ │ │ │ └── OrderEventPublisher.ts # Publicación de eventos en un message broker │ │ │ └── /email # Adaptador para servicios de email │ │ │ └── OrderEmailSender.ts # Servicio para enviar notificaciones por email │ │ │ └── /config # Archivos de configuración del sistema │ ├── /application.yml # Configuraciones de la aplicación (entorno, puertos, etc.) │ ├── /db.config.ts # Configuraciones de base de datos │ └── /message-queue.config.ts # Configuración para el sistema de mensajería │ ├── /tests # Pruebas unitarias y de integración │ ├── /application # Pruebas de la capa de aplicación │ ├── /domain # Pruebas de la lógica de dominio │ ├── /adapters # Pruebas de los adaptadores │ └── /integration # Pruebas de integración │ ├── /docs # Documentación del proyecto │ ├── /architecture.md # Documentación de la arquitectura Hexagonal │ ├── /use-cases.md # Descripción de los casos de uso │ └── /api-spec.md # Especificaciones de la API │ ├── /infrastructure # Configuración y scripts de infraestructura │ ├── /docker # Configuración para contenedores Docker │ │ ├── Dockerfile # Archivo Dockerfile para construir la imagen │ │ └── docker-compose.yml # Archivo para orquestación con Docker Compose │ ├── /kubernetes # Configuración para despliegue en Kubernetes │ ├── /db # Scripts de inicialización de base de datos │ └── /messaging # Configuraciones del sistema de mensajería (RabbitMQ, Kafka, etc.) │ ├── /scripts # Scripts auxiliares para automatizar tareas │ └── init-db.sh # Script para inicializar la base de datos │ ├── /logs # Carpeta para los archivos de log │ └── application.log # Archivo de log de la aplicación │ ├── /build # Archivos generados por el proceso de build │ ├── /node\_modules # Dependencias del proyecto (si es un proyecto Node.js) │ ├── package.json # Dependencias y scripts del proyecto (si es Node.js) ├── README.md # Documentación principal del proyecto └── .gitignore # Archivos y carpetas que Git debe ignorar ``` Explicación de la Estructura 1. **Application (Capa de aplicación)**: * Aquí se definen los **puertos** (interfaces) de entrada y salida, que representan la abstracción entre la lógica de la aplicación y los adaptadores. * **Puertos de entrada**: Representan las interfaces de interacción con el usuario o sistemas externos (como servicios REST o CLI). * **Puertos de salida**: Interfaces que se conectan a componentes externos como bases de datos o sistemas de mensajería. 2. **Domain (Capa de dominio)**: * Aquí se encuentra la **lógica de negocio pura**. Incluye entidades, modelos, y servicios de dominio que contienen las reglas de negocio. Esta capa no tiene dependencia de infraestructura, lo que la hace muy reutilizable y fácil de testear. 3. **Adapters (Adaptadores)**: * Estos son los **adaptadores que conectan el núcleo del sistema (application/domain)** con el mundo exterior. Incluyen: * **Adaptadores de entrada**: REST APIs, CLI, listeners de eventos, etc. * **Adaptadores de salida**: Implementaciones concretas de los puertos de salida, como acceso a base de datos, integración con sistemas de mensajería, envío de emails, etc. 4. **Config**: * Aquí se encuentran los **archivos de configuración** de la aplicación, como configuraciones de la base de datos, sistemas de mensajería y otros servicios. 5. **Tests**: * Contiene las **pruebas unitarias e integración**. Se dividen por las capas del sistema para asegurar que cada componente funcione correctamente de forma aislada y en conjunto. 6. **Infrastructure**: * Configuración relacionada con la **infraestructura del proyecto**, como Docker, Kubernetes y scripts de base de datos. 7. **Logs**: * Carpeta destinada para almacenar los archivos de log del sistema, facilitando la auditoría y depuración. ### Ventajas de la Arquitectura Hexagonal * **Independencia de la infraestructura**: La lógica del negocio está completamente aislada de los detalles técnicos externos, lo que permite cambiar tecnologías sin afectar el núcleo del sistema. * **Facilidad de prueba**: Al estar las capas desacopladas, es sencillo escribir pruebas para la lógica de negocio sin necesidad de instanciar bases de datos o servicios externos. * **Extensibilidad**: Puedes añadir nuevos adaptadores (por ejemplo, un nuevo sistema de mensajería) sin modificar el código del núcleo. * **Mantenimiento**: Cada capa es responsable de un conjunto bien definido de tareas, lo que facilita el mantenimiento y la evolución del sistema. Este ejemplo muestra cómo se organiza un proyecto usando **arquitectura Hexagonal**, donde los componentes de la aplicación (lógica de negocio) están completamente desacoplados de las interfaces del mundo exterior (como bases de datos, APIs, o mensajería).

En este vídeo pueden verlo con un ejemplo en java muy al estilo hola mundo: https://www.youtube.com/watch?v=VLhdDYaW-uI&ab_channel=ManuelZapata

Arquitectura Hexagonal y DDD
Al ser una arquitectura que fomenta que nuestro dominio sea el núcleo de todas las capas (o regiones), y que no se acople a nada externo, encaja muy bien con la idea de DDD.