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

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 :

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 :

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.

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.

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.

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.

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) :

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...