Arquitectura Hexagonal
Este documento busca presentar algunas definiciones que son importantes desde la experiencia y adopción de este tipo de arquitectura en capas. Y a su vez, se espera que sea una guía para empezar a adoptar arquitecturas limpias en el desarrollo de software.
Recordar, que la información que se presenta, busca ser lo mas pragmática posible, de tal manera que lo apliques en el stack de desarrollo preferente.
Es importante, en valor que nos aporta los principios SOLID para poder adoptar las buenas practicas como es la Arquitectura Hexagonal, sobre todo la inversión de dependencia.
¿Qué es la Arquitectura hexagonal?
Desde muchas fuentes, coincidimos que la palabra Hexagonal limita o confunde su correcta adopción, así que vamos hablar como también es conocida “Ports&Adapters”, donde:
- Ports: Son interfaces que definimos en la Capa Dominio y nos desacopla de la Capa de Infraestructura. Ej: CustomerRepository
* Adapters: Se convierten en todas las posibles implementaciones de los Ports, es decir que son clases que implementan la interfaz, de acuerdo a su proveedor, así que lo puedes encontrar en la capa de infraestructura. Ej: MySqlCustomerRepository, etc.
Y ¿Porqué el Hexágono?
La forma tradicional, es hacer diseños de arquitectura con figuras de cuadros o rectángulos… ahora con la propuesta de la nueva arquitectura, se planeo en un diseño con una figura geométrica distinta, así que el siguiente candidato seria un pentágono, al diseñar arquitecturas con esta forma, la verdad no luce muy bien o mejor dicho, dibujar un pentágono no es tan fácil, como dibujar un hexágono, así que finalmente la figura elegida fue el hexágono.
Ahora hablemos de sus capas.
Capa de Aplicación
La importancia de empezar a evaluar necesidades de los usuarios, y empezar a plasmarlo en una solución de software, básicamente se traduce en la capa de aplicación.
De este modo, te permite definir el caso de uso, en adición, vas entender los datos que te va entregar el usuario.
Con estos insumos, notaras que has logrado entender y plasmar la necesidad del cliente, y te va permitir plantear los test unitarios, todo esto, sin hablar nada relacionado con la infraestructura. Es decir, aún no se tiene nada relacionado a un http, una Base de datos, una escritura de archivo, una mensajería, etc.
A vuelo de pájaro, esta capa destaca las acciones o casos de usos.
Capa de Dominio
Es una capa de gran relevancia, es allí donde se modela nuestro dominio creando nuestros puertos(contratos de infraestructura). En otras palabras, son las interfaces(Repository) que nos sirven para estar desacoplados de la capa de infraestructura. Así mismo se crearan nuestros Value Objects que modelaran parte de nuestro dominio.
Capa de Infraestructura
Esta capa es encargada de todo lo que tiene que ver con las Entradas ó Salidas de nuestros sistema(I/O). En otras palabras, es donde se crean nuestros adaptadores de infraestructura(implementaciones),como operaciones en Base de datos, Operaciones HTTP, escribir en archivos, etc.
Para poder acceder a cualquiera de estas implementaciones, se suele llegar a esta, por medio de una interfaz, la cual establecerá el limite entre nuestro dominio y la infraestructura.
Ahora Ej. Arquitectura Hexagonal
Regla de Dependencia(Regla de Oro)
Por qué “Aplicación, Dominio, Infraestructura” , Y no Ports &Adapters?
Desacoplar la lógica de negocio de las implementaciones de infraestructura, nos va permitir alta cohesión y bajo acoplamiento. Así, cuando tengamos que hacer algún cambio en la infraestructura, no se vea afectada nuestra lógica de negocio.
Si necesitamos realizar cambios en la capa de infraestructura, con la arquitectura hexagonal no representa de ningún riesgo de modificación para la Capa de Aplicación o Lógica de Negocio.
Ejemplo de Negocio: Cambios de proveedores de autenticación, cambio de Bases de datos, etc.
La Arquitectura Hexagonal, no es más que, otra convención de arquitectura, con un comportamiento simétrico a travez de todos los casos de uso.
Bonus: Y los Test?
Ya tenemos todo desacoplado en las respectivas capas, ahora los test también se nos hacen más sencillos.
Ya tenemos cierto dominio con el patrón Repository, a nivel de nuestros test realizaremos Mock de las operaciones definidas en el Repository, para que se realicen las operaciones en memoria, sin tener que interactuar realmente con la infraestructura.
Test unitarios: Capa de Aplicación y Dominio
Test de integración: Capa de Infraestructura
Test de Aceptación: Todas las capas
Conclusiones
Arquitectura Hexagonal(Hexagonal Architecture), no tiene nada que ver con Arquitectura en Capas(Layered Architecture), por que el dominio es quien conoce la infraestructura en la Arquitectura en Capas. Es decir, todo lo contrario a lo que hemos venido hablando de hexagonal.
Ejemplos de Arquitectura en Capas donde el dominio esta acoplado a la infraestructura, como: ActiveRecord, Hibernate.
