Architecture d'Event Sourcing : Une Plongée en Profondeur dans les Systèmes de Stockage d'Événements de Domaine

L'Event Sourcing est un modèle architectural où l'état d'une application est déterminé par une séquence d'événements. Au lieu de stocker l'état actuel d'une entité, nous persistons une série d'événements immuables qui représentent les changements apportés à cette entité. Cet article de blog explorera en détail l'architecture d'Event Sourcing, en se concentrant spécifiquement sur les systèmes de stockage d'événements de domaine.

Qu'est-ce que l'Event Sourcing ?

Dans les systèmes traditionnels, l'état actuel d'une entité est directement stocké dans une base de données. Lorsqu'une mise à jour se produit, l'enregistrement existant est modifié ou écrasé. Cette approche fonctionne bien pour de nombreuses applications, mais elle présente des limites lorsque :

• L'audit et le suivi de l'historique sont cruciaux.
• Des transitions d'état complexes doivent être reconstruites.
• La propagation des données en temps réel et les architectures pilotées par les événements sont nécessaires.

L'Event Sourcing répond à ces limitations en stockant chaque changement d'état sous forme d'événement immuable. Ces événements sont persistés dans un magasin d'événements en ajout seul (append-only). Pour reconstruire l'état actuel d'une entité, les événements sont rejoués dans l'ordre où ils se sont produits. Pensez-y comme un grand livre comptable, où chaque transaction est enregistrée, et le solde est calculé en additionnant toutes les transactions.

Concepts Clés

• Événement de Domaine : Un fait représentant quelque chose qui s'est produit dans le domaine. C'est un enregistrement immuable d'un changement d'état. Les exemples incluent OrderCreated, OrderShipped, PaymentReceived.
• Event Store : Un magasin de données en ajout seul (append-only) optimisé pour le stockage et la récupération des événements de domaine. Il fournit des mécanismes pour la persistance, la récupération et l'abonnement aux événements.
• Gestionnaires d'Événements (Event Handlers) : Composants qui réagissent aux événements de domaine. Ils peuvent mettre à jour des modèles de lecture, déclencher des intégrations externes ou effectuer d'autres actions.
• Modèles de Lecture (Read Models) : Des représentations de données dénormalisées optimisées pour des modèles de requêtes spécifiques. Ils sont mis à jour par les gestionnaires d'événements et fournissent une vue en lecture seule des données.
• Snapshotting (Instantané) : Une technique utilisée pour optimiser la reconstruction de l'état en stockant périodiquement l'état actuel d'une entité. Lors de la reconstruction de l'état, le système charge le dernier instantané et ne rejoue que les événements survenus après sa création.

Avantages de l'Event Sourcing

L'Event Sourcing offre plusieurs avantages par rapport aux architectures traditionnelles CRUD (Create, Read, Update, Delete) :

• Piste d'Audit Complète : Chaque changement d'état est enregistré comme un événement, fournissant un historique complet des données de l'application. C'est inestimable pour l'audit, le débogage et la conformité.
• Requêtes Temporelles : La capacité d'interroger l'état d'une entité à n'importe quel moment. Cela permet une analyse historique et des rapports. Par exemple, vous pouvez déterminer le nombre de commandes passées dans une région spécifique à une date donnée.
• Débogage Simplifié : En rejouant les événements, vous pouvez recréer n'importe quel état passé de l'application, ce qui facilite l'identification et la correction des bogues.
• Performances Améliorées pour Certaines Opérations : Bien que la reconstruction de l'état puisse être plus lente, la mise à jour des modèles de lecture peut être hautement optimisée pour des modèles de requêtes spécifiques.
• Architecture Pilotée par les Événements : L'Event Sourcing s'aligne naturellement sur les architectures pilotées par les événements, permettant une propagation des données en temps réel et une intégration avec d'autres systèmes.
• Évolution Facilitée : L'ajout de nouvelles fonctionnalités ou la modification de celles existantes est souvent plus facile car vous pouvez simplement ajouter de nouveaux gestionnaires d'événements sans affecter le flux d'événements existant.
• Scalabilité Améliorée : La distribution du traitement des événements sur plusieurs nœuds peut améliorer la scalabilité et la résilience.

