07/09/2026
Hablemos de Arquitectura Hexagonal en Java. ☕
Uno de los errores más comunes al construir aplicaciones empresariales en Java/Spring Boot es atar el negocio a la infraestructura:
❌ Modelos de dominio llenos de , y anotaciones de Jackson.
❌ Lógica crítica metida en controladores o repartida en repositorios.
❌ Imposibilidad de cambiar un motor de base de datos o cliente HTTP sin reescribir la mitad del código.
La Arquitectura Hexagonal (Ports & Adapters) resuelve esto con un principio clave: El Dominio es el rey, y no debe conocer nada del mundo exterior.
¿Cómo se traduce esto en la práctica?
- Core de Dominio (Java Puro): Solo POJOs con reglas de negocio y validaciones. Sin Spring, sin JPA, sin librerías externas.
- Puertos (Contratos / Interfaces):
Inbound (Driving): Definen qué puede hacer el sistema (casos de uso como CreateOrderUseCase).
Outbound (Driven): Definen qué necesita el sistema hacia afuera (como OrderRepositoryPort).
- Adaptadores (Los detalles técnicos):
Entrada: Controllers REST, consumers de Kafka o jobs que llaman a los puertos de entrada.
Salida: Implementaciones concretas de persistencia (Spring Data JPA), llamadas HTTP o colas que implementan los puertos de salida.
- El mayor beneficio: Poder probar la lógica de negocio completa con tests unitarios ultrarrápidos (sin levantar contextos pesados de Spring ni mocks complejos de base de datos), y la flexibilidad de cambiar proveedores tecnológicos sin tocar una sola regla de negocio.
De momento estoy trabajando en una migración con esta arquitectura y es enriquecedor como se desacopla el dominio con todo lo demas, si deseas crear o migrar un sistema con gusto te apoyo! 😊
