Arquitectura Hexagonal 101
Tags: hexagonalarchitectur, softwareengineering, architecture, cleancode
Published: 2023-09-28 13:23:34

---
title: Arquitectura Hexagonal 101
published: true
date: 2023-07-20 11:04:14 UTC
tags: hexagonalarchitectur,softwareengineering,softwarearchitecture,cleancode
canonical_url: https://medium.com/all-you-need-is-clean-code/arquitectura-hexagonal-101-e75a967db46c
---

#### Arquitecturas Limpias

#### Todo lo que necesitas saber sobre Arquitectura Hexagonal

![](https://cdn-images-1.medium.com/max/859/1*1nYwAqW8WRCDqY-PJdyskA.png)
_Esquema de arquitectura hexagonal._

> Artículo escrito originalmente para el blog [**Secture & Code**](https://secture.com/blog/arquitectura-hexagonal-101/) pulsa en el enlace para leerlo.

La Arquitectura Hexagonal, definida por [Alistair Cockburn](https://alistair.cockburn.us/hexagonal-architecture/), es una implementación de lo que llamamos una _Clean Architecture._ Tiene como principal motivación dividir nuestra aplicación en distintas capas con su propia responsabilidad. Esta separación por capas nos permite desacoplar nuestro código de las dependencias externas, como puede ser el framework o cualquier otra librería externa o _third party._

### Ports and adapters

Esta arquitectura también es ampliamente conocida como arquitectura de puertos y adaptadores, o por su nombre en inglés _ports&adapters._ Y es justo porque hace un uso intensivo del patrón “adaptador” ([_Adapter Pattern_](https://refactoring.guru/design-patterns/adapter)_)_ junto con el [principio de inversión de dependencias](https://martinfowler.com/articles/dipInTheWild.html) para obtener ese desacoplamiento del que antes hablábamos.

### ¿Por qué hexagonal?

En casi todos los textos o documentos que hablan de esta arquitectura, solemos verla representada con forma de hexágono. ¿Y por qué un hexágono y no un pentágono, o un triangulo o cualquier otro polígono? No hay una respuesta oficial al respecto, simplemente [puede ser porque el hexágono es el polígono más versátil](https://www.youtube.com/watch?v=thOifuHs6eY). Sea como sea, el número de lados no es relevante, es solo un arreglo meramente cosmético para diferenciarla del resto de arquitecturas limpias.

El hecho es que cada lado representa un puerto de entrada/salida de la aplicación, y una forma poligonal expresa mejor que un círculo este principio.

Estos puertos son el punto de entrada de cualquiera de los agentes externos o mecanismos que pueden interactuar con nuestra aplicación, bien sean estos clientes mobile o web a través del puerto para _REST API_, navegadores web a través del puerto HTTP o un sistema de colas a través del puerto para _Message Brokers._

Cada uno de estos puertos tiene, a su vez, asignado uno o varios adaptadores, en función de la diversidad que queramos soportar. Por ejemplo, el puerto para _MessageBrokers_ podría perfectamente tener adaptadores para RabbitMQ, Redis, Beanstalk o AmazonSQS, si lo que queremos es dar soporte a toda esta variedad de _providers_.

### Puntos en común con Clean Architecture

Anteriormente ya hablamos de [_Clean Architectures_](https://medium.com/secture/clean-architectures-101-95a31b79ddb4) y sus características, por lo que sería recomendable echar un vistazo al post en el que hablamos de este tema, ya que la arquitectura hexagonal es una de las implementaciones más puras que podemos encontrar de _Clean Architecture._

Tanto la distribución de las capas como su contenido o las reglas de dependencia son literalmente las mismas, pero igualmente vamos a ver sus características.

### La regla de dependencia

![](https://cdn-images-1.medium.com/max/859/1*1nYwAqW8WRCDqY-PJdyskA.png)

Cada uno de los hexágonos concéntricos representa una capa, y esta capa a su vez es una barrera que sólo puede ser atravesada por sus capas superiores. De este modo:

- **Infraestructura** puede acceder a **Aplicación** y a  **Dominio**
- **Aplicación** puede acceder a  **Dominio**
- **Dominio** sólo puede acceder a  **Dominio**

Cuanto más hacia dentro penetramos en las capas, más nos adentramos en la lógica de negocio, las reglas y las políticas. Cuanto más hacia fuera nos movemos, más cerca estamos de los agentes externos o mecanismos (clientes web o mobile, servicios externos o APIs, servicios de infraestructura como bases de datos, sistemas de colas, etc).

### Estructura de directorios y separación por capas

Vamos a ver paso por paso la estructura de directorios y cómo se distribuye el código en las distintas capas. Empezaremos por un ejemplo básico que iremos iterando.

En primer lugar, la raíz de nuestro proyecto podría ser esta:

![](https://cdn-images-1.medium.com/max/286/1*EdqbBQ1TULAKAndghQvLhg.png)
_Raíz del proyecto_

- **apps** contiene las aplicaciones, las instalaciones de los distintos frameworks que usemos. Aquí es donde vivirán nuestros controladores y nuestras rutas.
- **src** contendrá nuestro código, la lógica de negocio de nuestra aplicación.

![](https://cdn-images-1.medium.com/max/724/1*y2C5_r0wgsWtRq_yxWlpsQ.png)
_Aplicación API_

Aquí podemos observar desplegado el contenido de una aplicación. Por razones de espacio hemos obviado toda carpeta no relevante, dejando a la vista solo el _entrypoint_ (index.php) y los controladores.

![](https://cdn-images-1.medium.com/max/656/1*WonIdGlijk03B0WelOaCQg.png)
_Contexto y módulos de API_

Hemos optado por una distribución en contextos (_API_ y _Shared_). En este caso solo tenemos un contexto funcional _(API)_ y otro compartido _(Shared)_, pero podríamos tener más como, por ejemplo, _backoffice,_ que podría contener todo el código para gestionar una aplicación de gestión de contenidos.

Como se puede apreciar, cada módulo contiene su tripleta de carpetas, correspondiente cada una a una de las capas de la arquitectura.

![](https://cdn-images-1.medium.com/max/1024/1*rHF9TIklP-ViYU3UgV5pTA.png)
_Módulo Users expandido_

Entrando más en detalle, podemos ver el contenido de cada una de las carpetas que conforman la arquitectura:

- **Application.** Casos de uso. En nuestro caso aplicamos CQRs, por lo que normalmente se componen de una _query_ (acción de lectura) o un _command_ (acción de escritura), un _handler_ o manejador y, opcionalmente, un servicio que ejecute la acción. En algunos casos este servicio puede ser compartido por otros casos de uso, como por ejemplo en el caso de _GetUser_, por lo cual promocionamos el servicio de _application service_ a _domain service,_ situándolo en la carpeta _Domain_ y haciéndolo accesible al resto de casos de uso.
- **Domain.** Aquí es donde alojamos los objetos de dominio, como la entidad _User_ que representa a un usuario, o los contratos de servicios que se implementarán en infraestructura, como _UserRepository._ También consideramos objetos de dominio las excepciones, y algunos servicios compartidos como el anteriormente citado _GetUser._
- **Infrastructure.** Por último tenemos las implementaciones de los contratos de dominio. En este caso solo tenemos una implementación del repositorio y sería para el motor de bases de datos _MySQL_, pero perfectamente podríamos soportar más con solo implementar el contrato.

![](https://cdn-images-1.medium.com/max/1024/1*ehGYmBolCKq-2wGjKVTWOQ.png)
_Contexto compartido expandido_

Antes hablábamos de un _contexto compartido_, y es aquí donde van la mayor parte de los contratos y de las implementaciones de elementos que se van a utilizar por toda la aplicación, como pueden ser por ejemplo un _EventDispatcher,_ o los buses de _commands_ y _queries_. En este ejemplo, hemos implementado un bus con dos proveedores diferentes: _Symfony_ y _Tactician._ Y, además, hemos realizado dos implementaciones diferentes para cada una: la versión síncrona y la asíncrona.

Con esto pretendemos demostrar la versatilidad que nos ofrece esta arquitectura y la facilidad de cambio que nos aporta a nuestro código: podríamos cambiar la forma en que se manejan nuestros _commands_ y nuestras _queries_ con solo alterar unos parámetros de configuración del container de dependencias.

### Arquitectura hexagonal y DDD

Habremos visto mil y una veces el termino de arquitectura hexagonal junto con el de [DDD](http://dddcommunity.org/learning-ddd/what_is_ddd/), y es que sin duda son un _killer combo_ muy socorrido.

El DDD es una metodología de desarrollo que defiende el desacoplamiento por encima de todo, por lo que la Arquitectura Hexagonal encaja como un guante como núcleo central en su práctica.

### Bibliografia

- [**Hexagonal Architecture.** Alistair Cockburn (2005)](https://alistair.cockburn.us/hexagonal-architecture/)
- [**Hexagonal Architecture Draft.** Alistair Cockburn](http://wiki.c2.com/?HexagonalArchitecture)

* * *