Hexagonal Architecture
Perspectiva sobre el canonical
La definición y los trade-offs de esta aproximación están en ports-and-adapters. En el Atlas, Hexagonal Architecture es una Perspective Note sobre la formulación de Alistair Cockburn, no un segundo patrón que compite con Ports and Adapters.
El artículo original de 2005 presenta Ports and Adapters como nombre del patrón y Hexagonal Architecture como nombre alternativo. Su preocupación es separar la aplicación de los dispositivos y tecnologías que la rodean. El hexágono ofrece espacio para dibujar varios ports y destaca inside/outside; seis lados no exigen seis ports.
La clasificación editorial como perspectiva permite conservar la explicación histórica sin duplicar una definición. No afirma que Cockburn propusiera dos arquitecturas distintas.
Qué comunica el dibujo
La imagen ayuda a preguntar qué pertenece a la aplicación y qué pertenece a una interacción externa. Un dibujo con UI arriba y database abajo puede inducir a tratar ambas como extremos de una única cadena. Una figura con varias conexiones alrededor permite pensar también en procesos batch, pruebas y otros sistemas.
En nuestro ejemplo, aprobar una solicitud no cambia de significado porque llegue desde una pantalla o desde un mensaje. Sí cambian los detalles que deben interpretar esos adaptadores. El propósito de la frontera es poder examinar esa diferencia, no decidir dónde colocar cada carpeta en el dibujo.
Esto tampoco significa que todos los colaboradores tengan el mismo papel. Las interacciones primary/driving y secondary/driven se distinguen por quién inicia la conversación. La simetría visual no elimina esa distinción ni convierte entrada y salida en el mismo contrato.
Interpretaciones que el nombre no justifica
Una lectura literal puede producir seis paquetes, seis interfaces obligatorias o una clase Adapter por cada objeto. Esas convenciones no prueban que el núcleo esté protegido. Una función llamada HexagonalService puede seguir importando el framework HTTP o construyendo consultas específicas del almacenamiento.
Tampoco una API pública equivale automáticamente al port de aplicación. En nuestro ejemplo, una API HTTP puede traducir códigos y autenticación de transporte a una operación de aprobación. Si el caso de uso recibe directamente el request del framework, la traducción puede haber dejado entrar el detalle que pretendía separar.
Otra confusión es considerar que el modelo geométrico garantiza independencia operativa. Una base de datos sigue pudiendo fallar aunque su adaptador esté bien ubicado. Un fake hace posible ejecutar ciertas pruebas; no reproduce necesariamente concurrencia, durabilidad o resultados inciertos. Esas cuestiones se desarrollan en el canonical.
No se deducen del nombre requisitos de microservices, DDD, un contenedor de inyección o una biblioteca particular. Son decisiones adicionales que necesitan su propio contexto y justificación.
Cómo leer versiones modernas
La recomendación editorial es contrastar cualquier versión con preguntas concretas: ¿cuál es la frontera?, ¿qué conversación expresa cada port?, ¿qué cambia el adaptador?, ¿qué tipos conoce el núcleo?, ¿quién ensambla implementaciones? Las respuestas son más informativas que la cantidad de lados del diagrama.
Una implementación puede agregar capas concéntricas o separar políticas de aplicación y negocio. onion-architecture y clean-architecture dan nombres y énfasis propios a esas decisiones. Su parentesco no obliga a reinterpretar Hexagonal como una tercera definición del mismo contrato.
internal-structure ofrece la comparación de esa familia. Para responsabilidades, pruebas y límites técnicos de Ports and Adapters, continuar con el canonical; para entender por qué se dibuja un hexágono, esta nota conserva la perspectiva original.