Estándar de Arquitectura Hexagonal

Con la aparición y la creciente adopción de la Arquitectura de Microservicios, también crece la demanda de estándares arquitectónicos que puedan ayudar a crear e implementar estos servicios. Un estándar arquitectónico puede ser de gran ayuda en este viaje de creación e implementación de servicios. El objetivo de este post es presentar el estándar arquitectónico hexagonal, sus ventajas y algunas desventajas, y cómo utilizarlo es importante recordar que cada elección tiene un costo. Por lo tanto, vale la pena mencionar que se recomienda conocer varias herramientas, sus ventajas y costos. Se debe elegir la que sea más rentable teniendo en cuenta las ventajas.

Estándar de arquitectura hexagonal

En algún momento de mi vida escuche una frase relacionada con la vida. Sin embargo, también se aplica al desarrollo de software:

"Una persona inmadura piensa que todas sus elecciones generan beneficios... una persona madura sabe que todas las elecciones tienen pérdidas." (Augusto Cury)

Por lo general, cuantas más herramientas conozcas y más información tengas sobre sus ventajas y costo. Podrás tomar una mejor decisión acerca de que herramienta utilizar como solución según el reto que se presente en su organización. Bueno, vamos a entender ya el patrón de la Arquitectura Hexagonal.

Cree su aplicación para que funcione sin una UI o base de datos, a la que pueda ejecutar pruebas de regresión automatizadas, implementar cuando la base de datos no esté disponible y conectar aplicaciones sin involucrarlas. (Alistair Cockburn)

Así es como comienza el post, extraído de la documentación de la página web de Alistair Cockburn, creador del patrón de la Arquitectura Hexagonal o también conocido como el patrón de puertas y adaptadores.

Una de las razones para crear esta pauta fue principalmente delegar la infraestructura y la parte UI del proyecto, centrarse en la regla empresarial y hacerla funcional, además de no mezclarla, es decir, una regla empresarial en la base de datos o incluso en la parte UI de un proyecto.

La arquitectura hexagonal se comparte en 3 partes:

• El lado izquierdo del hexágono
• Centro del hexágono
• El lado derecho del hexágono

En este escenario, tenemos a actores que interactúan con el centro del hexágono:

• El actor principal, (El que dirige una acción)
• El actor secundario es dirigido.

Una pregunta común es la diferencia entre los actores: ¿Quiénes son los actores principales de mi solicitud? y ¿Quiénes son los actores secundarios de esta misma?

Para responder a esta pregunta, es necesario hacer otra pregunta:

"¿Quién empieza la conversación?

"Es decir, ¿quién es el responsable de iniciar el flujo, el actor que realiza una acción?

Una vez esta pregunta se responda, tendrás a los actores principales. No importa si se trata de una persona, otro sistema, un guión bash que llama a tu adaptador, si activa un disparador que llama al core business de su aplicación.. Este es el actor principal.

Entonces, el actor secundario será llevado a realizar cierta acción que el actor primario ha desencadenado. Puede estar grabando datos, registrándolos, o incluso llamando a una tercera aplicación y obteniendo una respuesta, volviendo al actor primario.

El centro del hexágono

Es donde se encuentran los modelos, dominios y reglas de negocio de su software . Es un entorno que debe estar totalmente aislado en términos de no ser afectado por acontecimientos externos, por ejemplo, la base de datos que se utilizará para el frontend.

Centro del hexágono

Es el lado del actor principal, el lado del usuario, el que lleva a cabo una acción, ya que es el lado del usuario el que realizará algunas tareas.

El lado derecho del hexágono

Es el lado del actor secundario. Este es el lado de los datos, el que se lleva a cabo ya sea para escribir los datos, leer los datos, modificar los datos y borrar los datos.

Puertos

Las puertas son la comunicación gateway entre el centro de tu hexágono con los lados izquierdo y derecho de tu hexágono, con los lados externos.

Adapters

Los adaptadores son los usuarios de las puertas. Por cada puerta que tenga su hexágono se debe crear un adaptador. Por lo tanto, tiene la libertad de modificarlo y borrarlo dinámicamente. En las puertas y adaptadores, también tenemos el concepto de puertas primarias y secundarias, y el concepto es el mismo que se utiliza con los actores.

En los actores primarios de nuestra aplicación tenemos los conductores de la acción, que utilizarán los adaptadores primarios, y esto "llamará" a las puertas primarias. Así, las puertas secundarias y los adaptadores conducirán la acción al actor secundario en el flujo continuo de la aplicación.

Inversión de Control (IoC)

En un flujo real, usando como ejemplo el simple registro de datos, tendríamos lo siguiente:

• El lado izquierdo (el conductor) entrega la información, usando un adaptador y a través de la puerta principal, al centro del hexágono (dominio).
• El centro del hexágono, entonces, recibe datos a través del puerto, luego los procesa usando una puerta secundaria y llama al lado derecho.
• El lado derecho (el conducido) llama a una base de datos para registrarlos.

Al final, tendríamos esto como el flujo del Hexágono:

Lado izquierdo -> Centro -> Lado derecho

Este escenario impacta en los conceptos de la Arquitectura Hexagonal, ya que el dominio debe estar aislado y ser el único responsable de la regla de negocio, porque en el ejemplo anterior, tendría que ser responsable de llamar a la entidad responsable de la grabación.

Ahora, surge el concepto de Inversión de Control (IoC).

La inversión de control (IO) es un patrón que aboga por utilizar instancias de una cierta clase, tratándola externamente y no dentro de la clase, es decir, delega el control de una clase a otra. Puede ser una interfaz, un componente, un servicio, etc.

En nuestro caso, invertirá precisamente en el flujo del orden, asegurándose de que, aún utilizando el ejemplo nuestra base de datos vaya a nuestro centro y no al revés, dejando nuestro dominio realmente aislado.

Al final, este sería nuestro flujo correcto:

Left side -> Center <- Ioc- Right side

Fortalezas

Fortalezas del uso de esta arquitectura:

• Solución de servicios externos independientes
• Permite aplazar algunas decisiones técnicas
• Creación y sustitución de adaptadores
• Fácil de probar la aplicación
• Tecnologías fáciles de intercambiar

Debilidades

También consideramos algunos aspectos negativos en el uso de esta arquitectura hexagonal:

• Complejidad adicional (Construcción de más capas)
• Costo de creación y mantenimiento
• No hay ninguna orientación sobre la organización del código (Directorios, capas)

Conclusión

Se toma como guía la arquitectura hexagonal, a partir de ella se crearon nuevos conceptos arquitectónicos con información más granular en la organización del código (Directorios y Capas), como ejemplos tenemos la Arquitectura Cebolla, de Jeffrey Palermo, y la Arquitectura Limpia, de Robert C. Martin (Tío Bob). Ambos se refieren al patrón creado por Alistair Cockburn.

Incluso si ya ha elegido seguir la idea de Jeffrey o del tío Bob, le recomiendo estudiar la arquitectura hexagonal para entender el concepto de aislamiento del dominio y la comunicación con sus respectivos actores. Después de eso, se dará cuenta que será más fácil entender las ideas de otros autores que crearon nuevos conceptos basados en esa idea inicial.