En el mundo del diseño de software, la “Arquitectura Hexagonal” de Alistair Cockburn se ha convertido en un término popular y, para algunos, casi un dogma. Sin embargo, ¿realmente aporta algo nuevo? En OswaldoTechMind, desglosamos las inconsistencias, los mitos y las verdades que se esconden detrás de esta propuesta, que muchos consideran revolucionaria.
La Ambigüedad de los Puertos: ¿Una Cuestión de Diseño o de Gusto?
Uno de los pilares fundamentales de la arquitectura hexagonal es la definición de “puertos” y “adaptadores” como elementos clave para la organización del sistema. Sin embargo, Cockburn los describe con una falta de precisión que no solo genera confusión, sino que también abre la puerta a interpretaciones subjetivas. En su artículo afirma:
“Qué es y qué no es exactamente un puerto es en gran medida una cuestión de gusto…”
En el diseño de software, los conceptos arquitectónicos no pueden basarse en gustos o preferencias personales; deben estar respaldados por principios objetivos y replicables. Esta ambigüedad no solo afecta la comprensión de la arquitectura, sino que también dificulta su implementación efectiva en proyectos reales. Además, Cockburn sugiere que el número de puertos necesarios es irrelevante:
“No parece que haya ningún daño particular al elegir el número ‘incorrecto’ de puertos… sigue siendo una cuestión de intuición.”
Esto plantea preguntas fundamentales: ¿qué lugar ocupan los principios de diseño como la alta cohesión y el bajo acoplamiento en este enfoque? ¿Es realmente aceptable dejar cuestiones arquitectónicas críticas al juicio intuitivo? ¿Cómo se mide el éxito de una arquitectura que carece de directrices claras y universales?
El concepto de “puertos” puede parecer innovador en teoría, pero su implementación en la práctica está lejos de ser trivial. Por ejemplo, en sistemas distribuidos, definir los puntos de interacción con claridad es crucial para evitar inconsistencias y garantizar que los componentes puedan evolucionar de manera independiente. Sin embargo, la falta de definiciones estrictas en la arquitectura hexagonal puede llevar a soluciones inconsistentes, donde los desarrolladores interpretan de manera subjetiva qué constituye un puerto y cómo debe implementarse.
Historia y Contexto: Todo Estaba Ya Escrito
Cockburn también hace referencia al “Principio de Inversión de Dependencia”, atribuyéndolo a Robert C. Martin (“Uncle Bob”) y mencionando también a Martin Fowler. Pero ¿sabías que estos principios ya estaban documentados desde hace décadas? Veamos un poco de historia:
- 1974: Wayne Stevens y Peter Pinson, en su artículo “On the Criteria To Be Used in Decomposing Systems into Modules”, introdujeron conceptos como modularidad y cohesión que sentaron las bases del diseño moderno.
- 1979: Larry Constantine y Ed Yourdon publicaron “Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design”, profundizando en los principios de cohesión y acoplamiento.
- 1988: Bertrand Meyer formalizó el principio abierto-cerrado en su libro “Object-Oriented Software Construction”, un texto que aún es referencia obligada.
- 1994: Barbara Liskov y Jeannette Wing definieron el principio de sustitución, otro pilar fundamental, en “A Behavioral Notion of Subtyping”.
Es evidente que las ideas centrales de la arquitectura hexagonal no son innovaciones originales, sino reinterpretaciones de principios establecidos. Lo preocupante es cómo se presentan como si fueran conceptos nuevos, lo que puede inducir a error a las nuevas generaciones de desarrolladores.
Además, es importante resaltar que muchas de las herramientas que se asocian con la arquitectura hexagonal, como los frameworks de inyección de dependencias o los sistemas de mensajería, fueron desarrolladas mucho antes de que este concepto ganara popularidad. Esto refuerza la idea de que la arquitectura hexagonal no introduce nada verdaderamente disruptivo, sino que empaqueta ideas existentes bajo una nueva narrativa.
Cambiar Nombres No Es Innovar
Uno de los problemas más evidentes de la arquitectura hexagonal es su tendencia a renombrar conceptos básicos con terminología innecesariamente compleja. Cockburn habla de “actores secundarios”, “puertos izquierdos” y “puertos derechos”, lo que no solo complica la comprensión, sino que también introduce una capa de abstracción artificial que no aporta valor real.
Por ejemplo, el patrón MVC (Modelo-Vista-Controlador), introducido por Trygve Reenskaug en los años 70, ya proporcionaba una forma efectiva de separar las responsabilidades en un sistema. Este patrón permitió la creación de interfaces de usuario mantenibles y escalables, un problema que la arquitectura hexagonal también pretende abordar, pero sin aportar mejoras significativas.
De manera similar, Tom DeMarco y Timothy Lister discutieron la importancia de la modularidad y la organización en capas en sus publicaciones clásicas. Su enfoque práctico y basado en datos contrastaba con la ambigüedad conceptual que caracteriza la arquitectura hexagonal.
La proliferación de terminología también puede ser perjudicial para los equipos de desarrollo. En entornos donde la comunicación clara y precisa es esencial, introducir nuevos términos para describir conceptos ya existentes puede generar malentendidos y reducir la eficiencia. Este es un problema especialmente evidente en equipos que adoptan metodologías ágiles, donde los ciclos de retroalimentación rápidos y la simplicidad son clave para el éxito.
El Impacto en los Desarrolladores Novatos
Uno de los efectos más preocupantes de propuestas como la arquitectura hexagonal es el impacto que tienen en los desarrolladores que están comenzando en el mundo del software. En lugar de aprender los fundamentos sólidos del diseño, muchos se encuentran atrapados en un mar de términos y conceptos que no están claramente definidos ni respaldados por ejemplos prácticos.
Por ejemplo, el “Principio de Inversión de Dependencia” y la “Inyección de Dependencias” son conceptos que ya existían antes de que Cockburn los mencionara. Pero ¿cuántos jóvenes desarrolladores creen erróneamente que estas ideas son exclusivas de la arquitectura hexagonal? Este tipo de desinformación solo perpetúa mitos y genera confusión innecesaria.
Además, la falta de ejemplos concretos y casos de éxito ampliamente documentados dificulta que los desarrolladores novatos comprendan cómo aplicar estos conceptos en situaciones reales. Mientras que los patrones clásicos, como MVC o el patrón de repositorio, han sido ampliamente adoptados y probados en una variedad de contextos, la arquitectura hexagonal carece de este nivel de validación empírica.
Conclusión: Volvamos a lo Básico
La arquitectura hexagonal, con toda su terminología llamativa, no aporta nada que no se conociera ya en la década de 1970. Sus conceptos fundamentales se basan en principios clásicos como la cohesión, el bajo acoplamiento y la modularidad, principios que fueron desarrollados y documentados por pioneros como Larry Constantine, Bertrand Meyer y Barbara Liskov.
Si eres desarrollador o arquitecto de software, mi consejo es claro: vuelve a las fuentes originales. Lee los libros clásicos, estudia los principios fundamentales y no te dejes llevar por el ruido de las redes sociales o los blogs sin rigor. La verdadera innovación no está en cambiar nombres o reinventar conceptos, sino en aplicar soluciones efectivas y sostenibles a problemas reales.
Como dijo alguna vez Jack Reeves en su artículo de 2003 en la revista C++: “El diseño de software no es más que buena ingeniería”. Volvamos a la esencia y dejemos de lado el ruido innecesario.
Finalmente, es importante fomentar una cultura de aprendizaje crítico en el ámbito del desarrollo de software. No todo lo que se presenta como innovador o revolucionario lo es realmente. Analiza, cuestiona y construye sobre fundamentos sólidos. Solo así podremos avanzar hacia soluciones que sean verdaderamente efectivas y duraderas.