VOLVER
Explore el poder de la Arquitectura Hexagonal para mejorar la mantenibilidad, comprobabilidad y adaptabilidad del software.
En esta completa guía, profundizaremos en los matices de Arquitectura hexagonalEl objetivo es analizar su definición, sus componentes y su historia. Estableceremos comparaciones entre Arquitectura hexagonal y otros patrones arquitectónicos populares para destacar sus puntos fuertes únicos. Además, examinaremos su papel fundamental en el diseño basado en dominios (DDD) y los microservicios, que son cada vez más importantes en el mundo de la tecnología moderna. desarrollo de software.
En el dinámico panorama de arquitectura de software, Arquitectura hexagonaltambién conocida como la Patrón de adaptadoresha surgido como un formidable contendiente, desafiando progresivamente las normas de la arquitectura tradicional por capas.
Impulsado por la necesidad de un diseño arquitectónico que pudiera garantizar la facilidad de las pruebas y una mayor mantenibilidad, Arquitectura hexagonal fue concebida. Su misión: proporcionar aplicaciones informáticas ajeno a las complejidades y veleidades del mundo exterior.
A lo largo de este artículo, nos embarcaremos en un viaje a través de los anales del Arquitectura hexagonal - una arquitectura que se sitúa en el nexo entre simplicidad y poder. Desentrañaremos su historia, estructura y principios, y la compararemos con otras arquitecturas. patrones arquitectónicos. Examinaremos su potencial para elevar la calidad de las aplicaciones informáticas y reducir la creciente marea de deuda técnica que asedia a la industria del software.
En el fondo, Arquitectura hexagonalo los Puertos y Arquitectura de los adaptadoreses un patrón de diseño basado en la segregación de preocupaciones. Divide una aplicación en dos secciones principales: el interior y el exterior.
El interior, también denominado núcleo de la aplicación, alberga el lógica empresarial y objetos de dominio: el núcleo de valor de su software. Este santuario interior se mantiene al margen de influencias externas, preservando así la integridad del lógica empresarial y el modelo de dominio.
El exterior, por su parte, es el reino de los sistemas externos -del interfaz de usuario hasta el acceso a la base de datos- que interactúan con el núcleo de la aplicación. Estas interacciones se gestionan a través de un mecanismo de puertos y adaptadores, que garantiza una separación limpia entre el núcleo de la aplicación y la base de datos. núcleo de la aplicación y sus actores externos.
Arquitectura hexagonal es una idea original de Alistair Cockburn, un visionario que articuló por primera vez este concepto como respuesta a las limitaciones de la tecnología tradicional. arquitectura en capas. Se diseñó para crear una tecnología agnóstica. capa de dominio que aísla el núcleo lógica empresarial de influencias externas, como la interfaz de usuario código y acceso a bases de datos.
En la tradición arquitectura en capasLos cambios en una capa podían propagarse a otras y tener consecuencias imprevistas. Además, las pruebas se complicaban por las intrincadas dependencias entre capas.
Arquitectura hexagonal surgió como solución, ofreciendo un modelo en el que los cambios en una parte del sistema no desestabilizarían las demás partes. En esencia, se trataba de lógica empresarial de que se accediera a él a través de una interfaz web, un API RESTo incluso un línea de comandos.
Arquitectura hexagonal, llamado así por su ilusión hexagonal en las representaciones diagramáticas, consta de tres componentes básicos: el modelo de dominiopuertos (primarios y secundarios) y adaptadores (primarios y secundarios).
En modelo de dominio es el corazón de la aplicación de software, encapsulando el normas empresariales y la lógica central. Los objetos de dominio que residen en este modelo contienen valores y reglas empresariales específicos.
A continuación, tenemos los puertos, conductos entre el modelo de dominio y el mundo exterior. Puertos principales exponer la aplicación lógica empresarialque sirven de puerta de entrada al núcleo de la aplicación. Representan los casos de uso que admite la aplicación.
Puertos secundariospor otro lado, están orientadas al exterior. Representan interfaces que la aplicación necesita del mundo exterior, como capas de persistencia o servicios externos.
Por último, tenemos los adaptadores, que actúan como traductores entre el modelo de dominio y el mundo exterior. Convierten los datos del formato utilizado por sistemas externos al formato utilizado por el lógica empresarialy viceversa.
Puertos y adaptadores forman el puente entre el núcleo de la aplicación y los actores externos. Los puertos primarios representan los casos de uso de negocio que la aplicación expone, permitiendo a los actores externos interactuar con la aplicación. Piense en ellos como las interfaces de servicio en su capa empresarial.
Los puertos secundarios, por su parte, son interfaces que tu aplicación necesita del mundo exterior. Pueden ser servicios como acceso a bases de datos, servicios web o incluso servicios de tiempo. Exponen lo que necesita la aplicación, independientemente de cualquier tecnología o características específicas del proveedor.
Los adaptadores son las manifestaciones físicas de estos puertos. Traducen los datos del formato utilizado por el lógica empresarial al formato utilizado por los actores externos y viceversa. Estos adaptadores pueden ser conversores de adaptadores específicos de la tecnología para API REST, bases de datos SQL o sistemas de mensajería, pero también pueden ser secuencias de comandos por lotes o interfaz de usuario código. Los adaptadores forman el límite de la aplicación, lo que permite que ésta sea independiente de la tecnología.
Los puertos primarios representan las operaciones que nuestra aplicación puede realizar - los comandos que nuestro dominio central puede aceptar. A menudo se implementan como interfaces en lenguajes como Javadefiniendo qué operaciones ofrece la aplicación.Adaptadores primariospor lo tanto, son las implementaciones de estas interfaces para actores externos específicos.
Por otro lado, los puertos secundarios son interfaces que el dominio principal utiliza para interactuar con el mundo exterior. Pueden incluir interfaces para persistir objetos del dominio o enviar notificaciones. Adaptadores secundarios son las implementaciones reales de estas interfaces - un Base de datos SQL o un adaptador de notificaciones por correo electrónico, por ejemplo.
Juntos, los puertos y adaptadores primarios y secundarios forman una frontera flexible y modular alrededor de la aplicación, separando el lógica de dominio de las preocupaciones técnicas. Imponen una separación clara de responsabilidades y permiten que distintas partes del sistema evolucionen de forma independiente.
La regla de la dependencia es un principio fundamental en Arquitectura hexagonal que establece que las dependencias deben apuntar hacia dentro, hacia el núcleo de la aplicación. El núcleo de la aplicación no depende de ninguna base de datos en particular, interfaz de usuario o cualquier otro organismo externo.
Este principio está estrechamente relacionado con el Principio de inversión de la dependencia (DIP), uno de los principios SOLID de diseño orientado a objetos. El DIP establece que los módulos de alto nivel (lógica empresarial o capa de dominio no debería depender de módulos de bajo nivel (como el adaptador de base de datos). En su lugar, ambos deberían depender de abstracciones. Esta inversión de las dependencias permite aislar los módulos de alto nivel de los cambios en los módulos de bajo nivel, fomentando un diseño en el que el lógica empresarial impulsa la arquitectura global.
La cartografía es un proceso esencial en Arquitectura hexagonalen el que un adaptador específico de la tecnología convierte los datos del formato utilizado por sistemas externos a un formato que nuestro capa de dominio puede entender. Este mapeo facilita la traducción entre las representaciones interna y externa de los datos de la aplicación.
Por ejemplo, cuando una petición HTTP llega a nuestra aplicación desde una interfaz externa como un API RESTLos datos de la solicitud deben traducirse de JSON a objetos de dominio que la aplicación pueda utilizar. Esta traducción es responsabilidad de los adaptadores.
A la inversa, cuando la aplicación necesita enviar una respuesta, los adaptadores volverían a convertir los objetos de dominio en JSON. Esto permite que la aplicación central permanezca ignorante de las especificidades del mundo externo, al tiempo que garantiza que puede interpretar correctamente los datos entrantes y formatear los salientes.
Arquitectura hexagonal ofrece una gran cantidad de ventajas, que pueden atribuirse en gran medida a su desacoplamiento de las aplicaciones informáticas de sus elementos externos y a la clara delimitación entre las distintas partes de un sistema.
Una de las ventajas fundamentales es la separación de preocupaciones, que favorece el mantenimiento y la legibilidad del código. El desacoplamiento del núcleo lógica empresarial del mundo exterior permite cambios en los adaptadores, bases de datos y interfaces de usuario sin alterar el núcleo lógica empresarial.
Arquitectura hexagonal también destaca en el ámbito de la comprobabilidad. El aislamiento de dependencias externas de la arquitectura permite a los desarrolladores ejecutar pruebas de regresión automatizadas y escribir suites de pruebas automatizadas más fácilmente. Este aislamiento mejora la resistencia de la aplicación, ya que los cambios en un componente no afectarán negativamente a los demás.
Además, la arquitectura admite varios adaptadores para el mismo puerto, lo que abre la puerta a varios adaptadores para el mismo puerto secundario. Esta flexibilidad permite a la aplicación interactuar con distintos tipos de bases de datos o soportar varias interfaz de usuario plataformas.
En el ámbito del desarrollo de software, la capacidad de mantenimiento suele ser una característica muy buscada, pero los estilos arquitectónicos tradicionales pueden tener dificultades para ofrecerla. Arquitectura hexagonal destaca aquí por su gran énfasis en la mantenibilidad.
Centrándose en la separación de preocupaciones, Arquitectura hexagonal garantiza que los cambios realizados en una parte de la aplicación no afecten a otras partes. Este rasgo ayuda a reducir el tiempo y el esfuerzo dedicados a comprender y depurar el código.
Además, la arquitectura fomenta la reutilización del código promoviendo un diseño en el que el núcleo lógica empresarial está aislada de las tecnologías específicas utilizadas para impulsar la aplicación. Este desacoplamiento permite a los desarrolladores cambiar, actualizar o refactorizar las aplicaciones. interfaces externas sin afectar a la lógica central, lo que reduce el riesgo de introducir errores.
La deuda técnica, una preocupación importante en el desarrollo de software, se refiere al coste futuro de la refactorización y la corrección de atajos y hacks en el código. Arquitectura hexagonal ofrece un enfoque proactivo para mitigar dicha deuda.
Al facilitar una separación clara entre el núcleo lógica empresarial y componentes externos, Arquitectura hexagonal reduce la probabilidad de código entrelazado que puede causar dolores de cabeza de mantenimiento y agravar la deuda técnica. La mantenibilidad y comprobabilidad inherentes a la arquitectura también contribuyen a reducir la deuda técnica, ya que ayudan a evitar la introducción de errores y facilitan los esfuerzos de refactorización.
Además, la capacidad de Arquitectura hexagonal para soportar cambios en la infraestructura sin necesidad de cambios en el lógica empresarial proporciona un amortiguador protector contra la deuda técnica. Esta capacidad permite a los equipos adaptarse a los cambios en los requisitos o las tecnologías sin tener que reescribir grandes partes de la aplicación.
En la práctica, Arquitectura hexagonal aporta un enfoque estructurado al desarrollo de software. El límite hexagonal en torno a la aplicación central proporciona una demarcación clara de dónde termina la aplicación y el mundo exterior comienza.
Los adaptadores actúan como guardianes, traduciendo las peticiones de los actores externos a un formato que la aplicación central pueda entender, y viceversa. De este modo, se aseguran de que la aplicación central siga siendo agnóstica a las especificidades del mundo exterior, ya sea una base de datos, un servidor o una red. API externao un interfaz de usuario.
El Diseño Orientado al Dominio (DDD) es una metodología de desarrollo de software que da prioridad a los conceptos empresariales centrales, o a los lógica de dominiocomo motor principal del diseño. Esta metodología se ajusta notablemente a Arquitectura hexagonalque también subraya la importancia de la lógica empresarial y el modelo de dominio en la arquitectura.
En el contexto de Arquitectura hexagonalDDD garantiza que los módulos de alto nivel de la aplicación -las capas de dominio- sean independientes de los elementos externos, como el interfaz de usuario o la base de datos. Esta independencia está garantizada por los puertos y adaptadores, que protegen a la capa de dominio de las especificidades de la base de datos. sistemas externoslo que permite lógica de dominio evolucionar de forma independiente.
Además, Arquitectura hexagonal complementa los principios de diseño estratégico de DDD, incluido el concepto de contextos delimitados. Cada contexto delimitado en DDD puede imaginarse como un hexágono en Arquitectura hexagonalcon el modelo de dominio como núcleo y el puertos y adaptadores actuando como límites.
Los microservicios, otro estilo arquitectónico contemporáneo, pueden beneficiarse enormemente de Arquitectura hexagonal. La naturaleza descentralizada de los microservicios -en los que cada servicio encapsula una capacidad empresarial específica- encaja perfectamente con la encapsulación de lógica empresarial dentro del núcleo del hexágono.
Al igual que cada microservicio debe estar débilmente acoplado a los demás, cada hexágono en Arquitectura hexagonal también está aislado de los demás, comunicándose únicamente a través de los puertos y adaptadores definidos. Esto permite que cada microservicio tenga su propio arquitectura hexagonalEl resultado es un conjunto de servicios autónomos y débilmente acoplados.
El aislamiento proporcionado por Arquitectura hexagonal puede ser especialmente útil cuando se trata de la complejidad y la naturaleza distribuida de los microservicios. Al aislar los lógica empresarial central del mundo exterior, Arquitectura hexagonal garantiza la lógica empresarial permanece intacta, independientemente de los cambios en otros servicios o sistemas externos.
La forma en que se diseña un programa informático puede influir mucho en su evolución a lo largo del tiempo. Comparación de Arquitectura hexagonal a otras arquitecturas nos da una comprensión más profunda de sus puntos fuertes y posibles compensaciones.
Arquitectura por capas es una tradición patrón arquitectónico que estructura una aplicación en capas lógicas, a menudo capas de presentación, negocio y acceso a datos. El principal inconveniente de este patrón es que fomenta una fuerte dependencia entre las capas, lo que lleva a una situación en la que los cambios en una capa pueden extenderse a toda la aplicación.
Por el contrario, Arquitectura hexagonal minimiza estas dependencias. En lugar de capas, tiene un núcleo de la aplicación rodeado de adaptadores intercambiables. Los cambios en un servidor de base de datos, por ejemplo, sólo afectarían al adaptador correspondiente, dejando el núcleo de la aplicación y otros adaptadores intactos.
Arquitectura limpiaotra patrón arquitectónicocomparte muchas similitudes con Arquitectura hexagonal. Ambas hacen hincapié en la separación de preocupaciones, pretenden aislar el núcleo normas empresariales de detalles externos, y se adhieren a la Principio de inversión de la dependencia.
Sin embargo, Arquitectura hexagonal se centra más en cómo interactúa la aplicación con el fuera de mundo mediante puertos y adaptadores, mientras que Arquitectura limpia proporciona una estructura más detallada de las capas internas de la arquitectura. Dicho de otro modo, Arquitectura limpia puede considerarse un superconjunto de Arquitectura hexagonalcon orientaciones adicionales sobre la organización de la estructura interna de la aplicación.
Arquitectura de la cebolla es otro estilo arquitectónico que pretende aislar el lógica empresarial central del interfaces externas e infraestructura. Tiene varias capas concéntricas con el modelo de dominio en el centro, y cada capa sólo puede depender de las capas de su interior.
Aunque comparten un objetivo común, Hexagonal y Arquitectura de la cebolla conseguirlo de formas ligeramente diferentes. Arquitectura de la cebolla pone mucho énfasis en la dirección de las dependencias, asegurándose de que todas las dependencias vayan hacia dentro. Arquitectura hexagonalaunque también respalda las dependencias hacia el interior, hace mayor hincapié en la interacción con el mundo exterior a través de sus puertos y adaptadores.
Uno de los puntos fuertes de Arquitectura hexagonal es su enfoque en la comprobabilidad. Al aislar el núcleo de la aplicación del mundo exterior a través de puertos y adaptadores, la Arquitectura Hexagonal permite la ejecución de pruebas automatizadas que pueda proporcionar confianza en la estabilidad y corrección del software.
En un Arquitectura hexagonalEl puertos primariosque encapsulan el núcleo normas empresarialespuede probarse independientemente del mundo exterior. Por ejemplo, en lugar de comunicarse con una base de datos real durante las pruebas, un adaptador de base de datos puede sustituirse por un doble de prueba que simule el comportamiento de una base de datos real. Esto permite a los desarrolladores centrarse en probar la normas empresarialesen lugar de la interacción con la base de datos.
Además, pruebas de regresión automatizadas pueden construirse fácilmente para validar que el sistema se comporta como se espera cuando se realizan cambios. Este nivel de comprobabilidad es una ventaja significativa a la hora de mantener y actualizar el software, ya que ayuda a detectar y solucionar problemas en una fase temprana del proceso de desarrollo.
Además, la estructura de Arquitectura hexagonal también admite pruebas de integración. Al sustituir el componentes externos (como un servidor de base de datos o un API externa) con dobles de prueba, los desarrolladores pueden comprobar cómo el núcleo de la aplicación se integra con estos componentes sin tener que utilizar los sistemas externos reales. Esto puede mejorar enormemente la velocidad y fiabilidad de las pruebas.
Arquitectura hexagonal surge como una solución atractiva en la vasta extensión de las estrategias de desarrollo de software. Se distingue por desacoplar la núcleo de la aplicación del entorno externo, garantizando así un alto grado de mantenibilidad, comprobabilidad y flexibilidad. Esta separación facilita que los desarrolladores se centren en el núcleo lógica empresarialal tiempo que se refuerza la resistencia del software frente a las alteraciones del sistemas externos.
Aunque la arquitectura hexagonal tiene sus inconvenientes, sus múltiples ventajas la convierten en un activo muy valioso para cualquier desarrollador. En el ámbito de arquitectura de softwareEl modelo hexagonal sigue imponiéndose.
Este artículo, salpicado de ejemplos de códigotiene por objeto proporcionar una comprensión profunda de Arquitectura hexagonal y sus posibles ventajas. Tenga en cuenta que el secreto de una arquitectura eficaz no reside en la adhesión ciega a patrones, sino en comprender los principios subyacentes e implementarlos de forma meditada para satisfacer requisitos específicos.
En el ámbito de la Arquitectura Hexagonal, la interfaz definida entre el capa de aplicación y el capa de datos es de vital importancia. Tanto si es un arquitecto de software considerando adoptar esta metodología, o un desarrollador que se esfuerza por comprender sus complejidades, está claro que la influencia de esta arquitectura sigue creciendo. Demuestra diversas formas en que puede utilizarse eficazmente. Por ejemplo, en un banca aplicaciónEl interfaz de repositorio puede actuar como adaptador secundario, puenteando el núcleo de la aplicación con código externo. Esta separación permite intercambiar aplicación concreta de un sistema de archivos o una tecnología específica, sin afectar a los servicios de la aplicación.
En desarrollo equipo ya puede trabajar en el lado izquierdo de la aplicación sin preocuparse de factores externosy así garantizar un progreso fluido. Y así concluimos nuestra exploración del mundo del Arquitectura hexagonalun estilo arquitectónico que sigue extendiendo su influencia por todo el panorama del desarrollo de software.
Spanish 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Polish 
Arabic 
Italian 
Japanese 
Korean 
Dutch