Caso de uso de la arquitectura hexagonal
En este tutorial, implementaremos una simple aplicación Java CMS con un consumidor CLI utilizando los principios de la Arquitectura Hexagonal. La idea principal será mantener la lógica de negocio lo más separada posible y utilizar el principio de Inversión de Dependencia que es la “D” del principio SOLID para evitar el acoplamiento entre capas.
Es una forma de diseñar una arquitectura de aplicación de software alrededor de la lógica de negocio y desacoplarla de otras capas. El desacoplamiento se realiza mediante el uso de puertos y adaptadores, por lo que la Arquitectura Hexagonal también se denomina Puertos y Adaptadores.
Las aplicaciones consisten en uno o más casos de uso, y se pueden utilizar puertos como una dependencia dentro de estos casos de uso mientras se definen los pasos para cumplir con los requisitos en términos de lógica de negocio. Aquí decimos puertos ya que los consumidores no los usarán directamente, se usará la implementación en su lugar.
Dentro de la clase ArticleRetrieveUseCase, tenemos una función de caso de uso de recuperación y utiliza ArticlePort y nunca sabe cuál es la implementación real ya que no depende de una implementación concreta.
Arquitectura hexagonal de microservicios
DDD no tiene ninguna restricción sobre las clases que pueden referenciarse entre sí o no. En el libro, los ejemplos de DDD utilizan una arquitectura tradicional en capas, pero el libro también establece que DDD puede ser utilizado junto con cualquier otra arquitectura de software. Si quieres usar una arquitectura hexagonal también está bien.
La arquitectura hexagonal divide la aplicación en 3 capas concéntricas: adaptadores, puertos, negocio. La arquitectura hexagonal también establece que las referencias sólo se permiten hacia el interior. Esto significa que los adaptadores pueden hacer referencia a los puertos y al negocio, los puertos pueden hacer referencia al negocio, y el negocio no puede hacer referencia a otra capa. En esta situación, es totalmente lícito referenciar y llamar a tu capa de negocio desde tu adaptador. Lo que rompería el patrón es pasar una referencia al puerto o al adaptador al modelo de negocio.
Ejemplo de arquitectura hexagonal java spring boot
El término “Arquitectura Hexagonal” ha existido durante mucho tiempo. Lo suficiente como para que la fuente principal sobre este tema haya estado fuera de línea por un tiempo y sólo recientemente haya sido rescatada de los archivos.
Sin embargo, he encontrado que hay muy pocos recursos sobre cómo implementar realmente una aplicación en este estilo de arquitectura. El objetivo de este artículo es proporcionar una forma opinable de implementar una aplicación web en el estilo hexagonal con Java y Spring.
El hexágono es sólo una forma elegante de describir el núcleo de la aplicación que se compone de objetos de dominio, casos de uso que operan sobre ellos, y puertos de entrada y salida que proporcionan una interfaz con el mundo exterior.
En un dominio rico en reglas de negocio, los objetos de dominio son el alma de una aplicación. Los objetos de dominio pueden contener tanto estado como comportamiento. Cuanto más cerca esté el comportamiento del estado, más fácil será entender, razonar y mantener el código.
Como los objetos de dominio no tienen dependencias de otras capas de la aplicación, los cambios en otras capas no les afectan. Pueden evolucionar sin dependencias. Este es un excelente ejemplo del Principio de Responsabilidad Única (la “S” de “SOLID”), que establece que los componentes deben tener una sola razón para cambiar. En el caso de nuestro objeto de dominio, esta razón es un cambio en los requisitos empresariales.
Arquitectura hexagonal spring boot ejemplo github
El principio de la arquitectura hexagonal fue creado por Alistair Cockburn en 2005. Es una de las muchas formas de DDD (Domain Driven Design Architecture). El objetivo era encontrar una manera de resolver o mitigar de alguna manera las advertencias generales introducidas por la programación orientada a objetos. También se conoce como arquitectura de puertos y adaptadores. El concepto de hexágono no está relacionado con una arquitectura de seis lados ni tiene nada que ver con la forma geométrica. Un hexágono tiene seis lados de hecho, pero la idea es ilustrar el concepto de muchos puertos. Además, esta forma es más fácil de dividir en dos y de utilizar como representación de la lógica de negocio de la aplicación. La idea es separar la aplicación que queremos desarrollar en tres partes distintas. La izquierda, el núcleo y la derecha. Desde un concepto aún más amplio queremos diferenciar los conceptos de dentro y fuera. El interior es la lógica de negocio y la aplicación en sí misma y el exterior es lo que estamos utilizando para conectar e interactuar con la aplicación.
El núcleo de una aplicación puede definirse como el lugar donde ocurre la lógica de negocio de la aplicación. El núcleo de una aplicación recibe datos, realiza operaciones sobre ellos y opcionalmente puede comunicarse con otros componentes externos como bases de datos o entidades de persistencia.