Arquitectura Hexagonal

Dato curioso:
La arquitectura hexagonal (Ports and Adapters) se basa en el patrón de comportamiento “Adapter” https://refactoring.guru/design-patterns/adapter

Lo bonito de los patrones es que sirven tanto en lo micro (como una función) como en lo macro (toda la arquitectura)

Arquitectura Hexagonal

Esta arquitectura está compuesta por:

1. Aplicación: Es la capa de negocio diseñada como un hexágono.
2. Puertos: Son aquellos puentes hacia la aplicación.
3. Adaptador: Realizan la conversión de algo externo hacia lo que la aplicación entiende, es decir, será el ajuste hacia algo que el puerto pueda entender.

Regla de la dependencia: Los elementos externos tienen conocimiento de lo que hay hacia dentro (en la aplicación), pero nunca al revés, la aplicación no tiene conocimiento de estos adaptadores que se están construyendo alrededor de la aplicación.

Actos primarios: Son aquellos adaptadores que son capaces de iniciar interacciones en el sistema, por ejemplo una interfaz gráfica o un API Rest que se comunican con una API de clientes y ésta finalmente es quien interactúan con la aplicación.

Actores secundarios: Son aquellos adaptadores que son de alguna forma notificados de acciones que ocurren en la aplicación. Son parte del flujo.

¿Por qué un hexágono?

Para dar espacio para insertar los puertos y adaptadores que sean necesarios.

En la última aplicación en la que estoy trabajando:

Es una aplicación que toma asistencias de las personas que acudieron a un evento de beneficio social con lectura biométrica. De momento se está usando la huella dactilar. Ahora vamos a implementar reconocimiento facial con AWS Rekognition para las personas que tienen problema con su huellita.

En este caso el puerto puede ser “API de comprobación biométrica” o solo “API de comprobación” dependiendo de si necesitamos que siempre se use algún biométrico o si queremos dejar abierta la posibilidad de usar otro medio como tarjetas RFID por ejemplo. Habría que ver si pudiera darse el caso realmente.

Y el adaptador sería la implementación concreta “Reconocimiento facial”, “Reconocimiento huella dactilar”, y “Verificador de RFID” si necesitáramos soportarlo.

Creo que el artículo de cockburn tiene un estilo en el que trata de ser poético y no se le entiende muy bien, pero aquí les dejo un video de codely.

https://www.youtube.com/watch?v=eNFAJbWCSww

Lectura complementaria, en su momento este artículo fue el que mejor me hizo entender como funcionaba 😃
https://towardsdev.com/hexagonal-architecture-deep-dive-with-postgresql-redis-and-go-practices-4b051f940e93

Arquitectura Hexagonal.

Se llama “hexagonal” porque visualmente, puedes dibujarla como un hexágono con diferentes lados, donde cada lado representa un punto de entrada o salida hacia/desde la aplicación.

En esta arquitectura, el “hexágono” en el centro es la aplicación, y los lados del hexágono representan los diferentes adaptadores que pueden interactuar con la aplicación.

Estos adaptadores pueden ser divididos en dos categorías principales:

1. Adaptadores de entrada o de comando (actores primarios): Estos son los puntos de entrada a la aplicación. Por ejemplo, la interfaz de usuario, una petición HTTP a una API, una llamada a una función, etc. estos son elementos activos.

2. Adaptadores de salida o de consulta (actores secundarios): Estos son los puntos de salida desde la aplicación. Por ejemplo, una base de datos, un servicio web, un sistema de archivos, etc. estos actores no van a iniciar interacciones sino que mas bien van a ser parte de un flujo.

Regla de la dependencia.

Lo más importante de la arquitectura hexagonal es que la lógica de negocio no tiene conocimiento de quién o qué está interactuando con ella. La lógica de negocio se comunica con el mundo exterior a través de abstracciones (puertos) y estas abstracciones son implementadas por los adaptadores. De esta forma, puedes cambiar los detalles técnicos o de infraestructura sin afectar la lógica de negocio.
En resumen, se llama “Arquitectura Hexagonal” porque puedes visualizarla como un hexágono con diferentes puntos de entrada y salida, cada uno de los cuales puede ser conectado o desconectado sin afectar a los demás, proporcionando así una gran flexibilidad y facilitando las pruebas y la mantenibilidad.

En un proyecto del trabajo en el cual estoy trabajando que es una migracion de Cash Empresas, implementando software comprado al core bancario del banco, la arquitectura hexagonal se generaria de la siguiente manera:
Sistema de Pagos y Cobros Interbancarios
Port1: P/C en Canal Web
Adapter1: GUI de Banca Empresas

Port2: API de debitos y creditos
Adapter2: Oracle BD

Aquí un ejemplo de la arquitectura hexagonal https://github.com/vicente100est/Sales_hexagonal_architecture

En esta arquitectura tenemos un elemento central, la aplicación (o dominio, para los entendidos xD), la cual representa un hexagono

![[Captura de pantalla 2023-09-18 a la(s) 23.04.50.png|300]]

Alrededor de la aplicación, tenemos lo que se llama puertos. Son el puente hacia nuestra aplicación. Veamos un ejemplo:

![[Captura de pantalla 2023-09-18 a la(s) 23.06.49.png|300]]

Además, sobre los puertos, tenedremos algo más llamado adaptadores. Esto se encarga de hacer la conversión de algo externo a algo que nuestra aplicación (puerto también) entiende:

![[Captura de pantalla 2023-09-18 a la(s) 23.07.48.png|300]]

