La arquitectura hexagonal es una gran opción si queremos enfocar la arquitectura de una aplicación a Clean architectures y DDD.
Lee el post completo que te traemos a continuación y descubre los beneficios de esta arquitectura.
Conceptos previos sobre Arquitectura Hexagonal
DDD
Domain Driven Design (Diseño guiado por el dominio) es un enfoque para el desarrollo de software que provee una serie de prácticas y terminologías que aceleran el manejo de dominios complejos.
Se basa en las siguientes premisas:
Poner el foco primario del proyecto en el núcleo y la lógica de dominio Basar los diseños complejos en modelos
Fomentar la colaboración entre técnicos y expertos de negocio en los conceptos fundamentales del negocio
Fuente: Wikipedia
Clean Architecture
Clean Architecture es un conjunto de principios con el objetivo de abstraer la lógica de negocio de un determinado software de los detalles de implementación. Debido a esto, DDD se fundamenta en las Clean Architectures puesto que por definición, en estas arquitecturas se pone al dominio en el foco central de atención.
Lógica de negocio
La lógica de negocio de un determinado software son las reglas de negocio que determinan cómo la información se puede crear o modelar, sus restricciones y validaciones, etc.
En el caso de una tienda virtual, sus reglas de negocio definirán los procesos de registro de clientes, búsqueda de productos, compras, etc.
Detalles de implementación
Bases de datos
Sistemas de ficheros
API de comunicación con los clientes
Mensajería externa (SMS, E-mails, etc)
APIs externas
Definición de Arquitectura Hexagonal
La Arquitectura Hegaxonal (también llamada arquitectura de Puertos y adaptadores) es una Clean Archiecture.
Se suele ver representada gráficamente en forma de hexágono, aunque realmente no tiene ninguna relación con el número 6. Es decir, ni se compone de 6 capas, ni admite de forma exclusiva 6 puertos o adaptadores.
Los detalles de implementación en Clean Architecture se refieren a las implementaciones necesarias para que la lógica de negocio se pueda comunicar con otros elementos externos a ella, tales como:
Arquitectura Hexagonal
El core de la aplicación se compondría de la capa de aplicación (implementación de casos de uso) y la capa de dominio (modelos e interfaces)
Puertos y adaptadores
Otra definición de la arquitectura hexagonal es la llamada Arquitectura de puertos y adaptadores. Quizá sea más correcta, puesto que elimina la referencia al número 6 inherente a la palabra Hexagonal y que puede inducir a error.
Ports and adapters
En este esquema, vemos el core de la aplicación como una unidad indivisible (aunque pueda estar compuesta por más de una capa). Perteneciente al core tendríamos los puertos, que no son más que las interfaces que deben cumplir los adaptadores o implementaciones.
Adaptadores primarios
Los adaptadores primarios son las implementaciones de comunicación con el cliente o usuario final. Por ejemplo una API Rest, una aplicación de escritorio, etc. Estos adaptadores hacen uso de los Puertos primarios para comunicarse con el core de la aplicación.
Puertos primarios
Los puertos primarios pertenecen al core y son las interfaces a las que se conectarán los Adaptadores primarios. Estas interfaces son las que exponen los casos de uso implementados dentro de la capa de negocio.
Puertos secundarios
Los puertos secundarios pertenecen al core y son las interfaces que deben implementar los Adaptadores secundarios para garantizar la correcta comunicación con los sistemas de infraestructura, tales como base de datos, sistema de ficheros, etc.
Adaptadores secundarios
Los adaptadores secundarios son las implementaciones de comunicación con los sistemas de infraestructura, ya sea una base de datos, un sistema de ficheros, un proveedor de envío de e-mails, etc. Estos adaptadores deben implementar los Puertos secundarios, para que el core de la aplicación pueda hacer uso de estos adaptadores sin conocer sus detalles de implementación.
Conclusiones
La arquitectura hexagonal es una gran opción si queremos enfocar la arquitectura de una aplicación a Clean architectures y DDD.
Aislar la lógica de negocio conlleva las siguientes ventajas:
- Independencia de los detalles de implementación
- Mayor testabilidad
- Mayor mantenibilidad
- Mayor adaptabilidad
Como consecuencia de esto, la lógica de negocio jamás se verá afectada por ningún problema que afecte a los detalles de implementación (tales como cambios en drivers de conexión, librerías o APIs externas), quedando totalmente aislados dentro de su correspondiente capa.
La mantenibilidad y adaptabilidad de la lógica de negocio se ven potenciadas por este modelo, que permite que el equipo de desarrollo de la capa de negocio se centre única y exclusivamente en los casos de uso, permitiendo establecer un lenguaje común con los expertos de negocio.
La testabilidad es otra gran beneficiada de esta arquitectura, puesto que facilita la simulación (o mock) de los detalles de implementación, permitiendo testear los casos de uso de una forma desacoplada con respecto a la infraestructura o sistemas secundarios subyacentes.
