En cliquant sur "Accepter", vous acceptez que des cookies soient stockés sur votre appareil afin d'améliorer la navigation sur le site, d'analyser l'utilisation du site et de nous aider dans nos efforts de marketing.

Architecture Event-Driven et Design Patterns : Savoir quand exploiter SAGA, CQRS et DDD

skiils Fantôme Data
Blog
>
Architecture Event-Driven et Design Patterns : Savoir quand exploiter SAGA, CQRS et DDD
Archii
3/9/2024

Dans le monde dynamique du développement logiciel, l'architecture orientée événements (Event-Driven Architecture ou EDA) et les patterns de conception jouent un rôle crucial en permettant des systèmes réactifs et performants.

Parmi les nombreux modèles disponibles, SAGA, Command Query Responsibility Segregation (CQRS) et Domain-Driven Design (DDD) se distinguent. Bien que ces patterns puissent coexister dans un système complexe, ils ont des rôles, des responsabilités et des impacts différents sur l'architecture d'une application.

 

1. SAGA Pattern

Le pattern SAGA est une approche pour gérer la cohérence des données dans un environnement de microservices, où chaque service gère sa propre base de données. Les sagas sont essentielles dans les systèmes distribués pour maintenir la cohérence des transactions qui s'étendent sur plusieurs services. Une saga est une séquence d'actions ou d'événements liés entre eux. Si une action échoue, la saga définit des compensations pour annuler ou ajuster les actions précédentes.

·       Caractéristiques principales :

Transaction Distribuée : Chaque étape de la saga est une transaction en elle-même, ce qui peut conduire à une cohérence finale plutôt qu'à une cohérence immédiate.

Compensation: Si une transaction échoue, les actions précédentes sont compensées par des transactions qui annulent ou corrigent les effets.

Communication Asynchrone : Les sagas utilisent souvent la communication asynchrone pour orchestrer les transactions entre différents services.

·       Applications typiques de SAGA :

Gestion des transactions complexes à travers des microservices où chaque service gère ses propres données de manière autonome.

Scénarios nécessitant des compensations en cas d'échec, comme dans les systèmes de réservation ou de commande.

 

2. CQRS(Command Query Responsibility Segregation)

CQRS est un pattern de conception qui sépare les opérations de lecture des données (queries) des opérations de mise à jour (commands). Ce découplage permet de traiter plus efficacement les demandes de lecture et d'écriture, optimisant ainsi les performances et l'évolutivité du système.

·       Caractéristiques principales :

Séparation des responsabilités : Divise clairement la logique de gestion des commandes de celle des requêtes, permettant d'optimiser chaque aspect indépendamment.

Flexibilité: Permet d'avoir différents modèles de données pour la lecture et l'écriture, ce qui peut simplifier la complexité et améliorer les performances de chaque opération.

Évolutivité : Améliore l'évolutivité du système en permettant à la charge de lecture et d'écriture d'être gérée séparément.

·       Applications typiques de CQRS :

Systèmes avec des exigences claires de performance et de scalabilité distinctes entre les lectures et les écritures.

Applications où la séparation des modèles de lecture et d'écriture peut aider à optimiser les requêtes et simplifier la gestion de la cohérence des données.

 

3. DDD (Domain-Driven Design)

Le Domain-Driven Design est une approche de conception logicielle centrée sur le domaine et la logique métier. DDD vise à aligner le développement logiciel avec les besoins métier complexes en mettant l'accent sur la compréhension du domaine.

·       Caractéristiques principales :

Modélisation du domaine : Se concentre sur la création d'un modèle riche et explicite du domaine métier.

Ubiquitous Language : Utilise un langage commun entre les développeurs et les experts métier pour assurer une compréhension et une communication claires.

Sous-domaines : Divise le domaine complexe en sous-domaines plus gérables, chacun traité comme un module distinct.

·       Applications typiques de DDD :

Projets complexes où les règles métier sont évolutives et où le domaine nécessite une modélisation détaillée.

Environnements où la collaboration entre les experts du domaine et les développeurs est cruciale pour le succès du projet.

 

Bilan : pour profiter des avantages de chaque Design Patterns, des Synergies sont possibles

SAGA et DDD : Les sagas peuvent être utilisées dans le cadre de DDD pour gérer les transactions distribuées au sein des sous-domaines. Cela permet d'assurer l'intégrité transactionnelle tout en maintenant une modélisation centrée sur le domaine.

CQRS et DDD : CQRS peut être mis en œuvre dans un système utilisant DDD pour séparer les traitements de lecture et d'écriture au niveau du domaine. Cela optimise les interactions avec le domaine en fonction de la nature de la demande (commande ou requête).

SAGA et CQRS : Les sagas peuvent orchestrer des commandes dans un système utilisant CQRS, gérant les transactions et les compensations à travers des commandes distinctes et des modèles de requêtes.

Maelle
Maelle
Chargée de Communication