Contenidos
Ejemplo de arquitectura hexagonal
La arquitectura hexagonal es un patrón muy potente. Te ayuda a crear un software más sostenible y mejor comprobable desacoplando la lógica de negocio del código técnico. El presente post profundiza en un ejemplo de Arquitectura Hexagonal construido con Kotlin y Spring Boot llamado TalkAdvisor. El código fuente está disponible en este repositorio de GitLab.
Como recordatorio, los adaptadores de la izquierda utilizan la API del dominio. Y esto es normalmente para exponer las características al consumidor. En el otro extremo, los adaptadores de la derecha integran el dominio con servicios de terceros a través de su SPI.
TalkAdvisor es una aplicación de demostración desarrollada con Kotlin y Spring Boot utilizando la arquitectura hexagonal. Recomienda charlas técnicas de YouTube basadas en las preferencias temáticas del usuario. Por lo tanto, ofrece dos características principales:
Técnicamente, nuestro ejemplo de Arquitectura Hexagonal se divide en dos partes: el dominio y la infraestructura. El dominio contiene toda la lógica de negocio y representa el contexto delimitado de la recomendación. En cambio, la infraestructura contiene:
Arquitectura hexagonal
Cuando tenía un concepto de dominio que dependía de un sistema externo, solía poner una interfaz para abstraer el proceso de construcción de sus instancias. Le daba a esa interfaz el “rol de puerto conducido”, y le daba a ese proceso el “rol de adaptador conducido”, sin importar lo complejo que fuera el proceso, o si tenía que traducir el modelo del sistema externo al modelo de dominio de mi aplicación. Esto es una influencia del “Diseño Dirigido por el Dominio” ( DDD ). Ese adaptador se llama “Capa Anti Corrupción” ( ACL ) en la jerga DDD.
Pero la Arquitectura Hexagonal no tiene nada que ver con DDD, la Arquitectura Hexagonal no sabe nada de DDD, la Arquitectura Hexagonal es sólo un patrón que dice: Poner una interfaz de puerto conducido para cualquier “cosa del mundo real” (actor conducido) con la que el hexágono necesite hablar.
Así que, Alistair, si una tarea no necesita tocar ninguna tecnología (por ejemplo) traducir A a B (una vez que obtuvimos A de un repo), mi error es que no debería poner esa tarea en un adaptador, sino dentro del hexágono. El adaptador se limita a obtener A del repositorio. ¿He acertado?
Arquitectura hexagonal de Kotlin
No soy un experto en HA, sin embargo la uso todos los días y la encuentro útil. La única razón por la que escribo este post es para mostrarte que la Arquitectura Hexagonal tiene sentido, al menos si tu servicio es algo más que un JsonToDatabaseMapper.
La implementación del adaptador REST accede a la lógica del dominio a través de un ArticleApiService interno. El servicio API pertenece al adaptador API. ArticleApiService delega la creación y recuperación de artículos al ArticleService del dominio y traduce el modelo del dominio al modelo de la API.
Mejores prácticas de arquitectura de Spring Boot
El principio de la arquitectura hexagonal fue creado por Alistair Cockburn en 2005. Es una de las muchas formas de DDD (Domain Driven Design Architecture). El objetivo era encontrar una manera de resolver o mitigar de alguna manera las advertencias generales introducidas por la programación orientada a objetos. También se conoce como arquitectura de puertos y adaptadores. El concepto de hexágono no está relacionado con una arquitectura de seis lados ni tiene nada que ver con la forma geométrica. Un hexágono tiene seis lados de hecho, pero la idea es ilustrar el concepto de muchos puertos. Además, esta forma es más fácil de dividir en dos y de utilizar como representación de la lógica de negocio de la aplicación. La idea es separar la aplicación que queremos desarrollar en tres partes distintas. La izquierda, el núcleo y la derecha. Desde un concepto aún más amplio queremos diferenciar los conceptos de dentro y fuera. El interior es la lógica de negocio y la aplicación en sí misma y el exterior es lo que estamos utilizando para conectar e interactuar con la aplicación.
El núcleo de una aplicación puede definirse como el lugar donde ocurre la lógica de negocio de la aplicación. El núcleo de una aplicación recibe datos, realiza operaciones sobre ellos y opcionalmente puede comunicarse con otros componentes externos como bases de datos o entidades de persistencia.