Défis de l'Event Sourcing

L'Event Sourcing présente également certains défis qui doivent être soigneusement examinés :

• Complexité : La mise en œuvre de l'Event Sourcing nécessite un état d'esprit différent et une compréhension plus approfondie de la modélisation de domaine et des principes pilotés par les événements.
• Cohérence à Terme (Eventual Consistency) : Les modèles de lecture sont cohérents à terme avec l'event store, ce qui peut introduire des retards et des incohérences dans l'interface utilisateur. Des stratégies pour gérer la cohérence à terme, telles que le verrouillage optimiste ou les transactions de compensation, doivent être mises en œuvre.
• Versionnement des Événements : À mesure que l'application évolue, la structure des événements de domaine peut changer. Des stratégies pour gérer le versionnement des événements, telles que la migration d'événements ou l'évolution de schéma, doivent être mises en œuvre pour garantir la compatibilité ascendante.
• Reconstruction de l'État : Reconstruire l'état d'une entité en rejouant les événements peut prendre du temps, en particulier pour les entités avec un grand nombre d'événements. Le snapshotting peut aider à atténuer ce problème.
• Choisir le Bon Event Store : La sélection d'un event store approprié qui répond aux exigences de performance, de scalabilité et de fiabilité de l'application est cruciale.

Systèmes de Stockage d'Événements de Domaine : Une Vue d'Ensemble Comparative

1. Bases de Données Relationnelles (SQL)

Les bases de données relationnelles comme PostgreSQL, MySQL et SQL Server peuvent être utilisées comme des event stores. Bien qu'elles offrent les propriétés ACID (Atomicité, Cohérence, Isolation, Durabilité) et une forte cohérence des données, elles peuvent ne pas être le choix le plus efficace pour le traitement d'événements à haut débit.

Avantages :

• Propriétés ACID : Garantit l'intégrité et la cohérence des données.
• Technologie Mature : Technologie bien établie avec des outils et un support étendus.
• Familiarité : La plupart des développeurs sont familiers avec les bases de données relationnelles.
• Forte Cohérence : Fournit de fortes garanties de cohérence.

Inconvénients :

• Goulots d'Étranglement de Performance : Peut devenir un goulot d'étranglement pour les flux d'événements à fort volume.
• Défis de l'Évolution de Schéma : La gestion des changements de schéma peut être complexe et nécessite une planification minutieuse.
• Limites de Scalabilité : La mise à l'échelle des bases de données relationnelles peut être difficile, en particulier pour les charges de travail intensives en écriture.
• Non Optimisées pour les Opérations en Ajout Seul : Les bases de données relationnelles ne sont pas spécifiquement conçues pour les opérations en ajout seul, ce qui peut affecter les performances.

Exemple d'Implémentation (PostgreSQL) :

Créez une table pour stocker les événements de domaine :

            CREATE TABLE events (
  event_id UUID PRIMARY KEY,
  aggregate_id UUID NOT NULL,
  event_type VARCHAR(255) NOT NULL,
  event_data JSONB NOT NULL,
  created_at TIMESTAMP WITHOUT TIME ZONE NOT NULL DEFAULT (NOW() AT TIME ZONE 'utc')
);

            

              
                Copy
              
            
          

Insérez un nouvel événement :

            INSERT INTO events (event_id, aggregate_id, event_type, event_data)
VALUES (uuid_generate_v4(), 'a1b2c3d4-e5f6-7890-1234-567890abcdef', 'OrderCreated', '{"orderId": "ORD-123", "customerId": "CUST-456", "amount": 100}');

            

              
                Copy
              
            
          

2. Bases de Données NoSQL

Les bases de données NoSQL, telles que MongoDB, Cassandra et Couchbase, offrent plus de flexibilité et de scalabilité par rapport aux bases de données relationnelles. Elles sont bien adaptées pour gérer des flux d'événements à fort volume, mais elles peuvent offrir des garanties de cohérence des données plus faibles.

Avantages :

• Scalabilité : Conçues pour une scalabilité horizontale et peuvent gérer de grands volumes de données.
• Flexibilité : Un schéma flexible ou sans schéma permet un versionnement plus facile des événements.
• Performance : Optimisées pour les opérations de lecture et d'écriture à haut débit.
• Rentabilité : Peuvent être plus rentables que les bases de données relationnelles pour certaines charges de travail.

