¡Acceso ilimitado 24/7 a todos nuestros libros y vídeos! Descubra la Biblioteca Online ENI. Pulse aquí
¡Acceso ilimitado 24/7 a todos nuestros libros y vídeos! Descubra la Biblioteca Online ENI. Pulse aquí
  1. Libros
  2. Java Spring
  3. Utilizaciones avanzados
Extrait - Java Spring Construya aplicaciones reactivas con una arquitectura de microservicios en un entorno Jakarta EE
Extractos del libro
Java Spring Construya aplicaciones reactivas con una arquitectura de microservicios en un entorno Jakarta EE Volver a la página de compra del libro

Utilizaciones avanzados

Introducción

En esta exploración de las arquitecturas de aplicaciones reactivas, destacamos una serie de elementos clave que encontramos con frecuencia a la hora de ejecutar proyectos. Revisamos y profundizamos en una serie de conceptos que sustentan estas arquitecturas, aunque aquí sólo podemos rozar la superficie de su complejidad. Es esencial estudiar estos temas en detalle, pero de momento nos contentaremos con una visión general para comprenderlos mejor.

Abordaremos estos puntos:

  • Domain-Driven Design(DDD): comprender los principios del diseño de software basado en el dominio para alinear la aplicación con el negocio.

  • Modelado basado en eventos y event sourcing: comprender cómo modelar el dominio utilizando eventos para mantener el estado de la aplicación, mediante el registro de todos los eventos.

  • Event store: comprender el concepto de almacenamiento de eventos en un sistema de eventos y el uso del event sourcing para recuperar el estado.

  • Event storming: un enfoque colaborativo para explorar y modelizar el ámbito empresarial mediante la identificación de eventos y procesos.

  • Arquitectura hexagonal: comprender el principio de separar las preocupaciones utilizando una arquitectura en capas y situando el dominio en el centro.

  • Clean architecture: comprender el modelo de arquitectura que fomenta la independencia entre las entidades lógicas y los detalles técnicos, lo que permite...

Diseño basado en el dominio

El Domain-Driven Design (DDD) es un enfoque de diseño de software propuesto por Eric Evans en su libro Domain-Driven Design: Tackling Complexity in the Heart of Software. El objetivo del DDD es modelar rigurosamente el dominio empresarial y crear un lenguaje común entre expertos funcionales y desarrolladores, conocido como ubiquitouslanguage. Esta visión compartida permite una mejor comprensión de los problemas negocios y la creación de software que refleje fielmente los conceptos y reglas del dominio. En el corazón de DDD está la noción de agregado, que es un conjunto de entidades y value objects tratados como una unidad coherente con una raíz agregada que gestiona las interacciones entre los distintos elementos.

Un objeto valor es un objeto de dominio que representa un valor. Es inmutable, lo que significa que no puede modificarse una vez creado. También es único, lo que significa que no hay dos objetos de valor que tengan los mismos valores.

El agregado es una frontera transaccional y de coherencia que garantiza el respeto de las invariantes de negocio durante las operaciones de modificación. El DDD también fomenta el uso de modelos ricos en funcionalidades, basados en una estrecha colaboración entre los expertos de negocio y los desarrolladores. El modelo se codifica en el código fuente de la aplicación y debe ser comprensible para los propios expertos de negocio. Además de los agregados, el DDD propone otros conceptos tales como entidades, los value objects, los domain events, los factories, los domain services y los applications services. Cada uno de estos elementos desempeña un papel específico en la construcción del modelo y la gestión del dominio de negocios. DDD se utiliza a menudo en el contexto de proyectos complejos en los que una comprensión profunda del dominio de negocio es crucial para el éxito del proyecto. Fomenta un enfoque iterativo e incremental, que permite refinar el modelo a lo largo del tiempo.

El Domain-Driven Design es un potente...

Arquitectura hexagonal y clean architecture

La clean architecture y la arquitectura hexagonal son dos enfoques de la arquitectura de software que pretenden crear aplicaciones bien estructuradas, modulares y fáciles de mantener. Aunque tienen orígenes y conceptos distintos, comparten un objetivo común: aislar el núcleo funcional de la aplicación de la lógica técnica para crear sistemas escalables y comprobables.

