Con la llegada y crecimiento de la adopción de la Arquitectura de Microservicios, también crece la demanda por estándares arquitecturales que puedan ayudar en la creación e implementación de estos servicios. La elección de un estándar arquitectural puede ayudar mucho en esta jornada. La idea de este artículo es mostrar un poco sobre el estándar de arquitectura Hexagonal y explicar sus ventajas y algunas desventajas y cómo utilizarlo.

Recordando que no existe bala de plata y toda elección trae un costo, entonces vale resaltar que es aconsejable conocer varias herramientas, sus ventajas y costos y escoger aquella cuyo costo sea bajo cerca de las ventajas.

Estándar de Arquitectura Hexagonal

Hay una frase que escuché cierta vez en la vida, pero la traje para adentro del desarrollo de software también, y que para mí tiene sentido, que dice lo siguiente:

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

En suma, como dije anteriormente y reforzando, mientras más herramientas usted conozca, mientras más conozca sobre sus ventajas y costos, tiende a hacer una mejor elección de cuál utilizar como solución ante el desafío presentado.

Bueno, sin más demora, vamos al conocimiento del estándar de Arquitectura Hexagonal.

Cree su aplicación para funcionar sin tener ni una UI o base de datos, a la cual usted puede ejecutarle pruebas de regresión automatizada, impleméntela cuando la base de datos no está disponible y conecte aplicaciones sin involucrarlas. (Alistair Cockburn)

Así comienza el artículo, documentación en el sitio web de Alistair Cockburn, creador del estándar de Arquitectura Hexagonal o también conocido como estándar de puertos y adaptadores.

Uno de los motivos de la creación de este estándar fue principalmente delegar la parte de infraestructura y UI (User Interfaz) del proyecto y preocuparse con la regla de negocio y en dejarla funcional, además de no mezclar la regla de negocio en la base de datos ni en la parte de UI de un proyecto.

La arquitectura hexagonal se divide en 3 partes

• Centro del hexágono
• Lado izquierdo del hexágono
• Lado derecho del hexágono

En este escenario tenemos a los actores que interactuarán con el centro del hexágono, tenemos 2 actores

El actor primario conducirá una acción

El actor secundario será conducido.

Una duda común es la diferencia entre los actores, ¿quiénes son los actores primarios de mi aplicación? ¿Quiénes son sus actores secundarios?

Para responder esta pregunta es necesario hacer otra “¿Quién inicia la conversación?”, o sea, ¿quién es el gatillo que inicia el flujo, que hace una acción?

Al responder esta cuestión usted tendrá a los actores primarios, no interesa si es una persona, otro sistema, un script en bash que llama a su adapter, si él acciona un gatillo que llama al core business de su aplicación, entonces él es el actor primario.

El actor secundario será entonces conducido a ejecutar una determinada acción que el actor primario disparó, siendo grabar datos, logarlos, o incluso llamar a una tercera aplicación y obtener una respuesta, retornando al actor primario.

El centro del hexágono

Es donde se sitúan sus modelos, dominios, reglas de negocio de su software, es un ambiente que debe ser totalmente aislado en términos de no ser afectado por ocurrencias externas, ejemplo, base de datos que será utilizada, framework frontend.

Lado izquierdo del hexágono

Es el lado del actor primario, user-side, que conduce una acción, siendo este el del usuario que ejecuta alguna tarea.

Lado derecho del hexágono

Es el lado del actor secundario, data-side, que es conducido, ya sea para grabar datos, leer datos, modificar datos y borrar datos.

Puertos 

Los puertos son el puente de entrada de comunicación entre el centro de su hexágono con los lados izquierdo y derecho de su hexágono, con los lados externos.

Adapters

Los adapters son los utilizadores de los puertos, para cada puerto que su hexágono tenga un adapter debe ser creado para que usted tenga la libertad de modificarlo, borrarlo de forma dinámica.

En puertos y adapters también tenemos el concepto de puertos primarios y puertos secundarios y el concepto es el mismo explicado sobre los actores, en los actores primarios de nuestra aplicación tenemos los conductores de la acción que usarán los adapters primarios y este a su vez “golpearán” en los puertos primarios, siendo así los puertos y adapters secundarios conducirán la acción hasta el actor secundario en un flujo continuo de la aplicación.

Inversión de Control (IoC)

En un flujo real, usando como ejemplo la simple grabación de un registro, en este escenario, tendríamos lo siguiente:

• El lado izquierdo (el conductor) entrega la información, utilizando un adapter y a través del puerto primario, para el centro del hexágono (dominio).
• El centro del hexágono, a su vez, recibe a través del puerto los datos, los procesa enseguida utilizando un puerto secundario y llama al lado derecho.
• El lado derecho (el conducido) llama a una base de datos para grabarlos.

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

Lado izquierdo -> Centro -> Lado Derecho

Pero este escenario viola uno de los conceptos de la Arquitectura Hexagonal, que es que el dominio debe ser aislado y cuidar solamente de la regla de negocio, porque en el ejemplo anterior, él tendría que cuidar de llamar a quien hace la grabación.

Para eso nosotros utilizamos el concepto de inversión de control, del inglés Inversion of Control (IoC).

Inversión de control es un estándar que predica que usemos instancias de una determinada clase, tratándola externamente y no dentro de la clase en cuestión, esto significa delegar el control de una clase para otra, puede ser de interfaz, componente, servicio, etc.

En nuestro caso, justamente invertirá el orden de flujo, haciendo que, aun utilizando el ejemplo, nuestra database vaya hasta nuestro centro y no lo contrario, dejando así a nuestro dominio realmente aislado.

Al final este sería nuestro flujo correcto:

Lado izquierdo -> Centro <- Ioc- Lado Derecho

Puntos Positivos

Como puntos positivos de utilizar está arquitectura podemos listar los siguientes:

• Solución Independiente de Servicios Externos
• Es posible postergar algunas decisiones técnicas
• Creación y sustitución de adaptadores
• Facilidad en probar la aplicación.
• Facilidad en el intercambio de tecnologías.

Puntos negativos

Como no todo son flores, tenemos también algunos puntos negativos en el uso de la arquitectura hexagonal, siendo ellos:

• Complejidad Extra (construcción de más capas)
• Costo de creación y mantenimiento.
• No existe una orientación sobre organización de código (directorios, capas)

Conclusión

La arquitectura hexagonal es considerada como una guía y a partir de ella fueron siendo creados nuevos conceptos arquitecturales con informaciones más granulares en la organización de código (directorios, capas), como ejemplos tenemos la arquitectura onion (Onion Arquitecture) por Jeffrey Palermo y la arquitectura limpia (Clear Arquitecture) por Robert C. Martin (Uncle Bob), las dos hacen referencia al estándar creado por Alistair Cockburn.

Aunque usted ya opte por seguir la idea de Jeffrey o Uncle Bob, le indico el estudio de la arquitectura hexagonal para entender bien el concepto de aislamiento del dominio y de comunicación del mismo con sus respectivos actores, después de esto, usted verá que será más fácil entender las ideas de otros autores que crearon nuevos conceptos a partir de esta idea inicial.

Referencias

• Arquitectura Hexagonal con Java – https://www.udemy.com/course/arquitetura-hexagonal-com-java-1
• Hexagonal architecture – https://alistair.cockburn.us/hexagonal-architecture
• Alistair in the «Hexagone» 1/3 – https://www.youtube.com/playlist?list=PLGl1Jc8ErU1w27y8-7Gdcloy1tHO7NriL