Blog ENI : Toute la veille numérique !
-25€ dès 75€ sur les livres en ligne, vidéos... avec le code FUSEE25. J'en profite !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Java Spring
  3. Utilisations avancées
Extrait - Java Spring Construisez vos applications réactives avec une architecture micro-services en environnement Jakarta EE (2e édition)
Extraits du livre
Java Spring Construisez vos applications réactives avec une architecture micro-services en environnement Jakarta EE (2e édition) Revenir à la page d'achat du livre

Utilisations avancées

Introduction

Dans cette exploration des architectures d’applications réactives, nous mettons en lumière plusieurs éléments-clés que nous rencontrons fréquemment lors de la mise en œuvre de projets. Nous revisitons et approfondissons un certain nombre de concepts qui sous-tendent ces architectures, bien que nous ne puissions qu’effleurer leur complexité ici. Il est essentiel d’étudier ces sujets en détail, mais pour l’instant, nous nous contentons d’un aperçu général pour mieux les appréhender.

Nous aborderons ces points :

  • Domain-Driven Design (DDD) : comprendre les principes de conception logicielle fondée sur le domaine pour aligner l’application avec le métier.

  • Modélisation événementielle et event sourcing : comprendre la façon de modéliser le domaine en utilisant des événements pour conserver l’état de l’application en enregistrant tous les événements.

  • Event store : comprendre la notion de stockage des événements dans un système d’événement et l’utilisation de l’event sourcing pour la récupération de l’état.

  • Event storming : une approche collaborative pour explorer et modéliser le domaine métier en identifiant les événements...

Domain-Driven Design

Le Domain-Driven Design (DDD) est une approche de conception logicielle proposée par Eric Evans dans son livre Domain-Driven Design: Tackling Complexity in the Heart of Software. L’objectif du DDD est de modéliser le domaine métier de manière rigoureuse et de créer un langage commun entre les experts fonctionnels et les développeurs, ce qu’on appelle l’ubiquitous language. Cette vision partagée permet de mieux comprendre les enjeux métier et de créer des logiciels qui reflètent fidèlement les concepts et les règles du domaine. Au cœur du DDD se trouve la notion d’agrégat, qui est un ensemble d’entités et de value objects traités comme une unité cohérente avec une racine d’agrégat qui gère les interactions entre les différents éléments.

Un value object est un objet du domaine qui représente une valeur. Il est immutable, c’est-à-dire qu’il ne peut pas être modifié une fois créé. Il est également unique, c’est-à-dire qu’il n’y a pas deux value objects avec les mêmes valeurs.

L’agrégat est une frontière transactionnelle et de cohérence qui garantit que les invariants métier sont respectés lors des opérations de modification. Le DDD encourage également l’utilisation de modèles riches en fonctionnalités, fondés sur la collaboration étroite entre les experts métier et les développeurs. Le modèle est codifié dans le code source de l’application et devrait être compréhensible par les experts métier eux-mêmes. Outre les agrégats, le DDD propose d’autres concepts tels que les entités, les value objects, les domain events, les factories, les domain services et les applications services. Chacun de ces éléments joue un rôle spécifique dans la construction du modèle et la gestion du domaine métier. Le DDD est souvent utilisé dans le contexte de projet complexe où la compréhension profonde du domaine métier est cruciale pour le succès du projet. Il encourage une approche itérative et incrémentale, permettant au modèle...

Architecture hexagonale et clean architecture

La clean architecture et l’architecture hexagonale sont deux approches d’architecture logicielle qui visent à créer des applications bien structurées, modulaires et faciles à maintenir. Bien qu’elles aient des origines et des concepts différents, elles possèdent un objectif commun : isoler le cœur fonctionnel de l’application de la logique technique pour créer des systèmes évolutifs et testables.

La clean architecture, popularisée par Robert C. Martin, également connu sous le nom d’Uncle Bob, repose sur le principe de séparation des préoccupations et sur l’indépendance des différentes couches de l’application. Cette architecture est fondée sur le principe du dependency rule, qui stipule que les dépendances doivent toujours pointer vers l’intérieur, c’est-à-dire que les couches internes ne doivent pas connaître les détails d’implémentation des couches externes. La clean architecture se compose de quatre cercles concentriques :

  • Le cercle le plus à l’intérieur représente le cœur de l’application, qui contient la logique métier et les règles de domaine. Ce cercle est indépendant de toute technologie externe et peut être testé de manière...

CQRS

Le CQRS (Command Query Responsibility Segregation) est un modèle architectural qui est souvent utilisé dans le contexte des applications réactives. Il vise à séparer les opérations de lecture (queries) des opérations d’écriture (commands) en utilisant des modèles de conception différents pour chacune d’entre elles. L’idée principale derrière le CQRS est d’optimiser les performances et la scalabilité de l’application en gérant séparément les besoins de lecture et d’écriture.

Dans une application réactive, qui traite généralement de grandes quantités de données et de flux d’événements asynchrones, le CQRS devient particulièrement pertinent. Voici comment le CQRS fonctionne pour les applications réactives :

  • Séparation des responsabilités : le CQRS divise les responsabilités en utilisant deux modèles distincts. D’un côté, nous avons le modèle de requête (query), qui traite les opérations de lecture et répond aux demandes de données. De l’autre côté, nous avons le modèle de commande (command), qui gère les opérations d’écriture et modifie l’état de l’application.

  • Modèle de requête...