La clean architecture, popularizada por Robert C. Martin, también conocido como Uncle Bob, se basa en el principio de separación de preocupaciones y en la independencia de las distintas capas de la aplicación. Esta arquitectura se basa en el principio de dependency rule, que estipula que las dependencias deben apuntar siempre hacia dentro, es decir, las capas internas no deben conocer los detalles de implementación de las capas externas. La clean arquitecture se compone de cuatro círculos concéntricos:

  • El círculo más interno representa el núcleo de la aplicación, que contiene la lógica de negocio y las reglas del dominio. Este círculo es independiente de cualquier tecnología externa y puede probarse de forma aislada.

  • El siguiente círculo representa las interfaces, también conocidas como adaptadores, que definen los contratos entre el núcleo de la aplicación y las capas externas. Esto permite separar...

CQRS

El CQRS (Command Query Responsibility Segregation) es un modelo arquitectónico que se utiliza a menudo en el contexto de las aplicaciones reactivas. Su objetivo es separar las operaciones de lectura(queries) y las operaciones de escritura(commands), utilizando diferentes patrones de diseño para cada uno. La idea principal de CQRS es optimizar el rendimiento y la escalabilidad de la aplicación gestionando por separado los requisitos de lectura y escritura.

En una aplicación reactiva, que normalmente maneja grandes cantidades de datos y flujos de eventos asíncronos, CQRS adquiere especial relevancia. A continuación, se explica cómo funciona CQRS en las aplicaciones reactivas:

  • Separación de responsabilidades: CQRS divide las responsabilidades utilizando dos modelos distintos. Por un lado, tenemos el modelo de consulta(query), que gestiona las operaciones de lectura y responde a las solicitudes de datos. Por otro, tenemos el modelo de comandos(command), que se encarga de las operaciones de escritura y modifica el estado de la aplicación.

  • Modelo de consulta(Query): el modelo de consulta se encarga de recuperar y presentar los datos a los usuarios. Está optimizado para las operaciones de lectura utilizando estructuras de datos adaptadas a las necesidades específicas de las consultas. Este modelo puede desplegarse en varios nodos de lectura para mejorar el rendimiento distribuyendo la carga.

  • Modelo...

Sagas

En el contexto de las aplicaciones reactivas, las sagas son un modelo de coordinación para gestionar transacciones e interacciones entre varios servicios distribuidos. Las sagas se utilizan para mantener la coherencia de los datos y las acciones en un entorno distribuido en el que las operaciones son asíncronas y pueden fallar.

Una saga es esencialmente una secuencia de transacciones o etapas que pueden ejecutarse de forma fiable y coherente para realizar una tarea compleja en la que intervienen varios servicios. Cada paso de la saga representa una acción que debe realizarse en un servicio específico. Si un paso falla, la saga debe poder volver atrás y deshacer los pasos anteriores (esta acción se denomina "compensación") para garantizar la coherencia del sistema.

En el contexto de las aplicaciones reactivas, las sagas son especialmente útiles porque permiten gestionar las operaciones distribuidas de forma descentralizada y asíncrona, manteniendo la coherencia global del sistema. Las aplicaciones reactivas se despliegan a menudo en arquitecturas de microservicios, donde cada microservicio es responsable de una parte específica de la lógica de negocio. Las interacciones entre estos microservicios pueden ser complejas y deben gestionarse cuidadosamente para evitar incoherencias y errores.

Las sagas pueden utilizarse de diversas formas en aplicaciones reactivas, como:

  • Modelo de coordinación:...

Evolución de las arquitecturas

La arquitectura de una aplicación evoluciona a medida que aumentan el tráfico y las necesidades. Al principio se suele utilizar un enfoque monolítico, pero rápidamente resulta difícil de mantener y evolucionar.

Al utilizar una arquitectura por capas, el código está mejor organizado, pero persisten los problemas de rendimiento.

images/figura9.1.png

En segundo lugar, la arquitectura evoluciona hacia un enfoque CQRS, separando la parte de escritura de la de lectura, lo que permite una mejor gestión de las solicitudes y comandos.

images/figura9.2.png

El uso de un bus de control y un bus de eventos facilita la comunicación entre las distintas partes de la aplicación y garantiza cierto grado de redundancia de los datos.

images/figura9.3.png

