🕒 5 minutos de lectura
Cuando hablamos de arquitectura de software, es fácil caer en palabras grandes, diagramas complejos y estructuras que parecen más difíciles que el propio problema que queremos resolver.
Seguro que has visto proyectos donde, antes de escribir una sola línea de código, ya existen:
- Múltiples capas,
- Decenas de interfaces,
- Carpetas que nadie sabe para qué sirven,
- Diagramas que parecen sacados de una tesis doctoral.
Y también lo contrario:
aplicaciones sencillas, bien organizadas, fáciles de entender y mantener, que no siguen ningún “patrón famoso”… pero funcionan muy bien.
Eso nos lleva a una pregunta importante:
¿Realmente necesitamos arquitecturas complejas para hacer software profesional?
En este artículo quiero explicar qué son Clean Architecture y Hexagonal Architecture, qué problema intentan resolver y, sobre todo, cuándo tiene sentido usarlas y cuándo no.
El problema real
Antes de comparar arquitecturas, hay que entender qué problema intentan solucionar.
En muchos proyectos pasa esto:
- La lógica de negocio depende directamente del framework.
- Cambiar la base de datos implica tocar medio proyecto.
- Probar el código es complicado.
- Pequeños cambios generan efectos inesperados.
En resumen:
👉 el código está demasiado acoplado.
Tanto Clean Architecture como Arquitectura Hexagonal nacen para evitar eso: proteger la lógica de negocio y aislarla del resto del sistema.
Todo lo demás gira alrededor de esa idea.
Clean Architecture: claridad conceptual y foco en el dominio
Clean Architecture propone algo bastante sencillo de entender:
Lo más importante de tu aplicación es la lógica de negocio. Todo lo demás debería adaptarse a ella, no al revés.
Imagina una cebolla:
- En el centro está el negocio (reglas, decisiones, cálculos).
- Alrededor, las capas que ayudan a ejecutar ese negocio.
- En la parte exterior, la infraestructura: frameworks, base de datos, UI.
La regla clave es esta:
👉 el centro no conoce lo que hay fuera.
Tu lógica no debería saber:
- Si usas Spring, Angular o cualquier framework,
- Si la base de datos es PostgreSQL o Mongo,
- Si el usuario entra por una API o una interfaz web.
¿Cuándo tiene sentido Clean Architecture?
- Cuando el negocio es complejo.
- Cuando el proyecto va a vivir muchos años.
- Cuando hay varias personas trabajando en el mismo código.
- Cuando quieres que los cambios sean predecibles.
¿Cuándo puede ser demasiado?
- Proyectos pequeños.
- Prototipos o pruebas de concepto.
- Cuando el equipo no está acostumbrado a este enfoque.
- Cuando se usa solo “porque es lo correcto”.
- En estos casos, puede acabar generando más código del necesario.
Hexagonal Architecture: entradas, salidas y desacoplamiento real.
Hexagonal Architecture parte de otra idea fácil de visualizar:
Tu aplicación es un núcleo que recibe información por unos lados y se comunica con el exterior por otros.
En lugar de pensar en capas, piensa en:
- entradas: API, interfaz gráfica, eventos, comandos.
- salidas: base de datos, servicios externos, colas, emails.
La aplicación no debería saber quién la llama ni a quién llama. Solo debería saber qué necesita.
Para eso se usan:
- puertos → interfaces que definen qué necesita el sistema.
- adaptadores → implementaciones concretas (API, DB, etc.).
¿Cuándo funciona muy bien Hexagonal?
- Cuando el sistema tiene muchas integraciones externas.
- Cuando cambian los canales de entrada (API, eventos, UI…).
- Cuando el testing es importante.
- Cuando quieres aislar bien la infraestructura.
¿Cuándo puede complicar de más?
- Aplicaciones simples.
- Sistemas con pocas dependencias externas.
- Equipos que no entienden bien el concepto de puertos.
Mal aplicada, acaba en muchas interfaces que no aportan valor.
La verdad incómoda: no son tan distintas
Aquí viene algo importante.
Clean Architecture y Arquitectura Hexagonal no son enemigas. De hecho, buscan exactamente lo mismo:
- Separar negocio de infraestructura.
- Reducir acoplamiento.
- Facilitar pruebas.
- Permitir cambios sin romper todo.
La diferencia está en cómo piensas el sistema:
- Clean Architecture habla más de capas y casos de uso.
- Hexagonal habla más de entradas y salidas.
En proyectos reales, muchas veces se combinan ideas de ambas. Y eso está perfectamente bien.
El mayor error: elegir arquitectura antes de entender el problema
Uno de los errores más habituales es decidir la arquitectura antes de entender el problema.
Elegir patrones porque «son profesionales», «los usa todo el mundo», «quedan bien en un diagrama», suele llevar a sobreingenieria, código dificil de mantener y frustración en el equipo… A veces la mejor arquitectura es un monolito bien estructurado, pocas capas y sentido común.
Conclusión: la arquitectura es una decisión, no una religión
Ni Clean Architecture ni Arquitectura Hexagonal son soluciones mágicas.
Son herramientas. Y como cualquier herramienta, funcionan bien cuando se usan en el contexto adecuado.
La pregunta importante no es:
“¿Qué arquitectura es mejor?”
La pregunta correcta es:
“¿Qué necesita este sistema ahora y qué podría necesitar en el futuro?”
Responder bien a eso es lo que realmente define una buena arquitectura… y a un buen profesional.
Si quieres ver ejemplos prácticos de Clean Architecture y Arquitectura Hexagonal, los he desarrollado en este artículo.