¿Qué es la Arquitectura Hexagonal?

La Arquitectura Hexagonal es un patrón de arquitectura que organiza una aplicación de tal modo que la lógica de negocio quede totalmente aislada de las tecnologías subyacentes que implementa la aplicación, logrando aislar los detalles técnicos y las decisiones de infraestructura detrás de interfaces bien definidas. Esto permite tener una aplicación más flexible, mantenible y resistente a los cambios, ya que la evolución tecnológica no afecta directamente al core de la aplicación.

¿Qué problema viene a resolver?

La Arquitectura Hexagonal viene a solucionar varios de los problemas clásicos de las arquitecturas modernas:

Aislamiento:

En arquitecturas como MVC, la lógica de negocio suele estar mezclada en controladores, Bases de datos, ORMs, Frameworks y APIs externas. Esto genera acoplamiento y como consecuencia hace que los cambios sean más costosos.

La arquitectura hexagonal separa de manera estricta la lógica de negocio de la infraestructura y en consecuencia genera bajo acoplamiento. 

Testing:

Cuando la lógica de negocio está mezclada con la infraestructura, testear puede resultar ser costoso. Esta arquitectura permite testear el dominio como lógica pura, sin levantar Express, bases de datos ni servicios externos.

Migraciones de tecnología:

En una arquitectura acoplada, cambiar la base de datos, el framework o un proveedor externo es costoso. Esta arquitectura te permite reemplazar adaptadores (implementaciones de una interface) sin tocar la lógica del negocio.

Organización y claridad:

Evita que Controllers tengan lógica de negocio, repositorios hagan validaciones del negocio, casos de uso dependan de ORMs u otros detalles técnicos. Resultado: Código limpio, mantenible y escalable.

 

¿Cómo funciona?

La Arquitectura hexagonal separa la lógica de negocio de todo lo que sea externo a ella y para esto define tres partes fundamentales en las que se divide la aplicación:

Dominio:

Es el núcleo del sistema que centraliza toda la lógica de negocio sin ningún detalle técnico.

Incluye: entidades, value objects, casos de uso (servicios de aplicación), reglas de negocio.

El dominio no sabe de qué framework web usa la aplicación, ni si la DB es Mongo, Postgres o archivos, ni si lo utiliza una API REST, un cron job, un evento. Las demás partes de la aplicación se comunican con el dominio solo a través de los puertos.

 

Puertos:

Los puertos son interfaces que definen cómo se comunicarse el dominio con el exterior.

Hay dos tipos:

Puertos de Entrada:

Son las interfaces de las operaciones que el exterior puede pedirle al dominio.
Ejemplo: ICreateOrderUseCase, IGetCustomerBalance.

El dominio expone sus casos de uso a través de los puertos.

 

Puertos de Salida:

Son las interfaces que el dominio utiliza para interactuar con servicios externos.

Ejemplos: IUserRepository, IPaymentGateway, ISendEmailService

El dominio no sabe quién implementa estos puertos. Solo sabe qué métodos existen.

Los puertos son el contrato entre el dominio y la infraestructura.

 

Adaptadores:

Los adaptadores son las implementaciones concretas de los puertos y conectan la aplicación con el mundo real.

Hay dos tipos:

Adaptadores de Entrada:

Son las “entradas” a la aplicación.

Ejemplo: controllers REST, eventos, jobs croneados, webSockets, etc.

Convierte la entrada en una llamada a un puerto de entrada.

Adaptadores de Salida:

Son las “salidas” hacia tecnologías externas.

Ejemplo: repositorios que usan bases de datos, clientes HTTP para APIs externas, Interfaces a colas de mensajería, servicios de email, SMS, etc.

Cada adaptador implementa un puerto de salida.

 

La esencia de esta separación es que, al realizar cambios como por ejemplo de una BD relacional a una no relacional, solo tenemos que cambiar el adaptador, el dominio ni se entera.

Conclución:
Utilizar arquitectura hexagonal nos permite construir aplicaciones escalables y con bajo costo de cambio. Al igual que en un auto podés cambiar una rueda pinchada sin necesidad de tocar el motor, en una aplicación con Arquitectura Hexagonal podés reemplazar o modificar una parte sin afectar el núcleo del sistema. Cada pieza está desacoplada y cumple un rol específico, lo que hace que la evolución del software sea mucho más sencilla y segura.