CLEAN ARCHITECTURE VS HEXAGONAL: ¿SON LO MISMO O SOLO SE PARECEN?

La Arquitectura Hexagonal fue propuesta por Alistair Cockburn alrededor de 2005. Su motivación era concreta: evitar que la lógica de negocio quedara atrapada en los detalles de infraestructura (base de datos, UI, protocolos). Para eso introdujo el modelo de Puertos y Adaptadores: el dominio expone interfaces (puertos) y el mundo exterior las implementa (adaptadores).

La Clean Architecture fue formalizada por Robert C. Martin (Uncle Bob) en 2012, sintetizando ideas de la arquitectura hexagonal, Onion Architecture y otros patrones. Su aportación es una estructura más explícita en capas concéntricas con una regla central: la Regla de Dependencia — las dependencias solo pueden apuntar hacia adentro, nunca hacia afuera.

Clean Architecture no inventó la separación de preocupaciones; la formalizó con nombres, capas y una regla de oro que cualquier equipo puede memorizar.

En esencia, ambas responden a la misma pregunta: ¿cómo construyo software donde la lógica de negocio no dependa de la tecnología? Pero lo responden con vocabularios y estructuras distintos.

Arquitectura Hexagonal: Puertos y Adaptadores

El diagrama hexagonal tiene una metáfora simple: el núcleo de la aplicación es el hexágono. Cada lado es una puerta de entrada/salida al mundo exterior. Esas puertas se llaman puertos. Las implementaciones concretas que se conectan a esas puertas son los adaptadores.

Dos tipos de puertos

• Driving Ports (puertos de entrada): los que el mundo exterior usa para hablar con la aplicación. Un controlador REST, un job de cron, una CLI — todos son adaptadores que llaman a puertos de entrada.
• Driven Ports (puertos de salida): los que la aplicación usa para hablar con el mundo exterior. Una interfaz de repositorio, un servicio de email, un bus de mensajes — el dominio los define, la infraestructura los implementa.

Clean Architecture: Capas concéntricas y la Regla de Dependencia

Clean Architecture organiza el software en anillos concéntricos. Cada anillo representa un nivel de abstracción. La regla es simple y absoluta: el código fuente solo puede depender de los anillos más internos. Nunca al revés.

Los cuatro anillos

1. Entities (Entidades): lógica de negocio de más alto nivel, agnóstica a la aplicación.
2. Use Cases (Casos de uso): lógica específica de la aplicación, orquesta las entidades.
3. Interface Adapters: convierte datos entre el formato de los casos de uso y el formato del mundo exterior.
4. Frameworks & Drivers: bases de datos, frameworks web, UI — los detalles más volátiles

Las diferencias que realmente importan

Visualmente ambas arquitecturas se parecen: hay un núcleo protegido y hay cosas externas que no deben contaminar ese núcleo. La confusión es natural. Pero hay diferencias concretas:

Estructura real de proyecto combinando ambas

En la práctica, la mayoría de los proyectos bien diseñados en .NET combinan las dos. Clean Architecture da la estructura en capas; Hexagonal aporta el lenguaje de puertos y adaptadores para las interfaces con el exterior.

Árbol de solución .NET 10

// MiApp.sln — Estructura de carpetas y proyectos

MiApp.sln

src/

  MiApp.Domain/               ← Entities (anillo más interno)
    Entities/
      Order.cs
    ValueObjects/

  MiApp.Application/           ← Use Cases + definición de Puertos
    UseCases/
      PlaceOrderUseCase.cs
    Ports/                     ← AQUÍ están los puertos hex.
      IOrderRepository.cs
      IEventBus.cs

  MiApp.Infrastructure/        ← Adaptadores de salida (Driven)
    Adapters/
      SqlOrderRepository.cs
      RabbitMqEventBus.cs
    Persistence/
      AppDbContext.cs

  MiApp.WebApi/               ← Adaptadores entrada (Driving) + Framework
    Controllers/
      OrdersController.cs
    Program.cs

tests/
  MiApp.Domain.Tests/
  MiApp.Application.Tests/     ← Tests sin infraestructura real
  MiApp.Integration.Tests/

OBSERVA EL FLUJO DE DEPENDENCIAS

WebApi → Application → Domain. Infrastructure → Application (implementa sus interfaces) → Domain. Nunca hay una flecha apuntando hacia afuera del centro. Eso es Clean Architecture. Los puertos son las interfaces definidas en Application/Ports/. Eso es Hexagonal. Ambos a la vez.

¿Cuándo elegir cada enfoque?

La respuesta honesta: en proyectos serios usarás ambos. Pero el énfasis varía según el contexto:

Usa el vocabulario Hexagonal cuando…

…el equipo necesita enfocarse en los puntos de integración. El lenguaje de puertos y adaptadores es poderoso para diseñar y documentar cómo el sistema se comunica con el mundo exterior. Es especialmente útil cuando hay muchos canales de entrada (REST, gRPC, workers, CLI) o muchos sistemas externos (varias bases de datos, servicios de terceros, colas).

Usa el vocabulario Clean Architecture cuando…

…el equipo necesita claridad sobre las responsabilidades de cada capa. Cuando hay ambigüedad sobre dónde vive cierta lógica, el modelo de anillos con la Regla de Dependencia resuelve la discusión de forma objetiva.

CONCLUSIÓN

Clean Architecture y Hexagonal Architecture son aliadas naturales, no competidoras. Hexagonal define cómo el sistema habla con el exterior (puertos y adaptadores). Clean Architecture define cómo se organiza internamente el sistema (capas con dependencias unidireccionales).

La combinación es especialmente potente: las interfaces son los puertos, la inyección de dependencias es el mecanismo de conexión, y los proyectos separados enforzan la regla de dependencia de forma natural — si un proyecto de dominio intenta referenciar infraestructura, el compilador te detendrá.

El verdadero criterio de éxito no es qué arquitectura elegiste, sino si en seis meses puedes cambiar tu base de datos, agregar un nuevo canal de entrada o probar la lógica de negocio en completo aislamiento. Si la respuesta es sí, lo estás haciendo bien.