Inconvénients :

• Cohérence à Terme : Peuvent offrir des garanties de cohérence des données plus faibles par rapport aux bases de données relationnelles.
• Complexité : Nécessite une compréhension plus approfondie des concepts de base de données NoSQL et des techniques de modélisation des données.
• Maturité : Certaines bases de données NoSQL sont moins matures que les bases de données relationnelles.
• Limites d'Interrogation : Les capacités d'interrogation peuvent être limitées par rapport aux bases de données relationnelles.

Exemple d'Implémentation (MongoDB) :

Stockez les événements de domaine dans une collection :

            {
  "event_id": "a1b2c3d4-e5f6-7890-1234-567890abcdef",
  "aggregate_id": "f1g2h3i4-j5k6-l7m8-n9o0-p1q2r3s4t5uv",
  "event_type": "OrderCreated",
  "event_data": {
    "orderId": "ORD-123",
    "customerId": "CUST-456",
    "amount": 100
  },
  "created_at": ISODate("2023-10-27T10:00:00.000Z")
}

            

              
                Copy
              
            
          

3. Magasins d'Événements Spécialisés (Event Stores)

Les magasins d'événements spécialisés, tels qu'EventStoreDB et AxonDB, sont conçus spécifiquement pour l'Event Sourcing. Ils fournissent des fonctionnalités telles que le stockage en ajout seul, le versionnement des événements et la gestion des flux. Ces bases de données sont généralement le meilleur choix si vous envisagez sérieusement l'event sourcing.

Avantages :

• Optimisés pour l'Event Sourcing : Conçus spécifiquement pour l'event sourcing avec des fonctionnalités telles que le stockage en ajout seul, la gestion des flux et le versionnement des événements.
• Haute Performance : Optimisés pour le traitement d'événements à haut débit.
• Gestion de la Cohérence à Terme : Mécanismes intégrés pour gérer la cohérence à terme.
• Gestion des Flux : Simplifie la gestion et l'interrogation des flux d'événements.

Inconvénients :

• Dépendance vis-à-vis d'un Fournisseur (Vendor Lock-in) : Peut introduire une dépendance vis-à-vis d'un fournisseur.
• Coût : Peut être plus cher que d'autres options.
• Courbe d'Apprentissage : Nécessite l'apprentissage d'une nouvelle technologie.
• Adoption Limitée : Moins largement adoptés que les bases de données relationnelles et NoSQL.

Exemple d'Implémentation (EventStoreDB) :

EventStoreDB utilise des flux (streams) pour stocker les événements. Vous pouvez ajouter des événements à un flux en utilisant la bibliothèque cliente d'EventStoreDB.

4. Files d'Attente de Messages (Kafka, RabbitMQ)

Les files d'attente de messages comme Apache Kafka et RabbitMQ peuvent être utilisées comme des event stores, en particulier en conjonction avec des frameworks de traitement de flux. Elles offrent un débit élevé, une scalabilité et une tolérance aux pannes, ce qui les rend adaptées aux applications pilotées par les événements à grande échelle. Cependant, elles sont généralement plus utilisées comme un mécanisme de transport transitoire que comme un magasin persistant.

Avantages :

• Débit Élevé : Conçues pour le traitement de messages à haut débit.
• Scalabilité : Hautement scalables et peuvent gérer de grands volumes d'événements.
• Tolérance aux Pannes : Mécanismes de tolérance aux pannes intégrés.
• Traitement en Temps Réel : Permet le traitement des événements en temps réel.

Inconvénients :

• Complexité : Nécessite une compréhension plus approfondie des concepts de files d'attente de messages et des frameworks de traitement de flux.
• Durabilité des Données : La durabilité des données doit être soigneusement configurée.
• Rejeu d'Événements : Rejouer des événements peut être plus complexe qu'avec des magasins d'événements spécialisés.
• Garanties d'Ordre : Les garanties d'ordre peuvent être limitées en fonction de la configuration.

Exemple d'Implémentation (Apache Kafka) :

