Arquitectura Hexagonal
Hay mucha información al respecto de esto pero quiero consolidar varias fuentes en un texto claro, simple y conciso de que es la Arquitectura Hexagonal y aprovechar esto en nuestro día a día.
Esta Arquitectura deriva de las Arquitecturas limpias o Clean Architecture. Y hereda la definición:
Son una serie de capas de nuestra aplicación y sobre todo, una regla de dependencia entre estas capas.
Acá es importante resaltar que la regla de dependencia esta ilustrada con las flechas que van desde afuera hacia dentro. Esto quiere decir que la capa más externa solo puede conocer a la capa interior inmediatamente siguiente, es decir, la capa Use Case solo conoce a Entities y no al revés.
Y para qué nos sirve esto? dado que las capas de adentro no conoce a las de afuera. Podemos cambiar la externa (afuera) sin que lo interna (adentro) se entere.
Por ejemplo, podemos cambiar nuestros controladores sin que los casos de usos se vean afectados.
Otro ejemplo, queremos subir de versión en nuestro framework de turno. En esta tarea solo tocaríamos las capas externas y no nuestros casos de usos, nuestra lógica de negocio. Qué es al final lo que nos importa.
Otro ejemplo más pero un poco menos probable es que necesitemos cambiar nuestra implementación de base de datos. Desde MySql a Oracle. Solo modificaríamos la capa de infraestructura y nuevamente nuestro código de negocio no se entera 😎.
Qué es la Arquitectura Hexagonal?
Primero quiero decir que el termino usado de hexágonal lleva a muchas interpretaciones y errores. Porque se tiende a pensar que solo se puede representar o implementar solo seis puertos o seis adapters (spoiler). Perfectamente podría ser un circulo 😅.
Y como dije anteriormente esta arquitectura deriva de las limpias pero define cosas particulares.
Capas de la Arquitectura Hexagonal
Infraestructura
Código que cambia en función de decisiones externas. En esta capa vivirán las implementaciones de las interfaces que definiremos a nivel de dominio. Es decir, nos apoyaremos en el DIP de SOLID para poder desacoplarnos de las dependencias externas.
Acá van las operaciones I/O como servicios rest, comunicaciones a colas de servicios, conexiones a base de datos, etc. Todo lo externo a nuestra lógica de negocio.
Aplicación
La capa de aplicación es donde viven los casos de uso de nuestra aplicación (crear cuenta, depositar, girar, etc). Los servicios de aplicación.
Dominio
Básicamente esta capa la podemos dividir en dos conceptos:
- Cosas que están en nuestro contexto y tenemos que representar. Como entidades de nuestro dominio (Banco, Usuario, Cuenta, Pagos, Producto, etc).
- Reglas de negocio que solo van a variar por criterios propios (negocio). Es decir, que por una cambio hecho en nuestra implementación de la base de datos no tenemos porque modificar algo en nuestra capa de dominio.
Puertos y adaptadores
La Arquitectura Hexagonal también se denomina Ports and Adapters. De hecho, como opinión personal creo que este término es más acertado ya que tiene connotaciones más cercanas a lo que podríamos pensar al ver cómo queda el código, y no implica un número finito como si lo hace la palabra hexágono.
En ese sentido, podemos pensar que:
- Los puertos son las interfaces definidas en la capa de dominio para desacoplarnos de nuestra infraestructura. Ejemplo: AccountRepository
- Los adaptadores son las implementaciones posibles de esos puertos. Estas implementaciones interpretarán esos contratos definidos en la interfaz (puertos) a la lógica necesaria a ejecutar en base a un determinado proveedor. Ejemplo: MySqlAccountRepository
Flujo de un Request
Para un request de creación de una cuanta bancaria. Podemos tener como ejemplo de flujo: una solicitud que llega a la capa de infraestructura (controller) y este a su vez llama al caso de uso que está en la capa de aplicación (aplication service) y el CU llama al Dominio.
Luego para que se lleve a cabo la lógica en la base de datos y podamos crear la cuenta bancaria seguimos el flujo en la implementación del repo que es parte de la infraestructura. Donde aplicamos el DIP de SOLID.
Como quedaría esto representado en un flujo con clases:
Esto ha sido una breve introducción a la arquitectura hexagonal y como podemos llevarla a nuestros proyectos.
Seguiré escribiendo más articulos al respecto de esta arquitectura como el patron repository, servicios de infraestructura, servicios de aplicación, eventos y testing. Nos leemos!
Espero les sirva, enjoy! 😃 🥳
