La Arquitectura Hexagonal, también conocida como “Arquitectura de Puertos y Adaptadoresâ€, es un modelo para crear sistemas desacoplados y fáciles de mantener, basándose en la separaración de las responsabilidades del núcleo del negocio, de los detalles técnicos (se considera detalles a todo lo externo al negocio… como la base de datos, la interfaz de usuario, servicios web).
Fue propuesta por Alistair Cockburn en 2005, como un conjunto de ideas, patrones, una filosofía de diseño de software, y poco a poco fue ganando popularidad (hoy es una arquitectura muy usada en microservicios).
# ¿Por qué Hexagonal?
El término “hexagonal†tiene que ver con la idea de que la lógica de negocio está en el centro de la aplicación y que cada lado representa un puerto de entrada/salida de la aplicación, y una forma poligonal expresa mejor que un círculo este principio.
Estos puertos son el punto de entrada o salida de detalles externos, mecanismos que interactúan con nuestro sistema, son las abstracciones (interfaces) de comunicación.
Cada uno de estos puertos tiene asignado uno o varios adaptadores, las implementaciones concretas, por ej. las querys para insertar en una base de datos MySQL. Esto es más flexible que un modelo en capas tradicional, donde la interacción suele ser lineal y en un solo sentido.
# Motivación
Una de los grandes problemas de los sistemas de software es la inclusión de lógica de negocio en el código fuente de la interfaz de usuario, lo que origina que:
-
El sistema no se puede probar con suites de pruebas automatizadas, porque parte de la lógica depende de detalles visuales.
-
Resulta imposible pasar de un uso humano a una ejecución automatizada.
-
Al cambiar tecnologías (UI o DB), hay que volver a codificar gran parte del sistema.
La arquitectura hexagonal propone hacer foco en estos temas, facilitando el desarrollo, el mantenimiento y las pruebas. Que sea independiente de dispositivos y bases de datos, permitiendo adaptar nuevos detalles externos sin recodificar casos de uso.
# Los 3 Conceptos Clave
Dominio
El corazón de la aplicación. Contiene la lógica de negocio pura, independiente de cualquier tecnología externa.
Puertos
Abstracciones (interfaces) que definen cómo el mundo exterior interactúa con el dominio (Primarios) y viceversa (Secundarios).
Adaptadores
Componentes que implementan los puertos, traduciendo entre el dominio y las tecnologías externas (API, DB, etc.).
# Gráficamente
Vemos una aplicación con dos puertos activos y varios adaptadores. La aplicación puede ser dirigida de igual manera por pruebas automatizadas, un ser humano o una API remota. En el lado de los datos, puede configurarse para usar DBs reales o mocks de sustitución sin cambiar el núcleo.
# Implementación
A la hora de implementarla, la estructura se organiza lógicamente para separar los contratos de las implementaciones:
-
dominio/: Entidades del sistema (Pedido, Articulo).
-
aplicacion/: Lógica de la aplicación y orquestación (ServicioPedido).
-
puerto/: Interfaces de comunicación (RepositorioPedidos).
-
adaptadores/: Implementaciones concretas (RepositorioPedidosMemoria).
# Código Java
Dominio: Pedido.java
package restaurante.dominio;
public class Pedido {
private Articulo articulo;
private int cantidad;
public Pedido(Articulo articulo, int cantidad) {
this.articulo = articulo;
this.cantidad = cantidad;
}
}
Puerto: RepositorioPedidos.java
package restaurante.puerto;
import restaurante.dominio.Pedido;
public interface RepositorioPedidos {
void guardarPedido(Pedido pedido);
}
Adaptador: RepositorioPedidosMemoria.java
package restaurante.adaptadores;
import restaurante.dominio.Pedido;
import restaurante.puerto.RepositorioPedidos;
public class RepositorioPedidosMemoria implements RepositorioPedidos {
@Override
public void guardarPedido(Pedido pedido) {
// Implementación de guardar en memoria
}
}
# Consideraciones
-
warning
Complejidad Adicional
Agrega más clases e interfaces comparado con modelos simples.
-
warning
Curva de Aprendizaje
Requiere entender bien la separación entre puertos y adaptadores.
# Beneficios Reales
-
verified
Adaptabilidad
Fácil reemplazo de adaptadores (UI, DB) sin tocar el negocio.
-
verified
Testeabilidad
Permite probar la lógica de negocio de forma aislada y pura.
# Visión de Amazon
Amazon propone una estructura clara para sistemas escalables, puedes consultar su guía completa aquí: Amazon Arquitectura Hexagonal.
# En Resumen
La arquitectura hexagonal mantiene un enfoque claro en cuanto a la separación de la lógica de negocio y los detalles de implementación, lo que lleva a sistemas más limpios, mantenibles y evolutivos.