Sagas

Dans le contexte des applications réactives, les sagas sont un modèle de coordination pour gérer les transactions et les interactions entre plusieurs services distribués. Les sagas sont utilisées pour maintenir la cohérence des données et des actions dans un environnement distribué où les opérations sont asynchrones et peuvent échouer.

Une saga est essentiellement une séquence de transactions ou d’étapes qui peuvent être exécutées de manière fiable et cohérente pour accomplir une tâche complexe qui implique plusieurs services. Chaque étape de la saga représente une action à effectuer dans un service spécifique. Si une étape échoue, la saga doit être capable de revenir en arrière et d’annuler les étapes précédentes (cette action est appelée « compensation ») pour garantir la cohérence du système.

Dans un contexte d’applications réactives, les sagas sont particulièrement utiles car elles permettent de gérer des opérations distribuées de manière décentralisée et asynchrone, tout en maintenant la cohérence globale du système. Les applications réactives sont souvent déployées sur des architectures microservices...

Évolution des architectures

L’architecture d’une application évolue face à l’augmentation du trafic et des besoins. En général, initialement, une approche monolithique est utilisée, mais elle devient rapidement difficile à maintenir et à faire évoluer.

En passant par une architecture en couches, le code est mieux organisé, mais les problèmes de performances persistent.

images/09-01.png

Ensuite, l’architecture évolue vers une approche CQRS, séparant la partie écriture de la partie lecture, ce qui permet de mieux gérer les requêtes et les commandes.

images/09-02.png

L’utilisation, ensuite, d’un bus de commande et d’un bus d’événements facilite la communication entre les différentes parties de l’application et assure une certaine redondance des données.

images/09-03.png

L’étape suivante consiste à introduire un event store pour stocker l’historique des modifications des données, permettant ainsi de reconstituer l’état final des objets à partir de leur état initial et des modifications successives.

images/09-04.png

Enfin, l’architecture évolue vers une approche en streaming, où des microservices spécialisés utilisent des flux de données pour communiquer entre eux, réduisant ainsi les flux et les impacts des modifications.

Ce processus d’évolution...

Éléments de mise en œuvre

Il y a un certain nombre de modules Spring qui peuvent aider à développer des applications réactives comme (entre autres) :

  • Spring WebFlux : module principal pour la programmation réactive dans Spring, permet de créer des applications web réactives fondées sur des flux et des événements.

  • Spring Reactive Streams : fournit des implémentations pour les interfaces réactives du projet Reactor, ainsi que des flux réactifs pour la communication asynchrone entre composants.

  • Spring Data Reactive : étend Spring Data en offrant des fonctionnalités réactives pour les opérations de persistance de données avec des bases de données réactives comme MongoDB et Cassandra.

  • Spring WebClient : client HTTP réactif, permet d’effectuer des appels HTTP de manière réactive et non bloquante.

  • Spring Cloud Stream : framework pour la construction d’applications de streaming en temps réel, utilise des liens de communication fondés sur des canaux. Il intègre des plateformes de streaming comme Apache Kafka ou RabbitMQ.

  • Spring Cloud Function : permet de créer des fonctions réactives indépendantes de tout environnement d’exécution spécifique, favorisant le développement d’applications événementielles et réactives.

  • Spring Cloud Gateway : module de passerelle réactive pour router et filtrer les requêtes de manière réactive, offre une scalabilité et une résilience améliorées pour les applications basées sur le cloud.

  • Spring Security Reactive : extension réactive de Spring Security, sécurise les applications réactives en utilisant les principes de la programmation réactive.

  • Spring Session Reactive : permet de gérer la session utilisateur de manière réactive dans des environnements distribués, offrant une prise en charge asynchrone et réactive.

  • Spring AMQP : fournit une prise en charge réactive pour la messagerie asynchrone basée sur le protocole AMQP (Advanced Message Queuing Protocol).

  • Spring Integration : module qui facilite l’intégration de systèmes hétérogènes...

Conclusion

L’écosystème de Spring est remarquablement complet pour le développement d’applications réactives. Il propose un large éventail d’outils et de modules conçus spécifiquement pour répondre aux besoins des applications réactives. Que ce soit avec Spring WebFlux pour la gestion de flux réactifs, Spring Cloud Stream pour les communications asynchrones, ou encore Spring State Machine pour la modélisation des machines à états, Spring offre une solution pour chaque préoccupation liée à la réactivité.

Ce qui rend l’écosystème Spring encore plus attrayant, c’est sa cohérence et son intégration harmonieuse. En utilisant les différentes composantes de Spring pour les applications réactives, les développeurs peuvent rester dans un écosystème familier et centré sur Spring, bénéficiant ainsi d’une courbe d’apprentissage réduite et d’une meilleure productivité.

De plus, Spring prend en compte les méthodologies spécifiques aux applications réactives, telles que le Domain-Driven Design (DDD), l’event sourcing, le CQRS, et bien d’autres. Ces concepts essentiels sont intégrés dans les modules de Spring pour faciliter la mise en œuvre de bonnes pratiques...