LambdaCast #13: Arquitectura Hexagonal – ¿Qué es, qué no es, y cuándo es sobre ingeniería?

El LambdaCast #13 fue una sesión dinámica y educativa sobre la Arquitectura Hexagonal o puertos y adaptadores. Un tema esencial para desarrolladores y arquitectos de software interesados en diseñar sistemas robustos y escalables. Esta sesión se tituló “Arquitectura hexagonal: ¿qué es, qué no es, y cuándo es sobre ingeniería?”. Contamos con la participación de Aleix Morgadas – Chief Product Officer (CPO), que compartió sus conocimientos y experiencias en la implementación de este patrón de diseño. Si no tuviste la oportunidad de asistir a la sesión en vivo, no te preocupes. A continuación, te ofrecemos un resumen detallado de los puntos clave discutidos durante el LambdaCast. Incluyendo una reflexión sobre cuándo esta arquitectura es útil y cuándo puede llevar a la sobreingeniería.

Puedes ver la grabación completa de esta sesión en YouTube.

• Introducción a la Arquitectura Hexagonal
• ¿Qué es la Arquitectura Hexagonal?
• Beneficios de la Arquitectura Hexagonal
• ¿Qué No Es la Arquitectura Hexagonal?
• Ejemplo de Sobreingeniería
• Cuándo Usar la Arquitectura Hexagonal
• Escenarios donde es útil aplicar Arquitectura Hexagonal
• Cuándo no usar la Arquitectura Hexagonal
• Lecciones Clave
• Conclusión

La arquitectura hexagonal, también conocida como puertos y adaptadores, es un patrón de diseño que se ha popularizado en los últimos años por su enfoque en desacoplar la lógica de negocio del software de las implementaciones tecnológicas específicas, como bases de datos o servicios externos.

Durante la sesión, se aclararon varios puntos respecto al término “arquitectura hexagonal”:

1. El concepto fue introducido por Alistair Cockburn.
2. Son una serie de reglas de dependencia que ayudan a que en nuestra arquitectura podamos aislar el código de aplicación del resto de agentes externos.
3. Se consigue aplicando el principio de inversión de dependencia a nivel de arquitectura.
4. Además, Aleix mencionó que quizás no se puede considerar una arquitectura como tal porque es muy poco restrictiva y que solamente se preocupa de estas reglas de dependencia.

Este patrón proporciona una flexibilidad considerable al permitir que el dominio central de la aplicación se mantenga independiente de las tecnologías externas.

La arquitectura hexagonal propone una estructura donde el núcleo del software o lógica de negocio se comunica con el mundo exterior a través de puertos (interfaces). Los adaptadores se conectan a estos puertos para manejar las interacciones con el exterior. Como por ejemplo: bases de datos, interfaces de usuario, o servicios de terceros. Aleix Morgadas explicó que la arquitectura hexagonal no es un marco rígido, sino una guía que permite a los desarrolladores abrir su sistema a múltiples opciones, en lugar de cerrarlo a un conjunto específico de dependencias tecnológicas. Este enfoque contrasta con arquitecturas más tradicionales como MVC o arquitecturas en capas, que suelen ser más prescriptivas.

• Desacoplamiento: Mantiene el dominio independiente de la infraestructura tecnológica.
• Flexibilidad: Permite cambiar componentes externos sin afectar la lógica de negocio.
• Facilidad de pruebas: Las pruebas unitarias y de integración se simplifican gracias a la clara separación de responsabilidades.

Un tema central del LambdaCast fue la desmitificación de la arquitectura hexagonal. Se destacó que, a menudo, se confunde con conceptos como DDD (Domain-Driven Design) o CQRS (Command Query Responsibility Segregation), lo que puede llevar a una implementación innecesariamente compleja. Aleix compartió su experiencia personal, explicando cómo el exceso de patrones y principios puede llevar a la sobrecarga cognitiva y a la sobreingeniería. Subrayó que, en muchos casos se utiliza incorrectamente para resolver problemas que no existen, lo que complica el desarrollo y el mantenimiento del software.

Uno de los puntos más interesantes de la sesión fue el análisis de casos en los que la arquitectura hexagonal se implementa de manera excesiva. Aleix describió su trayectoria en 2015-2016, cuando comenzó a explorar patrones avanzados como DDD y CQRS, y cómo esto lo llevó a sobrecomplicar soluciones que podrían haberse abordado de manera más simple. En su ejemplo, describió cómo, al intentar implementar una arquitectura hexagonal con todos los patrones asociados, terminó creando sistemas tan complejos que se volvieron difíciles de mantener y desarrollar, sin un retorno claro de la inversión en términos de eficiencia o escalabilidad. La moraleja aquí es clara: si bien es importante conocer y comprender patrones avanzados, es fundamental aplicarlos con juicio, adaptándolos a las necesidades reales del proyecto y evitando la tentación de implementarlos indiscriminadamente.

• Aplicaciones con ciclo de vida larga: Sistemas que necesitarán adaptarse a nuevas tecnologías con el tiempo.
• Proyectos con múltiples integraciones: Aplicaciones que interactúan con varios servicios externos, donde el desacoplamiento es clave para manejar el cambio.
• Entornos de desarrollo ágil: Equipos que desean mantener la flexibilidad para modificar componentes sin reescribir toda la lógica de negocio.

• Proyectos pequeños o prototipos: Donde la simplicidad y la velocidad de desarrollo son más importantes que la flexibilidad a largo plazo.
• Sistemas con poca lógica de negocio: En aplicaciones donde la mayor parte del trabajo se realiza a nivel de base de datos o servicios externos. La complejidad añadida de la arquitectura hexagonal puede no estar justificada.

Durante el LambdaCast, se discutieron varias lecciones clave que los asistentes pudieron llevarse:

1. Conoce tu proyecto: No todos los proyectos requieren una arquitectura tan flexible y desacoplada. Es crucial evaluar las necesidades específicas antes de decidir adoptar un patrón como este.
2. Evita la sobreingeniería: La implementación de patrones avanzados debe estar justificada por la complejidad del proyecto. Aplicar los patrones de diseño conocidos no garantiza un software mejor, y puede hacer que los proyectos sean más difíciles de manejar.
3. Prioriza la simplicidad: A menudo, la mejor solución es la más simple. Si un CRUD simple resuelve el problema, no hay necesidad de complicarlo con patrones avanzados.
4. Mantén la flexibilidad: Incluso dentro de una arquitectura hexagonal, es importante no perder de vista la simplicidad. Las decisiones deben basarse en un equilibrio entre desacoplamiento y facilidad de implementación.

La arquitectura hexagonal es un patrón de diseño que puede mejorar significativamente la flexibilidad y la mantenibilidad del software. Sin embargo, también puede llevar a la sobreingeniería si no se aplica con cuidado.

El LambdaCast fue una oportunidad para reflexionar sobre este patrón y discutir sus aplicaciones prácticas. También hablar de los errores comunes que se cometen al implementarlo. Si estás considerando adoptarla en tu proyecto, asegúrate de evaluar cuidadosamente sus beneficios frente a sus posibles complicaciones. Para profundizar más en este tema, te invitamos a ver la sesión completa en nuestro canal de YouTube.