La arquitectura hexagonal es una propuesta donde se busca organizar un sistema a partir de un elemento central llamado “aplicación”. Proporciona una estructura modular que promueve la separación de preocupaciones, la flexibilidad y la testeabilidad.
Esta aplicación contiene las reglas de negocio de nuestra aplicación y la vamos a representar como un hexágono.
Esas reglas de negocio, también conocidas como dominio o lógica de negocio, son la razón de ser del sistema. Si deseas profundizar en lógica de negocio, te recomiendo este video en mi canal de YouTube.
Quiero compartirte 3 beneficios de utilizar esta arquitectura.
Dado que se está separando claramente la aplicación de otras dependencias (como un framework web), esto facilita cambiar las dependencias sin que sea necesario afectar la lógica de negocio. Por otro lado, podemos hacer cambios en nuestra lógica de negocio sin preocuparnos por las dependencias que tiene.
Aislar las dependencias no solo facilita las modificaciones al código, sino que también facilita probarlo. En aplicaciones donde el código se encuentra totalmente mezclado (por ejemplo, un método tiene lógica, se conecta a una API y guarda en la base de datos), probar una parte específica se vuelve muy difícil. Esta arquitectura facilita el uso de objetos de prueba (como los mocks y los stubs), que permiten probar más fácil la aplicación sin tener que preocuparnos por las dependencias.
Dado que la aplicación no depende de una implementación específica, se facilita mucho cambiarla. Por ejemplo, si tu sistema se conecta a otro sistema mediante REST, pero el día de mañana liberan una versión que utiliza GraphQL, lo único que necesitas hacer es escribir un nuevo adaptador, ya que el puerto y la aplicación no conocen de esos detalles.
Una de las formas más comunes o tradicionales en que suele estructurar una aplicación es organizarla en 3 capas:
Cada una de esas capas tiene una responsabilidad bien definida. La presentación interactúa con el usuario final. El dominio contiene la lógica de negocio. El acceso a datos tiene el conocimiento para guardar y consultar información.
Este enfoque tiene una limitación importante: la dependencia del dominio con el acceso a datos. Esto puede ser un inconveniente cuando tenemos un dominio complejo, que puede interactuar con múltiples fuentes de datos y sistemas, pero además se necesita que sea fácil de modificar.
Ante estos inconvenientes (y algunos más) surgen las arquitecturas limpias. Una de ellas es la arquitectura hexagonal.
💡 Aprende más sobre Arquitecturas Limpias y el Patrón Repository
Los componentes de la arquitectura hexagonal son:
Ya hemos mencionado el elemento central de la arquitectura hexagonal: la aplicación. Ahora hablemos de los puertos y adaptadores.
Los puertos permiten acceder a la lógica de negocio. Sobre cada puerto, se implementan distintos adaptadores. Estos adaptadores hacen la conversión desde los elementos externos (por ejemplo, una pantalla) hacia lo que entienden los puertos.
Gracias a estos dos elementos también conocemos a la Arquitectura Hexagonal como arquitectura de puertos y adaptadores.
Aterricemos estos conceptos con un ejemplo. Supongamos que tenemos una tienda en línea, la cual ofrece una funcionalidad para gestionar clientes. En una arquitectura hexagonal, podríamos representarlo de la siguiente manera:
El sistema cuenta con dos puertos: API de clientes y API de BD (Base de datos).
El puerto del API de clientes es utilizado por dos adaptadores: una interfaz gráfica y un servicio REST. Cada uno de estos adaptadores conoce los detalles específicos de acuerdo a sus responsabilidades.
Por ejemplo, el adaptador de REST “entiende” de elementos específicos de HTTP, tales como encabezados, métodos, JSON, entre otros. En algún punto de su ejecución el adaptador llamará al puerto para hacer uso de la lógica de negocio.
Por otro lado, la API de BD permite a la aplicación desconocer los detalles puntuales de la base de datos que está utilizando. Esto es crucial para que la aplicación sea más fácil de mantener. Si en algún momento cambia la forma como se interactúa con la base de datos, esto no debería afectar la aplicación.
En el diagrama podemos ver como la API de BD no solo se emplea para acceder datos en MySQL, sino que también se utiliza para las pruebas. Esto lo vemos reflejado en los mocks, que son objetos para facilitar pruebas.
Un aspecto crucial a respetar en una arquitectura hexagonal es la regla de la dependencia.
Esta regla indica que las dependencias siempre van desde fuera hacia dentro y nunca al revés. Esto significa que la aplicación no debe tener ninguna referencia hacia elementos fuera de su hexágono. Por ejemplo:
Lo que te he mostrado en este artículo es un abrebocas muy pequeño de las posibilidades de la arquitectura hexagonal. Para seguir profundizando, y llevarla a código, te recomiendo mi nuevo Curso de Arquitecturas Limpias, donde estudiamos a fondo la arquitectura hexagonal, y otras similares. Profundizamos a detalle todo lo que necesitas saber para implementar estas arquitecturas en tus proyectos.
¡Nos vemos en el curso!
Muy buen post introductorio.
Me apunto el curso para tomarlo.
Muy buena explicación!
Muy interesante articulo. Voy a hacer el curso para aprender mas patrones de diseño.
Saludos!