Del código espagueti a la arquitectura hexagonal

A día de hoy, el software es ubicuo. ¿Queremos chatear con un amigo a miles de kilómetros? Recurrimos al software. ¿Queremos comprar online? Recurrimos al software. ¿Queremos escuchar música? Recurrimos al software. Por esto, en este post voy a escribir sobre arquitecturas de software, desde el código espagueti hasta la tan nombrada arquitectura hexagonal.

La arquitectura de software

Todo software tiene una arquitectura que estará mejor o peor diseñada, pero todo software tiene una serie de elementos que lo conforman y que logran que sea de una determinada manera. Evidentemente, la fase de diseño arquitectural ha de ser intencional si la resolución de nuestros problemas no es trivial. Diseñar es una tarea complicada, puesto que es necesario crear software que resuelva problemas.

Al fin y al cabo, es lo que el ser humano ha desarrollado a lo largo de la historia: herramientas que permiten hacernos la vida más fácil.

Es imposible (o muy complicado, pues en este sector no se deberían hacer afirmaciones tan categóricas) hacer el software perfecto, pero, al menos, hay que tratar de diseñar e implementar software que maximice las características de calidad: rendimiento, escalabilidad, capacidad para ser evaluable, mantenibilidad, eficiencia, robustez, resiliencia, efectividad, flexibilidad, funcionalidad, portabilidad… Es por esto que es recomendable proponer diseños técnicos entre varias personas (el diseño es una tarea colegiada), ya que esto implica discutir distintos puntos de vista y abarcar más casuísticas que las que podría abarcar una sola persona.

El código espagueti

He comentado antes, literalmente: “la fase de diseño arquitectural ha de ser intencional”. El código espagueti no está diseñado concienzudamente, aunque, a veces, cumple sus propósitos. Siempre que pienso en el código espagueti se me viene a la cabeza una improvisación musical. Por un lado, en el mundo de la música en particular y del arte en general, la espontaneidad puede ser una aliada ya que facilita la transmisión de tu “yo más interior”, de tu personalidad… Dicho de otra manera, espontaneidad puede ser confundida con “creatividad en tiempo real”. Esto se percibe socialmente como bueno y de calidad.

Sin embargo, en el mundo del software pasa un poco lo mismo que en el mundo de la arquitectura tradicional (sí, la de los puentes). ¿Pasarías por un puente improvisado que se ha diseñado de forma accidental? ¿Utilizarías una pasarela de pago construida con código espagueti? ¿Te subirías a un coche autónomo que ha programado un desarrollador “en un momento de inspiración”? Entonces, ¿qué ocurre? ¿Por qué he empezado diciendo que a veces cumple sus propósitos? Porque es así, en determinadas ocasiones no es necesario llevar a cabo sobreingeniería y exprimir al 100% nuestra CPU fisiológica para resolver un problema.

Dicho de otro modo, a veces, nuestro cerebro improvisa implícitamente una solución que funciona y que entra dentro de nuestros objetivos de calidad (funcionalidad, efectividad…). No obstante, nuestro cerebro no es capaz de improvisar la arquitectura software de los grandes e-commerce, ni tampoco de un coche autónomo. A nivel cognitivo es imposible para un ser humano empezar a escribir el código de un sistema de esas características asegurando, además, que se alcanzan los objetivos de calidad especificados. Es por esto que el código espagueti, estigmatizado y despreciado por el sector del software, y al que he empezado «defendiendo» (porque, admitámoslo, dependiendo del problema no es tan malo), es incompatible con los productos que tenemos que desarrollar en Hiberus. 

La arquitectura hexagonal (o arquitectura de puertos y adaptadores)

Lo que se pretende con esta arquitectura limpia es proponer una metodología de diseño para sistemas complejos que proporciona muchas facilidades para obtener los objetivos de calidad mencionados.

Consiste en separar el sistema en tres capas:

• infraestructura
• aplicación
• dominio