Por ejemplo, la interfaz convierte la información a algo que la API de clientes puede entender. En el otro lado, la API de la base de datos podríamos tener código específico que pueda interactuar con esta base de datos (clases para trabajar con MySQL y nos permita adaptarnos también al algo que MySQL entienda también a través del puerto):

![[Captura de pantalla 2023-09-18 a la(s) 23.09.58.png|300]]

En este punto es donde podemos aplicar el principio de abierto y cerrado, creando nuevos adaptadores para interactuar con el API de clientes, por ejemplo.

En esta arquitectura es realmente importante el principio de las dependencias visto en [[Principios de diseño]]. Están los elementos externos quienes conocen los elementos internos de la aplicación, pero nunca al revés, la aplicación nunca conoce los elementos de sus entes externos.

Conceptos complementarios

Son los adaptadores que son capaces de iniciar interacciones en el sistema, elementos de alguna forma activos, como por ejemplo las interfaces gráficas.

Son los adaptadores que de alguna forma son notificados de acciones dentro de la aplicación. Esto no inician interacción sino que son parte del flujo. Por ejemplo, una interfaz de enviar el formulario y en algún punto del proceso solicitamos a la base de datos que haga algo, como una inserción. No inicia la interacción sino que recibe.

A esta arquitectura también se le conoce como Puertos y Adaptadores

Para dar espacio para insertar los puertos y adaptadores que sean necesarios. Es algo meramente visual, no debe ser un hexagono como tal siempre.

Prefiero el nombre de puertos y adaptadores, al inicio me confundió mucho el nombre de “hexagonal” y por lo regular, las aplicaciones no llegan a tener hasta 6 puertos

Trabajé en mi TEG (trabajo especial de grado), acá desarrollé un pequeño y simple videojuego en Unity como prototipo para demostrar las ventajas de trabajar con arquitecturas.

En mi caso, apliqué una arquitectura hexagonal en mi ESB (Enterprise Service Bus) que viene siendo el «core», mientras que en los «puertos» utilicé inyección de dependencia y los «adaptadores» son todos los servicios principales del juego como audios, images, database, login, etc.

✅

La arquitectura hexagonal, también conocida como arquitectura de puertos y adaptadores, es un patrón arquitectónico que promueve la separación de preocupaciones y la modularidad en un sistema de software. Este enfoque arquitectónico se basa en el principio de inversión de dependencias y tiene como objetivo principal facilitar la evolución y el mantenimiento del sistema.
.
En la arquitectura hexagonal, el núcleo de la aplicación está rodeado por capas externas que se comunican con el mundo exterior a través de puertos (interfaces). El núcleo de la aplicación contiene la lógica de negocio y no tiene dependencias hacia las capas externas. Las capas externas, a su vez, implementan los adaptadores que se conectan a los puertos y permiten la interacción con elementos externos, como bases de datos, interfaces de usuario o servicios web.
.
Aquí tienes una representación visual de la arquitectura hexagonal:
.
-------------------------
| Capa de Presentación |
-------------------------
| ↑
| |
Adaptadores
| |
↓ |
-------------------------
| Núcleo de la Aplicación |
-------------------------
↑ |
| |
Puertos
| |
↓ |
-------------------------
| Capa de Infraestructura |
-------------------------
.
En esta representación, la capa de presentación puede ser una interfaz de usuario, una API o cualquier otro componente responsable de la interacción con los usuarios o sistemas externos. Los adaptadores en esta capa se encargan de traducir las solicitudes y respuestas entre el núcleo de la aplicación y los formatos necesarios para interactuar con el mundo exterior.
.
El núcleo de la aplicación contiene la lógica de negocio y se mantiene independiente de las capas externas. Los puertos son interfaces que definen las operaciones que el núcleo necesita para interactuar con los elementos externos, como persistencia de datos, servicios de terceros, etc.
.
La capa de infraestructura proporciona implementaciones concretas de los puertos y adaptadores definidos en las capas externas. Estas implementaciones se encargan de la comunicación con los elementos externos, como bases de datos, servicios web, sistemas de archivos, etc.
.
La arquitectura hexagonal permite una fácil adaptación y pruebas, ya que los puertos y adaptadores se pueden intercambiar sin afectar el núcleo de la aplicación. Además, facilita la evolución del sistema, ya que los cambios en los elementos externos se limitan a las capas externas sin afectar el núcleo.

Saludos, trasladando el proyecto actual de software que hago parte , este sería desde mi punto de vista la conversión a la Arquitectura Hexagonal

Application = Usos de casos , Lógica de negocios
Ports = Interfaz o puentes con las Apis de los a
Adapter = UI , INTEGRACIONES ( SCANNER ) ,DB

En el proyecto en el cual estoy trabajando actualmente un ejemplo de puerto sería la API de BD y el adaptador PostgreSQL.

Caracteristicas de esta arquitectura:

• Regla de la dependencia:

Los elementos externos tiene conocimiento de la aplicacion, pero nunca alreves

• Actores Primarios:

Son basicamente adaptadores, que son capas de iniciar interacciones en el sistemas, son activos.

• Actores Secundarios:

Son adaptadores notificados de alguna accion ocurrida en la aplicacion o de alguna manera guiados, estos acrores no inician acciones

Como lo tenemos en el proyecto donde trabajo creo que un controlador es un adaptador porque si recibe la patición por api rest, o por grpc cambia.
También los repositorios pueden ser un adaptador porque si usa una u otra base de datos cambia su implemetnación.

Pero no estoy seguro de estarlo identificando bien.