Puertos, adaptadores y DDD
Ejemplos de arquitectura son MVC, la programación por capas, peer-to-peer, orientada a servicios (SOA), cliente-servidor…
Independientes del framework
Independientes de la UI
Independientes de la base de datos
Independiente de agentes externos
Mantenibles
Altamente Testables
Reutilizables
Tolerantes al cambio
Historia y motivaciones
Por qué se crearon las Arquitecturas Hexagonales
- Primero, el sistema no puede ser fácilmente probado con suites de pruebas automatizadas porque parte de la lógica que se necesita probar depende de detalles visuales que cambian a menudo, como el tamaño de un campo de entrada o la posición de un botón.
- Por la misma razón, se vuelve imposible cambiar su uso de uno dirigido por personas a un sistema de funcionamiento por lotes.
- Por ello, se vuelve difícil o imposible permitir al programa ser guiado (o usado) por otro programa cuando se desee.
¿Por qué hexágonos?
La asimetría interna-externa y la naturaleza similar de los puertos, con el fin de alejarse de la imagen unidimensional de las capas y todo lo que ella evoca.
La presencia de un número definido de diferentes puertos.
El hexágono no es un hexágono porque el número seis sea importante, sino más bien para permitir que la gente que hace uso del esquema tenga espacio para insertar puertos y adaptadores cuando lo necesite, sin estar restringido a un esquema unidimensional en capas. El término “arquitectura hexagonal” viene de este efecto visual.
Puertos y adaptadores
El término “puerto y adaptadores” reúne los “propósitos” de las partes del esquema. Un puerto identifica una comunicación útil. Típicamente, habrá muchos adaptadores para cualquier puerto, para varias tecnologías que puedan conectarse a un puerto.
Estas podrían ser: un contestador automático, un teléfono táctil o por voz, una GUI, un test harness, un batch driver, una interfaz http, una interfaz directa programa a programa (i.e. Llamadas a Procedimientos Remotos- RPC), una base de datos mock (en memoria) o una real (quizá distintas bases de datos para el desarrollo, pruebas y producción).
Un puerto es un consumidor agnóstico, un punto de entrada a la aplicación. Si buscamos una analogía, podría ser una interfaz en muchos lenguajes de programación. Podremos utilizar esta interfaz sin saber nada de cómo es su implementación concreta.
Los adaptadores funcionan como puente entre la aplicación y el servicio que esta necesita. Su función es transformar la comunicación entre actores externos y la lógica de la aplicación. Se corresponden con la implementación de los puertos.
La principal motivación de esta arquitectura es exponer los puertos de entrada o primarios, en una API que pueda ser ejecutada indistintamente por usuarios, programas o procesos. Esto nos da la ventaja de que el núcleo de nuestra aplicación no conoce lo que tiene a su alrededor ni se interesa en implementar su lógica de mensajes, de esto se encargarán los adaptadores.
Un evento entra a la aplicación desde el exterior y la aplicación ignora la naturaleza de la entrada. Esta llamada ha venido dada por un adaptador que ya se encargó de convertir la llamada en un procedimiento utilizable. En el momento que la aplicación necesita comunicar algo hacia el exterior, lo hace a través de un puerto y luego este puerto lo envía a un adaptador que se encargará de convertir la llamada saliente para que el dispositivo receptor la entienda.
Desventajas de las Arquitecturas Hexagonales
- Como para comunicar entre las diferentes capas hace falta el uso de puertos (interfaces) la complejidad suele aumentar con frecuencia. Hay que tener muy claros los principios básicos y cómo implementarlos ya que si no podríamos incurrir en los problemas históricos.
- En aplicaciones grandes, habrá un gran número de capas, con sus correspondientes interfaces e implementaciones. Esto supone un mayor nivel de Mantenimiento debido al aumento (por ejemplo en Java) de clases.
Arquitecturas Hexagonales y DDD
¿Cómo podemos dividir el código?
Capa de Dominio
Capa de Aplicación
Capa de Dominio
Conclusiones
- La Arquitectura Hexagonal propone un uso de forma escrupulosa de los principios SOLID, que nos guían para construir mejor software.
- Nuestro Dominio no está acoplado a nada externo, ya que dispone de puertos que deben ser implementados por los elementos externos.
- Facilita estar desacoplado del método de entrega haciendo que un caso de uso sea válido para una APP móvil, una API, una web tradicional…
- Está preparada para cambiar detalles de la implementación como la persistencia o el framework.
- Los elementos pueden ser fácilmente testados mediante pruebas unitarias.
Blog elaborado por Jorge Aranda
¡Habla con nuestros expertos!
