En su evolución a lo largo de su historia, el desarrollo de software y las diferentes escuelas de arquitectura con tracción en la comunidad han ido solidificando una serie de pilares imprescindibles a la hora de planificar aplicaciones: la mantenibilidad, la escalabilidad y la flexibilidad. Sin ellas en mente, la tendencia universal que tienen los sistemas a aumentar su complejidad al crecer establece un techo más o menos definido más allá del cual un programa no podría crecer, a riesgo de volverse completamente inasible por una persona que intente introducirse en el proyecto, o tremendamente frágil ante cambios y, por tanto, imposible de actualizar y escalar.
Una de estas arquitecturas que se han ganado un puesto como patrones ampliamente conocidos y empleados más allá de los circuitos teóricos es la de de Puertos y Adaptadores, propuesta en 2005 por Alistair Cockburn, también conocido por ser uno de los impulsores de la metodología Agile. La idea base de esta arquitectura es el desacople del núcleo de la aplicación de sus mecanismos de entrada y salida, permitiendo una mayor modularidad y testabilidad.
InprOTech Guardian, nuestra solución avanzada de ciberseguridad para redes OT, es software propio escrito con estos principios arquitectónicos en su base. En este artículo exploraremos los fundamentos de esta arquitectura, su estructura, ventajas, desventajas y cómo se implementa en la práctica.
Origen y Motivación
Alistair Cockburn introdujo la arquitectura de Puertos y Adaptadores como una respuesta a ciertos problemas típicos derivados del desarrollo orientado a objectos: dependencias excesivas y/o superfluas entre capas, imposibilidad de sustituir los elementos adyacentes a la aplicación por sistemas de prueba o de testeo, y filtrado de la lógica de negocio fuera de su rango de aplicación. Su objetivo principal era resolver los problemas de dependencia excesiva en las interfaces externas, lo que dificulta la evolución y el mantenimiento de los sistemas.
Problemas en las arquitecturas tradicionales
Las arquitecturas tradicionales suelen presentar problemas como:
- Acoplamiento fuerte entre la lógica de negocio y las capas de infraestructura (bases de datos, interfaces gráficas, APIs externas).
- Dificultad para realizar pruebas unitarias, ya que la lógica de negocio está entrelazada con la infraestructura.
- Menor flexibilidad, ya que cualquier cambio en los componentes externos impacta directamente el núcleo de la aplicación.
La arquitectura de Puertos y Adaptadores busca solucionar estos problemas promoviendo una separación clara entre el núcleo de negocio y el mundo exterior.
En sus propias palabras, los siguientes puntos constituyen la clave de esta arquitectura, su ¿para qué?:
Crea tu aplicación para que funcione sin una interfaz de usuario o base de datos para así:
- poder correr tests automatizados contra ella
· trabajar cuando la base de datos no está disponible
· estar abierto a implementar nueva tecnología
· conectar diferentes aplicaciones
· proteger tu códgo de filtraciones entre la lógica de negocio y el I/O
El Hexágono y la confusión con el nombre
En los 90, cuando Cockburn comenzó a coquetear con la idea que acabaría siendo este patrón, utilizaba un hexágono para representar su sistema. El motivo era que un cuadrado indroducía una idea muy fuerte de arriba-abajo-izquierda-derecha, que él consideraba un problema de enfoque, pero necesitaba una figura con simetría radial y con caras para representar los puntos de contacto de la aplicación con el exterior (aunque no identificaría estos puntos como los puertos hasta 2004). A pesar de que el hexágono no tenía ningún tipo de significado, ni el seis era un número especial o mágico en este contexto, el nombre con el que Cockburn bautizó al patrón ya había cuajado cuando decidió que el nombre correcto de la arquitectura, el que mejor captura su esencia, es el de Puertos y Adaptadores. Aunque el autor suele hacer incapié en cuál es la mejor denominación para aclarar esta posible confusión, lo cierto es que no reniega del nombre Arquitectura Hexagonal: su libro publicado en 2024 con el sevillano Juan Manuel Garrido de Paz sobre este diseño se titula Hexagonal Architecture Explained – How the Ports & Adapters architecture simplifies your life, and how to implement it; e incluso vende en su página web tazas y camisetas donde el hexágono es protagonista.
Principios de la Arquitectura de Puertos y Adaptadores
La arquitectura de Puertos y Adaptadores se basa en los siguientes principios fundamentales:
- El núcleo de la aplicación es independiente de los detalles externos: La lógica de negocio debe ser autónoma y no depender directamente de frameworks, bases de datos, APIs o interfaces de usuario.
- Interacción a través de «puertos»: Los puertos son interfaces que definen cómo otros componentes pueden interactuar con la lógica de negocio.
- Uso de «adaptadores» para conectar las interfaces externas con los puertos: Los adaptadores traducen las llamadas entre los componentes externos y los puertos internos.
Estructura de la Arquitectura de Puertos y Adaptadores
La arquitectura se compone de tres elementos principales:
Núcleo de la Aplicación
El núcleo de la aplicación contiene toda la lógica de negocio y las reglas del dominio. Está compuesto por:
- Casos de uso: Representan las acciones que puede realizar la aplicación (por ejemplo, «Registrar un usuario»).
- Entidades del dominio: Modelan los conceptos centrales del negocio y contienen la lógica de validación.
- Servicios de dominio: Contienen lógica de negocio compleja que no pertenece a una única entidad.
Este núcleo no tiene conocimiento de la infraestructura, lo que permite su testeo de manera aislada.
Puertos (Interfaces)
Los puertos actúan como contratos que definen cómo interactúan los componentes externos con el núcleo de la aplicación. Existen dos tipos de puertos:
- Puertos de Entrada: Interfaces que exponen los casos de uso de la aplicación. Son implementadas por controladores o servicios de aplicación.
- Puertos de Salida: Interfaces que representan dependencias externas como bases de datos, APIs de terceros o sistemas de mensajería.
Adaptadores
Los adaptadores implementan los puertos y se encargan de la comunicación entre el núcleo y el mundo exterior. Pueden implementan puertos de entrada (manejar solicitudes externas como una API REST o una interfaz gráfica) o de salida (la comunicación con bases de datos, sistemas externos, etc.)
Cabe mencionar que un sistema puede no tener adaptadores (o más bien, siguiendo el énfasis habitual en Cockburn en los usuarios de las aplicaciones sobre las propias aplicaciones, podríamos no necesitar adaptadores).
Relación con la Separación en Capas (Dominio, Aplicación e Infraestructura)
Alistair Cockburn es muy explícito en que su diseño solo define la existencia de un “interior» y un «exterior» en la arquitectura de Puertos y Adaptadores y que solo tiene una capa, la propia aplicación. Sin embargo, la simplicidad de este patrón permite acoplarlo a otros diseños, y muchos desarrolladores han adoptado una separación en tres capas, de más a menos externas:
- Infraestructura: Implementa la conectividad con bases de datos, sistemas de mensajería, APIs externas, etc.
- Aplicación: Orquesta los casos de uso, definiendo cómo se deben ejecutar.
- Dominio: Contiene las reglas de negocio puras y entidades centrales.
La relación entre estos tres estratos es unidireccional, de forma que las capas interiores solo pueden comunicarse con las capas que las contienen.
Esta separación bebe directamente de otros paradigmas como el Domain-Driven Design (DDD) de Eric Evans, la Clean Architecuture de Robert C. Martin, y el Onion Architecture.
En muchos casos, y aparentemente a contrapelo de la consideración del autor, esta separación en tres capas de infraestructura, aplicación y dominio forma parte de facto de la Arquitectura.
mi_proyecto/
│── src/
│ ├── application/
│ │ ├── puertos.py
│ ├── domain/
│ │ ├── modelo.py
│ │ ├── servicios.py
│ ├── infrastructure/
│ │ ├── persistencia.py
│ │ ├── api.py
│ ├── configuracion/
Beneficios de la Arquitectura de Puertos y Adaptadores
- Desacoplamiento: La lógica de negocio no depende de la infraestructura externa, lo que permite cambios en la base de datos o la interfaz sin afectar el núcleo.
- Testabilidad: Como el núcleo es independiente, se pueden realizar pruebas unitarias sin necesidad de configurar bases de datos u otras dependencias externas.
- Flexibilidad y mantenibilidad: Los adaptadores pueden ser reemplazados fácilmente para soportar nuevas tecnologías o integrar nuevos servicios externos.
- Escalabilidad: Permite dividir el sistema en módulos más manejables y reutilizables.
Desventajas y Desafíos
- Mayor complejidad inicial: La separación en puertos y adaptadores requiere más diseño y estructura en comparación con arquitecturas monolíticas simples.
- Sobreingeniería en aplicaciones pequeñas: No siempre es necesario este nivel de abstracción si la aplicación es muy sencilla.
- Mayor cantidad de código y clases: Se necesita escribir más código debido a la implementación de interfaces y adaptadores.
La arquitectura de Puertos y Adaptadores es una alternativa poderosa para diseñar sistemas desacoplados, flexibles y altamente testables. Su enfoque en la separación entre el núcleo de negocio y la infraestructura permite que las aplicaciones sean más mantenibles a largo plazo, facilitando la evolución del sistema sin depender de tecnologías específicas.
Aunque su implementación requiere una mayor planificación y estructura inicial, los beneficios que ofrece en términos de modularidad, escalabilidad y facilidad de pruebas justifican su adopción en proyectos que buscan robustez y flexibilidad. Además, su compatibilidad con otros enfoques como Domain-Driven Design (DDD) y Arquitectura Limpia la convierte en una opción versátil para sistemas complejos.
Sin embargo, es importante evaluar el contexto y necesidades del proyecto antes de aplicarla, ya que para aplicaciones pequeñas o de corta duración, el esfuerzo adicional puede no ser justificado. En definitiva, comprender los principios detrás de esta arquitectura y saber cuándo aplicarlos es clave para construir software sostenible y de alta calidad.
Referencias
1: https://alistair.cockburn.us/hexagonal-architecture
2: https://agilemanifesto.org/
3: https://www.youtube.com/watch?v=k0ykTxw7s0Y [Hexagonal Architecture @Tech Excellence]
4: https://alistaircockburn.com/Everything-else
5: https://itequia.com/en/domain-driven-design-what-is-it-and-how-to-apply-it-in-my-organization/
6: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
7: https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/