El siguiente paso es introducir un event store para guardar el historial de modificaciones de los datos, lo que permitirá reconstruir el estado final de los objetos a partir de su estado inicial y las modificaciones sucesivas.

images/figura9.4.png

Por último, la arquitectura está evolucionando hacia un enfoque de streaming, en el que microservicios especializados utilizan flujos de datos para comunicarse entre sí, reduciendo así el flujo y el impacto de los cambios.

Este proceso evolutivo muestra cómo la arquitectura de una aplicación puede adaptarse gradualmente para satisfacer las crecientes necesidades de tráfico y funcionalidad. Cada etapa representa un enfoque...

Elementos de implementación

Existen varios módulos de Spring que pueden ayudarle a desarrollar aplicaciones reactivas, como:

  • Spring WebFlux: módulo principal para la programación reactiva en Spring, utilizado para crear aplicaciones web reactivas basadas en flujos y eventos.

  • Spring Reactive Streams: proporciona implementaciones para las interfaces reactivas del proyecto Reactor, así como flujos reactivos para la comunicación asíncrona entre componentes.

  • Spring Data Reactive: amplía Spring Data ofreciendo características reactivas para operaciones de persistencia de datos con bases de datos reactivas como MongoDB y Cassandra.

  • Spring WebClient: cliente HTTP reactivo, permite realizar llamadas HTTP de manera reactiva y no bloqueante.

  • Spring Cloud Stream: framework para construir aplicaciones de streaming en tiempo real, utilizando enlaces de comunicación basados en canales. Integra plataformas de streaming como Apache Kafka y RabbitMQ.

  • Spring Cloud Function: crea funciones reactivas que son independientes de cualquier entorno de ejecución específico, lo que favorece el desarrollo de aplicaciones basadas en eventos y reactivas.

  • Spring Cloud Gateway: módulo de pasarela reactiva para enrutar y filtrar solicitudes de manera reactiva, que ofrece escalabilidad y resistencia mejoradas para aplicaciones basadas en la nube.

  • Spring Security Reactive: extensión reactiva de Spring Security, que protege las aplicaciones reactivas utilizando los principios de la programación reactiva.

  • Spring Session Reactive: permite la gestión reactiva de sesiones de usuario en entornos distribuidos, ofreciendo soporte asíncrono y reactivo.

  • Spring AMQP: proporciona soporte reactivo para mensajería asíncrona basada en el protocolo Advanced Message Queuing Protocol (AMQP).

  • Spring Integration: módulo que facilita la integración de sistemas heterogéneos y la comunicación entre aplicaciones mediante mensajes asíncronos y canales reactivos.

  • Spring State Machine: un módulo de Spring que puede ser útil para desarrollar aplicaciones reactivas, en particular cuando se necesita gestionar el estado y el comportamiento de la aplicación en función de eventos.

Utilizando estos diferentes módulos, los desarrolladores pueden crear aplicaciones reactivas de alto rendimiento, escalables y resistentes...

Conclusión

El ecosistema Spring es extraordinariamente completo para el desarrollo de aplicaciones reactivas. Ofrece una amplia gama de herramientas y módulos diseñados específicamente para satisfacer las necesidades de las aplicaciones reactivas. Ya sea Spring WebFlux para gestionar flujos reactivos, Spring Cloud Stream para comunicaciones asíncronas o Spring State Machine para modelar máquinas de estado, Spring ofrece una solución para cada preocupación relacionada con la reactividad.

Lo que hace que el ecosistema Spring sea aún más atractivo es su coherencia y perfecta integración. Al utilizar diferentes componentes de Spring para aplicaciones reactivas, los desarrolladores pueden permanecer en un ecosistema familiar y centrado en Spring, beneficiándose de una curva de aprendizaje reducida y de una mayor productividad.

Además, Spring tiene en cuenta metodologías específicas de las aplicaciones reactivas, tales como el Domain-Driven Design (DDD), el event sourcing, CQRS y muchas otras. Estos conceptos esenciales se integran en los módulos de Spring para facilitar la aplicación de buenas prácticas de diseño de software y garantizar la fiabilidad y escalabilidad de las aplicaciones reactivas.

Con su completo ecosistema y su compromiso con las aplicaciones reactivas, Spring proporciona a los desarrolladores un entorno propicio para crear aplicaciones...