La palabra «separación» implica, en este caso, un bajo acoplamiento (o incluso un desacople total) entre capas, que transitivamente se convierte en una mayor mantenibilidad (responsabilidades acotadas) y una mayor capacidad para ser evaluable (mocks y posibilidad de realizar pruebas unitarias). Además, también favorece la alta cohesión. Para que el diseño sea correcto y no desemboque en una “arquitectura de puertos, adaptadores y espaguetis” es necesario respetar el orden de las capas.

Los objetos de la capa de dominio y aplicación no deberían utilizar objetos de la capa de infraestructura, al igual que los objetos de la capa de dominio no deberían utilizar objetos de la capa de aplicación. Dicho de otra manera, las dependencias van de «fuera» hacia «dentro».

Aunque se suele representar como forma de hexágono (de ahí su nombre), realmente no limita el número de interacciones entre las capas (que sea un hexágono no un cuadrado o un octógono es casualidad). De esta manera, cada lado del polígono sería un puerto al que nos podríamos conectar a través de un adaptador.

Algunos ejemplos: 

• Implementamos un adaptador (e.g. clase UserController) en la capa de infraestructura para conectarnos al puerto HTTP de nuestro sistema.
• Este controlador/adaptador necesitará utilizar un “caso de uso” de la capa de aplicación (e.g. interfaz UserSignIn y clase UserSignInImpl) para registrar un usuario. He definido una interfaz y una clase que la implementa ya que he seguido el Principio de Inversión de Dependencias (la D de los principios SOLID). Este principio se basa en que lo mejor es acoplarse a contratos (UserSignIn) y no a implementaciones concretas (UserSignInImpl). En este caso, el puerto sería la interfaz, mientras que el adaptador sería la implementación concreta.
• Este caso de uso de la capa de aplicación necesitará crear una entidad usuario (e.g. clase User) y almacenarla en un repositorio (e.g. interfaz UserRepository). Estos dos últimos elementos mencionados pertenecen a la capa de dominio, el núcleo del sistema en una arquitectura limpia. Recalco que es el núcleo, porque es a lo que se le da más importancia en este tipo de arquitecturas. A partir del núcleo/dominio surge el Diseño Dirigido por el Dominio (Domain Driven Design, DDD), del que hablaré pronto en otro post.

Ventajas del uso de la arquitectura hexagonal

Con este pequeño diseño hemos conseguido muchas ventajas. Algunas de ellas son: 

• El caso de uso de registrar un usuario se podría utilizar desde distintos lugares que no sean nuestra clase UserController (e.g. interfaz de línea de comandos, adaptador de Kafka/RabbitMQ…), ya que se han separado las responsabilidades. 
• El caso de uso de registrar un usuario podría implementarse de diferentes maneras (e.g. registro email/contraseña, registro con token de una red social, registro con número de teléfono…), ya que hemos seguido el principio de inversión de dependencias y los elementos de la capa de infraestructura no dependen de implementaciones concretas. 
• El caso de uso de registrar un usuario podría almacenar al usuario en una base de datos documental (MongoDB), en una base de datos relacional (PostgreSQL)… Ya que hemos seguido el principio de inversión de dependencias. Esto hace que la solución sea agnóstica del SGBD que se utiliza, favoreciendo la mantenibilidad. 
• A nivel de semántica, todo está más separado, diferenciado y estructurado, por lo que se entiende mucho mejor y todas las partes resultantes son mucho más simples. 
• Se pueden hacer tests unitarios por capas. 
• Al fragmentar la aplicación, se puede reutilizar el código de casos de uso repetitivos entre aplicaciones, como puede ser el caso de uso mencionado de registro de usuarios. 

Conclusiones

En este post hemos repasado la importancia del software, qué es una arquitectura de software, así como qué diferencia al “código espagueti” de arquitecturas bien diseñadas y estructuradas.

Dentro de estas últimas, se encuentra la ya famosa “arquitectura hexagonal”, de la que hemos detallado sus ventajas, además de a qué se deben.

En Hiberus somos expertos en microservicios. Trabajamos día a día para mejorar nuestro software basándonos en experiencias previas y en patrones arquitecturales como este. Si crees que podemos mejorar tu sistema de información, contáctanos.