Publiez des événements de domaine sur un topic Kafka :

            // Configuration du producteur
Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");

Producer<String, String> producer = new KafkaProducer<>(props);

// Créer un enregistrement
ProducerRecord<String, String> record = new ProducerRecord<>("order-events", "ORD-123", "{"event_type": "OrderCreated", "customerId": "CUST-456", "amount": 100}");

// Envoyer l'enregistrement
producer.send(record);

producer.close();

            

              
                Copy
              
            
          

5. Magasins d'Événements Basés sur le Cloud

Les fournisseurs de cloud proposent des services de magasins d'événements gérés, tels qu'Azure Event Hubs, AWS Kinesis et Google Cloud Pub/Sub. Ces services offrent scalabilité, fiabilité et facilité d'utilisation, ce qui en fait un bon choix pour les applications cloud-natives.

Avantages :

• Scalabilité : Hautement scalables et peuvent gérer de grands volumes d'événements.
• Fiabilité : Fiabilité et tolérance aux pannes intégrées.
• Facilité d'Utilisation : Les services gérés simplifient le déploiement et la maintenance.
• Intégration : Intégration transparente avec d'autres services cloud.

Inconvénients :

• Dépendance vis-à-vis d'un Fournisseur (Vendor Lock-in) : Introduit une dépendance vis-à-vis d'un fournisseur.
• Coût : Peut être plus cher que les solutions auto-gérées.
• Latence : La latence du réseau peut affecter les performances.
• Contrôle : Moins de contrôle sur l'infrastructure sous-jacente.

Considérations sur les Performances

La performance est un facteur critique lors du choix d'un système de stockage d'événements de domaine. Voici quelques considérations de performance à garder à l'esprit :

• Débit en Écriture : La capacité à gérer un volume élevé d'événements entrants.
• Latence en Lecture : Le temps nécessaire pour récupérer les événements et reconstruire l'état d'une entité.
• Concurrence : La capacité à gérer des opérations de lecture et d'écriture concurrentes.
• Capacité de Stockage : La quantité de stockage requise pour stocker les événements.
• Latence du Réseau : La latence entre l'application et l'event store.

Pour optimiser les performances, considérez les techniques suivantes :

• Traitement par Lots (Batching) : Regrouper les événements avant de les écrire dans l'event store peut améliorer le débit en écriture.
• Mise en Cache (Caching) : Mettre en cache les événements fréquemment consultés peut réduire la latence en lecture.
• Snapshotting (Instantané) : Le snapshotting peut réduire le nombre d'événements à rejouer lors de la reconstruction de l'état d'une entité.
• Indexation : Indexer les événements en fonction de l'ID d'agrégat et d'autres attributs pertinents peut améliorer les performances des requêtes.
• Partitionnement (Sharding) : Partitionner l'event store sur plusieurs nœuds peut améliorer la scalabilité et les performances.

Intégrité des Données

L'intégrité des données est primordiale dans l'Event Sourcing. Il est crucial de s'assurer que les événements sont persistés de manière fiable et dans le bon ordre. Voici quelques stratégies pour maintenir l'intégrité des données :

• Transactions : Utilisez des transactions pour garantir que les événements sont écrits de manière atomique dans l'event store.
• Idempotence : Concevez les gestionnaires d'événements pour qu'ils soient idempotents, c'est-à-dire qu'ils puissent traiter le même événement plusieurs fois sans provoquer d'effets secondaires indésirables.
• Verrouillage Optimiste : Utilisez le verrouillage optimiste pour empêcher les mises à jour concurrentes du même agrégat.
• Validation des Événements : Validez les événements avant de les persister dans l'event store pour vous assurer qu'ils sont valides et cohérents.
• Sommes de Contrôle (Checksums) : Calculez des sommes de contrôle pour les événements et stockez-les avec les événements. Vérifiez les sommes de contrôle lors de la récupération des événements pour vous assurer qu'ils n'ont pas été corrompus.

Versionnement des Événements

À mesure que l'application évolue, la structure des événements de domaine peut changer. La gestion du versionnement des événements est cruciale pour garantir la compatibilité ascendante et prévenir la perte de données. Voici quelques stratégies pour gérer le versionnement des événements :

