Primero de todo, olvidaros del hexágono, no significa nada, simplemente es una figura bonita y fácil de recordar que le gustó a Alistair Cockburn. Alistair publicó un artículo en 2005 donde describía que la intención de la Arquitectura Hexagonal era la de permitir que una aplicación sea usada de la misma forma por usuarios, programas, pruebas automatizadas y scripts, y que pudiera ser tanto desarrollada como probada de forma aislada de sus eventuales dispositivos y bases de datos en tiempo de ejecución.
Es una de las llamadas Arquitecturas Limpias o Clean Arquitectures. a diferencia de la Layered Arquitecture en el núcleo es la base de datos, en la Arquitecture Hexagonal el centro es el dominio y la base de datos solo es un «detallito» irrelevante, incluso sustituible (el diseño permitiría poder cambiar de un MongoDB a un MySql de forma relativamente sencilla).
En la arquitectura hexagonal hay tres capas principales:
- Infraestructura: que es todo lo que implique grabar o leer del hardware o cosas externas, bases de datos, apis, controladores, ficheros, etc. Contiene los Servicios de Infraestructura.
- Aplicación: La lógica de negocio, casos de uso, etc. Contiene los Servicios de Aplicación.
- Dominio: La definición de conceptos del negocio, entidades de negocio. Contiene los Servicios de Dominio.
Lo más importante las dependencias de código van siempre de Infraestructura a Aplicación y de esta a Dominio.
Si hay código/servicios que necesitamos reutilizar en el código/servicios de la aplicación, esto se crea como servicios de dominio.
Los servicios de dominio no hace falta crear interface ni inyectarlo por qué ya son de nuestro dominio.
Es importante destacar que los servicios de dominio en ningún caso publicarán los eventos de dominio que se puedan producir ni gestinonarán transacciones. Eso se lo dejamos al Application Service que nos invoca para evitar duplicidades ya que es realmente él quién establece la “atomicidad” del caso de uso.
Videocurso de Arquitectura Hexagonal
[WIP]