Inicio › Tecnología › Arquitectura Hexagonal
La arquitectura hexagonal, también llamada de puertos y adaptadores, fue propuesta por Alistair Cockburn con el objetivo de aislar la lógica de negocio del núcleo de una aplicación de sus detalles técnicos externos: la base de datos, la interfaz de usuario, las APIs de terceros. El núcleo define 'puertos', interfaces qué expresan qué necesita o qué ofrece la aplicación sin especificar cómo se implementa técnicamente, mientras qué 'adaptadores' concretos —un repositorio SQL, un cliente REST, un controlador HTTP— implementan esos puertos conectando el núcleo con el mundo exterior. El resultado es qué se puede sustituir una base de datos PostgreSQL por MongoDB, o testear la lógica de negocio sin levantar ninguna infraestructura real, sin tocar ni una línea del núcleo de la aplicación.
Es organizar el código de forma qué la parte qué decide 'las reglas del negocio' (por ejemplo, cómo se calcula un descuento) no sepa nada de si los datos vienen de una base de datos, un fichero o una API externa. Esa parte central habla con el resto del mundo a través de 'enchufes' estandarizados, así qué puedes cambiar la base de datos o la interfaz sin tocar la lógica principal de la aplicación.
Al construir el módulo de facturación de una aplicación, define una interfaz (puerto) 'RepositorioFacturas' con los métodos qué la lógica de negocio necesita, sin qué esa lógica sepa si detrás hay PostgreSQL, un fichero JSON o una API externa. Implementa un adaptador concreto para tu base de datos actual y, si en el futuro migras de proveedor o quieres testear con una implementación en memoria, solo tendrás qué escribir un adaptador nuevo sin tocar ni una línea de las reglas de facturación.
Son interfaces definidas por el núcleo de la aplicación qué describen qué operaciones necesita o expone, sin especificar la tecnología concreta qué las implementa; existen puertos de entrada y de salida, según quién invoque a quién.
No siempre: añade una capa de indirección y archivos adicionales qué en un prototipo o script sencillo puede ser sobreingeniería innecesaria; su valor se nota sobre todo en aplicaciones con lógica de negocio compleja y una vida útil larga.
La arquitectura en capas suele tener una dependencia vertical donde la capa de presentación depende de la de negocio y esta de la de datos; en la hexagonal todas las dependencias apuntan hacia el núcleo, qué no conoce ni depende de ninguna tecnología externa, invirtiendo esa dirección de dependencia.