• Surtypage d'Événement (Event Upcasting) : Transformez les anciennes versions d'événements vers la version la plus récente lors de leur lecture depuis l'event store.
• Évolution de Schéma : Faites évoluer le schéma des événements au fil du temps en ajoutant de nouveaux champs ou en modifiant ceux existants. Assurez-vous que les anciennes versions d'événements peuvent toujours être traitées correctement.
• Migration d'Événements : Migrez les anciens événements vers la dernière version du schéma. Cela peut être fait en tant que processus d'arrière-plan.

Exemples Concrets

L'Event Sourcing est utilisé dans une variété d'industries et d'applications. Voici quelques exemples concrets :

• Commerce Électronique : Suivi de l'historique des commandes, des changements d'inventaire et de l'activité des clients. Par exemple, une plateforme de commerce électronique mondiale pourrait utiliser l'Event Sourcing pour suivre les commandes de divers pays, gérer les conversions de devises et gérer les stocks dans plusieurs entrepôts.
• Secteur Bancaire : Enregistrement des transactions, suivi des soldes de comptes et audit des activités financières. Une banque multinationale pourrait utiliser l'Event Sourcing pour suivre les transactions entre différentes succursales et devises, garantissant une piste d'audit complète.
• Jeux Vidéo : Suivi des actions des joueurs, des changements d'état du jeu et de l'historique des événements. Les jeux multijoueurs en ligne utilisent souvent l'Event Sourcing pour maintenir un état de jeu cohérent entre plusieurs joueurs et serveurs.
• Gestion de la Chaîne d'Approvisionnement : Suivi des mouvements de produits, des niveaux de stock et des calendriers de livraison. Une entreprise de logistique mondiale peut utiliser l'Event Sourcing pour suivre les expéditions à travers différents pays, gérer le dédouanement et gérer les plannings de livraison.

Choisir le Bon Système de Stockage : Une Matrice de Décision

Pour vous aider à décider quel système de stockage d'événements de domaine convient à votre application, considérez la matrice de décision suivante :

Informations Pratiques

Voici quelques informations pratiques pour la mise en œuvre de l'Event Sourcing :

• Commencez Petit : Commencez avec un domaine petit et bien défini pour acquérir de l'expérience avec l'Event Sourcing avant de l'appliquer à des domaines plus vastes et plus complexes.
• Concentrez-vous sur le Domaine : Modélisez soigneusement votre domaine et identifiez les événements de domaine clés.
• Choisissez le Bon Système de Stockage : Sélectionnez un event store qui répond aux exigences de performance, de scalabilité et de cohérence des données de votre application.
• Implémentez le Versionnement des Événements : Prévoyez le versionnement des événements dès le début pour garantir la compatibilité ascendante.
• Surveillez les Performances : Surveillez les performances de votre event store et de vos gestionnaires d'événements pour identifier les goulots d'étranglement potentiels.
• Automatisez le Déploiement : Automatisez le déploiement et la gestion de votre infrastructure d'Event Sourcing.
• Considérez les Compromis : L'Event Sourcing implique des compromis. Comprenez que des complexités apparaissent en échange des avantages obtenus avec ce modèle.

Conclusion

L'Event Sourcing est un modèle architectural puissant qui offre de nombreux avantages, notamment une piste d'audit complète, des requêtes temporelles et des performances améliorées pour certaines opérations. Cependant, il présente également des défis qui doivent être soigneusement examinés, tels que la complexité, la cohérence à terme et le versionnement des événements. En sélectionnant soigneusement un système de stockage d'événements de domaine et en mettant en œuvre les meilleures pratiques, vous pouvez tirer parti avec succès de l'Event Sourcing pour construire des applications scalables, résilientes et auditables.

Ce guide a fourni un aperçu de l'Event Sourcing et de plusieurs systèmes de stockage d'événements de domaine populaires. Choisissez le meilleur système pour l'aligner avec les besoins spécifiques des exigences de votre projet.

N'oubliez pas que ce contenu est destiné à un public mondial, alors adaptez et appliquez les concepts à votre situation et à votre contexte culturel uniques. Les principes de l'Event Sourcing sont universels, mais la mise en œuvre peut varier en fonction de vos besoins et de vos ressources spécifiques.