🍐🍎 Arquitectura Hexagonal explicada con peras y manzanas

Introducción

Imagina que tienes una aplicación que cocina peras y manzanas. Tienes la receta (la lógica de negocio) y diferentes formas de cocinarla: en horno, en microondas, o incluso en una app móvil. Pero… ¿qué pasa si cambias la forma de cocinar? ¿Tendrías que cambiar toda la receta? La arquitectura hexagonal (también llamada Ports and Adapters) nació para resolver exactamente eso.

1. El problema de las capas tradicionales

En las arquitecturas tradicionales (por ejemplo, MVC clásico), la aplicación suele estar fuertemente acoplada a frameworks, bases de datos o controladores HTTP. Por ejemplo: Si cambias tu base de datos de MySQL a MongoDB, debes modificar código en varias partes. Si agregas una nueva API REST o una interfaz gráfica, debes tocar tu capa de negocio. Esto genera dependencias cruzadas y hace que cada cambio técnico afecte la lógica central.

2. La idea central de la arquitectura hexagonal

En una arquitectura hexagonal, la lógica de negocio vive en el centro (como el corazón de la aplicación). Todo lo que la rodea (base de datos, API, mensajería, interfaz) se conecta mediante puertos (ports) y adaptadores (adapters).

En palabras simples:

La lógica no sabe si los datos vienen de una base, de una API o de un archivo JSON. Solo espera que alguien le entregue los datos con el formato correcto. Así logramos que la receta (el negocio) no dependa del tipo de cocina (la infraestructura).

3. Ejemplo con peras y manzanas

Sin arquitectura hexagonal:

public class FrutaService { 

private final FrutaRepository repository; 

public FrutaService() { 

this.repository = new FrutaRepository(); 

// ❌ Acoplamiento directo 

} 

public double calcularTotal() { 

List<Fruta> frutas = repository.obtenerFrutas(); 

return frutas.stream().mapToDouble(Fruta::getPrecio).sum(); 

} 

}

Aquí, FrutaService depende directamente del repositorio. Si mañana cambias de base de datos, tienes que modificar el servicio.

Con arquitectura hexagonal:

public interface FrutaRepository { 

List<Fruta> obtenerFrutas(); 

}

public class FrutaService { 

private final FrutaRepository repository; 

public FrutaService(FrutaRepository repository) { 

this.repository = repository; 

} 

public double calcularTotal() { 

return repository.obtenerFrutas() .stream() .mapToDouble(Fruta::getPrecio) .sum(); 

} 

}

@Repository 

public class FrutaRepositoryDB implements FrutaRepository { 

// Lógica para obtener frutas desde una BD 

} 

public class FrutaRepositoryArchivo implements FrutaRepository { 

// Lógica para obtener frutas desde un archivo JSON 

}

Resultado: tu servicio nunca cambia, aunque cambie la fuente de datos.

4. Beneficios clave

1. 🔹 Desacoplamiento total entre negocio y tecnología.
2. 🔹 Facilidad de pruebas unitarias: puedes usar mocks sin conectarte a BD.
3. 🔹 Sustituibilidad: cambia un adaptador por otro sin tocar la lógica.
4. 🔹 Escalabilidad: agrega nuevas entradas (API, CLI, eventos) sin romper nada.

5. Conclusión

En resumen, la arquitectura hexagonal es como una cocina modular: puedes usar horno, microondas o sartén… pero la receta sigue siendo la misma. El negocio no se entera del cambio, solo sabe cocinar peras y manzanas. No se trata solo de dibujar un hexágono bonito, sino de proteger tu lógica de negocio del caos tecnológico.

¿Qué opinas?

¿Ya aplicaste este patrón en tus proyectos? Déjame tu experiencia en los comentarios o sígueme en LinkedIn para más artículos de desarrollo y arquitectura.