Estás buscando un proveedor offshore y todos te prometen «código limpio». El problema es que nadie define «limpio» de la misma manera. He visto proyectos entregados por consultoras que pasaban los tests unitarios, pero cuya lógica de negocio estaba pegada a Spring Boot, a MySQL, a Kafka, hasta el punto de que un cambio de base de datos requería tres sprints. La arquitectura hexagonal es el filtro que separa a los equipos estructurados de los que improvisan.
Cuando dirijo un equipo en Vietnam en un proyecto SaaS, la primera pregunta que hago no es «¿qué framework usáis?» sino «¿cómo aislais el dominio?». La respuesta dice más que cualquier portfolio.
- 🏗️ Dominio aislado: la lógica de negocio no depende ni del framework ni de la base de datos.
- ⚡ Tests 3 veces más rápidos: el núcleo se prueba sin infraestructura, en cuestión de segundos.
- 🎯 Cambios sin roturas: reemplazar MySQL por MongoDB toca un adaptador, no la lógica de negocio.
- ✅ Criterio de selección: un proveedor que aplica este patrón entrega con menos deuda técnica.
¿Qué es la arquitectura hexagonal (y por qué ese nombre)?
La arquitectura hexagonal fue formalizada por Alistair Cockburn en 2005. Su otro nombre, «Ports & Adapters», describe mejor el mecanismo real. El término «hexagonal» proviene simplemente del esquema utilizado para representarla: un hexágono en el centro (la lógica de negocio) rodeado de conectores hacia el exterior. El propio Cockburn aclaraba que el número de lados no tiene ningún significado técnico, según la página dedicada en Wikipedia.
¿Por qué separar el dominio del resto?
El principio central cabe en una frase: las dependencias apuntan siempre hacia el núcleo, nunca al revés. Tu lógica de negocio (cálculo de un precio, validación de un pedido, orquestación de un flujo de trabajo) no sabe si se ejecuta en un controlador REST, un handler de Kafka o un test JUnit. Dice «quiero guardar este pedido» a través de un puerto (una interfaz). El adaptador (JPA, MongoDB, in-memory) se encarga de la implementación concreta.
Esta inversión de dependencias, conocida como Dependency Inversion Principle (la D de SOLID), crea una frontera nítida. Por un lado, las reglas de negocio estables. Por el otro, la infraestructura que cambia según las necesidades, las restricciones de coste o las decisiones del cliente.
El resultado concreto: cuando un cliente pide migrar de PostgreSQL a DynamoDB (ocurre con más frecuencia de lo que se cree en proyectos SaaS de fuerte crecimiento), el equipo reemplaza un adaptador. No el servicio de negocio. No los tests del dominio. No los casos de uso.
¿Cómo funcionan los puertos y los adaptadores?
Los puertos de entrada (input ports) definen lo que la aplicación sabe hacer: crear un pedido, cancelar un pago, generar una factura. Son interfaces que exponen los casos de uso del negocio.
Los adaptadores de entrada traducen las peticiones externas hacia esos puertos. Un controlador REST, un consumer de Kafka, un endpoint gRPC: todos llaman al mismo puerto. El dominio no ve ninguna diferencia.
En el lado de salida, los puertos de salida (output ports) declaran lo que la aplicación necesita: persistir datos, enviar un correo, publicar un evento. Los adaptadores de salida implementan esas interfaces: un repositorio JPA, un cliente SMTP, un producer de Kafka.
El dominio solo conoce abstracciones. Los detalles técnicos son intercambiables. Eso es lo que hace que la arquitectura sea framework-agnostic, una ventaja considerable cuando trabajas con un equipo offshore estructurado.
Hexagonal vs capas vs Clean Architecture: las diferencias reales
La mayoría de los artículos sobre el tema listan «ventajas» genéricas. La realidad sobre el terreno es más interesante, porque las tres arquitecturas (capas clásicas, hexagonal, Clean Architecture) parten del mismo diagnóstico pero divergen en la ejecución.
¿Cuáles son las ventajas concretas frente a la arquitectura en capas?
La arquitectura en capas (Controller → Service → Repository) que todo desarrollador Spring Boot aprende primero tiene un defecto estructural: las dependencias descienden, y la lógica de negocio acaba dependiendo de la infraestructura. Tu servicio importa anotaciones JPA, tu entidad de negocio hereda de una clase Spring, tus tests unitarios necesitan una base de datos para ejecutarse.
Según la guía de OCTO Technology sobre el tema, la arquitectura hexagonal invierte ese flujo: el dominio no depende de nada, es el resto quien depende de él. Los tests del núcleo se ejecutan en milisegundos, sin Docker, sin base de datos, sin mocks complejos.
En los proyectos que dirijo, esa diferencia se traduce en un ratio medible: los tests de integración sobre el adaptador JPA corren en 8 a 12 segundos, los tests del dominio en menos de 500 ms. Cuando tu pipeline de CI pasa de 4 minutos a 45 segundos en la parte de negocio, el equipo sube código con más frecuencia y más confianza.
¿En qué se diferencia la hexagonal de la Clean Architecture y del DDD?
La Clean Architecture de Uncle Bob (Robert C. Martin) y la arquitectura hexagonal convergen en un punto: aislar el negocio en el centro. La diferencia está en el nivel de prescripción. La Clean Architecture impone cuatro capas concéntricas (Entities, Use Cases, Interface Adapters, Frameworks & Drivers) con reglas estrictas de traversía. La hexagonal es más sencilla: dos zonas (interior/exterior) conectadas por puertos.
El Domain-Driven Design (DDD), por su parte, no es una arquitectura. Es un método de modelado del negocio (agregados, value objects, bounded contexts) que se combina muy bien con la hexagonal. Como señala Yield Studio en su guía, ambos conceptos se refuerzan mutuamente sin estar necesariamente vinculados.
En la práctica, recomiendo empezar por la hexagonal pura (ports + adapters) y añadir los patrones DDD (agregados, repositorios tipados) solo cuando la complejidad del negocio lo justifique. En un CRUD con 5 entidades, DDD es sobreingeniería. En un motor de precios con 20 reglas de negocio, es indispensable.
| Criterio | Arquitectura en capas | Arquitectura hexagonal | Clean Architecture |
|---|---|---|---|
| Aislamiento del dominio | Débil (anotaciones del framework en el servicio) | Fuerte (puertos y adaptadores) | Muy fuerte (4 capas prescritas) |
| Testabilidad del núcleo | Tests lentos (requiere base de datos) | Tests rápidos (adaptadores in-memory) | Tests rápidos (mismo principio) |
| Curva de aprendizaje | 1 día | 1 a 2 semanas | 2 a 4 semanas |
| Adecuada para un CRUD simple | Sí | A menudo excesiva | Excesiva |
| Adecuada para un SaaS complejo | Arriesgada a largo plazo | Sí | Sí |
FUENTE: síntesis de campo GoLive Software · ACT. 06/2026
¿Cómo implementar la arquitectura hexagonal en la práctica?
La teoría es atractiva. La implementación es donde la mayoría de los equipos se pierden. Aquí están los puntos concretos que marcan la diferencia entre una arquitectura hexagonal en una presentación y una arquitectura hexagonal en producción.
¿Qué estructura de paquetes adoptar?
La estructura de paquetes más habitual separa tres carpetas raíz: domain/, application/, infrastructure/. La carpeta domain contiene las entidades de negocio, los value objects y los puertos (interfaces). La carpeta application contiene los servicios que orquestan los casos de uso. La carpeta infrastructure contiene los adaptadores (controladores REST, repositorios JPA, clientes HTTP).
La regla de oro: ningún import de infrastructure en domain o application. Si tu IDE muestra un import de org.springframework en el paquete domain, la arquitectura está rota. Según Numendo en su guía práctica, esta disciplina de dependencias es lo único que realmente importa.
¿Cómo gestionar los tests con esta arquitectura?
Los tests se dividen de forma natural en dos familias. Los tests del dominio utilizan adaptadores in-memory (un simple HashMap que implementa el puerto de persistencia). Cubren toda la lógica de negocio, son ultrarrápidos y no requieren ninguna infraestructura.
Los tests de integración verifican que los adaptadores concretos funcionan: el repositorio JPA persiste correctamente en base de datos, el cliente HTTP llama al endpoint correcto, el producer de Kafka publica en el topic adecuado. Estos tests son más lentos, pero su alcance está limitado.
En un proyecto reciente entregado por nuestro equipo en Vietnam para un SaaS de gestión logística, esta separación produjo un resultado que rara vez observo en otros proveedores: 92 % de cobertura sobre el dominio, ejecutada en 3 segundos. Los tests de integración corrían en 25 segundos con Testcontainers. El pipeline completo terminaba en menos de 2 minutos.
No es un detalle menor. Un pipeline lento empuja a los desarrolladores a saltarse los tests o a publicar menos. Un pipeline rápido crea un círculo virtuoso de calidad. Es un argumento que desarrollo cuando evalúo los criterios de elección entre agencia y SSII: la velocidad del bucle de retroalimentación técnica es un indicador de madurez invisible en los presupuestos.
¿Hay que aplicar la hexagonal en todos los proyectos?
No. Y es un punto que muchos artículos eluden. Para una aplicación CRUD simple (un back-office de administración con 5 pantallas), la arquitectura en capas clásica es más rápida de implementar y perfectamente suficiente. La hexagonal cobra sentido cuando la lógica de negocio es compleja, cuando se anticipan cambios de infraestructura o cuando varios equipos trabajan sobre el mismo dominio.
Según un estudio de Gartner de 2024, el 64 % de los proyectos de software con más de 18 meses de desarrollo sufren al menos un cambio importante de infraestructura (migración a la nube, cambio de base de datos, sustitución de un servicio externo). En ese tipo de proyecto, la hexagonal amortiza su inversión inicial desde el primer pivote técnico.
«La calidad viene de la arquitectura, de las decisiones técnicas, de los tests y del rigor en la ejecución, no del número de desarrolladores en el proyecto.»
Vincent Roye, junio de 2026
¿Cómo verificar que un proveedor domina la arquitectura hexagonal?
Vas a firmar con una consultora o una agencia offshore, y el comercial te jura que el equipo «hace hexagonal». Aquí están las cinco preguntas que separan a los verdaderos practicantes de los vendedores de presentaciones.
¿Qué preguntas hacer antes de firmar?
Pregunta 1: «Muéstrame un grafo de imports de tu último proyecto.» Si el paquete domain importa Spring, Hibernate o cualquier framework, la respuesta es clara. Un proveedor serio puede generar ese grafo en 5 minutos con una herramienta como ArchUnit o jdeps.
Pregunta 2: «¿Cuánto tardan en ejecutarse vuestros tests del dominio?» Respuesta esperada: pocos segundos. Si la respuesta es «necesitamos Docker para lanzar los tests», los adaptadores están mezclados con el negocio.
Pregunta 3: «Si mañana os pido reemplazar PostgreSQL por MongoDB, ¿qué ficheros cambian?» Respuesta esperada: únicamente los adaptadores de persistencia. Si la respuesta empieza con «refactorizamos los servicios», la arquitectura es en capas disfrazada.
Pregunta 4: «¿Dónde está la lógica de negocio en vuestra estructura de directorios?» Respuesta esperada: una carpeta domain/ (o core/, hexagon/) sin ninguna dependencia hacia la infraestructura. Si el proveedor te muestra servicios Spring anotados con @Service que contienen las reglas de cálculo, es una señal de alarma.
Pregunta 5: «¿Vuestras entidades de dominio son las mismas que vuestras entidades JPA?» Respuesta esperada: no. El modelo de dominio y el modelo de persistencia deben ser distintos. Usar la misma clase para ambos crea un acoplamiento invisible que explota al primer cambio de esquema.
Estas cinco preguntas toman 15 minutos en una llamada técnica. Te ahorran meses de deuda técnica. Es una inversión que recomiendo sistemáticamente, al igual que un audit técnico del código existente.
Mi veredicto: lo que aplico en GoLive Software
Aplico la arquitectura hexagonal en cada proyecto SaaS que entrega mi equipo en Vietnam, salvo en los back-offices CRUD puros donde sería sobreingeniería. No es una elección teórica: es una elección económica.
En nuestros proyectos, el patrón Ports & Adapters combinado con desarrolladores senior vietnamitas y herramientas de IA como Claude Code produce un resultado concreto. El dominio es testable en aislamiento, los adaptadores son intercambiables, y cuando un cliente cambia de opinión sobre su infraestructura (y siempre cambia de opinión), el equipo pivota en días, no en semanas.
Creo que la verdadera diferencia entre un proveedor offshore que entrega calidad y otro que acumula deuda técnica reside en estas decisiones de arquitectura. No en el framework. No en el lenguaje. En la disciplina de separación entre el negocio y la infraestructura. La hexagonal no es una moda: es el mínimo exigible para un proyecto que debe vivir más de 18 meses.
Si estás evaluando un proveedor, haz las cinco preguntas anteriores. Si buscas un equipo que aplique este estándar en producción, estima tu proyecto con GoLive Software.
Preguntas frecuentes
¿Qué es la arquitectura hexagonal en una frase?
Un patrón de arquitectura de software que sitúa la lógica de negocio en el centro y la conecta con el mundo exterior (bases de datos, APIs, interfaces) a través de puertos (interfaces) y adaptadores (implementaciones). Inventada por Alistair Cockburn en 2005, también recibe el nombre de «Ports & Adapters». Su objetivo: hacer que el núcleo de la aplicación sea totalmente independiente de la tecnología utilizada.
¿Es la arquitectura hexagonal adecuada para un proyecto pequeño?
Para un CRUD simple con poca lógica de negocio, la arquitectura en capas clásica sigue siendo más rápida de implementar. La hexagonal cobra todo su sentido cuando la lógica de negocio es rica (reglas de cálculo, flujos de trabajo, validaciones cruzadas) o cuando se anticipan cambios de infraestructura. El coste inicial extra se amortiza desde el primer pivote técnico.
¿Cuál es la diferencia entre arquitectura hexagonal y Clean Architecture?
Ambas aíslan el dominio en el centro. La Clean Architecture (Robert C. Martin) prescribe cuatro capas concéntricas con reglas estrictas de traversía. La hexagonal es más pragmática: dos zonas (interior/exterior) conectadas por puertos y adaptadores. En la práctica, los equipos suelen combinar ambos enfoques según la complejidad del proyecto.
¿Cómo probar una aplicación con arquitectura hexagonal?
Los tests del dominio utilizan adaptadores in-memory (un simple HashMap como repositorio falso) y se ejecutan en pocos segundos, sin Docker ni base de datos. Los tests de integración verifican los adaptadores concretos (JPA, Kafka, HTTP) con herramientas como Testcontainers. Esta separación produce un pipeline de CI rápido y una cobertura de negocio elevada.
¿Cómo saber si mi proveedor aplica realmente la arquitectura hexagonal?
Pide el grafo de imports del paquete domain: no debe aparecer ningún import de framework. Pregunta el tiempo de ejecución de los tests del dominio (esperado: pocos segundos). Pregunta qué ficheros cambiarían si se reemplazara la base de datos (esperado: únicamente los adaptadores). Estas tres comprobaciones toman 15 minutos y revelan el nivel real del equipo.
Fuentes
- Architettura esagonale spiegata in 10 minuti , codippa
- What is Hexagonal Architecture? , 4SoftwareDevelopers
- Hexagonal Architecture: Make your code independent , Del Código a la Arquitectura
- Hexagonal vs Clean vs Onion Architecture... It Doesn't Matter , CodeOpinion
- Architecture hexagonale , fr.wikipedia.org
- Architecture Hexagonale : trois principes et un exemple d'implémentation , blog.octo.com
- Le Guide Ultime pour Maîtriser l'Architecture Hexagonale , scalastic.io
- L'Architecture Hexagonale : principes, avantages et implémentation , numendo.com
- Architecture Hexagonale : Guide Complet , yieldstudio.fr
