Concepts de base de l'Event Sourcing

Introduction à l'Event Sourcing

Au début (0:00), Derek parle de la confusion qui règne autour de l'approvisionnement en événements et des concepts fondamentaux qui y sont associés. Il définit le sourçage d'événements comme n'étant pas seulement la "capture de l'état actuel", mais le stockage d'événements - la capture de chaque changement qui se produit dans votre modèle de domaine dans un journal de type "append-only".

De cette manière, vous conservez un historique complet des changements d'état de votre système. Au lieu de persister uniquement l'état final, vous persistez les événements qui reflètent la logique commerciale qui s'est produite.

Événements : Saisir les faits commerciaux

À 0:33, Derek explique ce qu'est réellement un événement. Un événement représente quelque chose qui s'est déjà produit dans le système - un fait commercial. Par exemple, un événement "ProductReceived" contiendrait la quantité reçue et la date.

Derek insiste sur le fait que lorsque vous stockez des événements, ils doivent être nommés en utilisant une convention de dénomination qui reflète le passé, comme "Produit expédié" ou "Inventaire ajusté". Dans un schéma d'événement, vous pouvez avoir des champs tels que public Guid Id, public string Name et des horodatages.

Chaque événement doit également avoir un identifiant unique, ce qui est crucial pour un système de stockage "append only" dans lequel vous ajoutez des événements à un flux d'événements.

Flux d'événements : Organiser des événements

À 2:02, Derek passe aux flux d'événements. Il établit une comparaison avec une table de base de données relationnelle, mais explique que dans le cadre de l'approvisionnement en événements, tous les événements liés à un objet de domaine (tel qu'un article d'inventaire) appartiennent au même flux d'événements.

Chaque flux d'événements est lié à une entité spécifique, souvent définie par un identifiant public Guid Id et une chaîne de caractères Name. Par exemple, un produit portant l'UGS ABC123 aurait son propre flux contenant des événements persistants tels que la réception ou l'expédition.

Derek suggère que lorsque vous modélisez ces outils, vous pensiez en termes de racines d'agrégats et d'objets de domaine, en empruntant des concepts de conception axée sur le domaine.

La modélisation du cycle de vie - qu'il soit de courte ou de longue durée - permet d'optimiser le nombre et la taille des flux. Ces éléments sont essentiels pour améliorer les performances des systèmes complexes.

Projections et modèles de lecture

À 4:12, Derek présente les projections et le modèle de lecture. Étant donné que votre système de source d'événements capture des événements plutôt que l'état actuel, vous devez rejouer les événements pour répondre à des questions telles que "Quelle est la quantité de stock actuelle ?"

Pour construire des modèles de lecture, vous traitez les événements du flux. Par exemple, en utilisant private void Apply(Event e) ou similaire, vous incrémentez ou décrémentez le stock en fonction des gestionnaires d'événements pour chaque type d'événement.

Derek illustre comment construire un modèle de lecture dans une base de données documentaire ou une base de données relationnelle - peut-être qu'une projection montre simplement la quantité en stock, tandis qu'une autre montre l'historique des expéditions.

Cela reflète la ségrégation des responsabilités en matière de commandes et de requêtes (CQRS) : la séparation des opérations d'écriture (commandes) des opérations de lecture (requêtes).

Projections pour les modèles d'écriture

À 6:48, Derek montre comment appliquer les projections du côté de l'écriture également. Cela est essentiel pour valider les actions avant qu'elles ne soient autorisées.

Dans un gestionnaire de commandes, avant d'expédier des produits, vous devez vérifier que la quantité est suffisante. Derek utilise une méthode comme private void Apply(List events) pour reconstruire l'état nécessaire.

Des champs tels que public int Version permettent de suivre l'évolution du flux et d'en assurer la cohérence.

Cette mise en œuvre pratique permet d'appliquer la logique d'entreprise lors du traitement de nouveaux événements, en veillant à ce que votre système n'agisse que sur des transitions d'état valides.

Les abonnements : Réagir aux nouveaux événements

À 8:01, Derek parle des abonnements. Les abonnements permettent aux consommateurs d'événements d'écouter les nouveaux événements et de réagir.

Par exemple, un projecteur peut s'abonner à un flux d'événements et mettre à jour un modèle de lecture lorsqu'il voit un événement "Produit expédié". Un éditeur peut également être à l'écoute d'événements et les publier sur des systèmes externes tels que RabbitMQ ou Kafka, en s'intégrant à d'autres services.

Derek décrit les abonnements non seulement pour la mise à jour des modèles internes, mais aussi pour la distribution des données dans des systèmes d'événements distincts, en préservant la cohérence éventuelle.

Cela montre un autre avantage majeur de l'architecture pilotée par les événements : vos services restent cohérents en fin de compte, tout en étant évolutifs de manière indépendante.

Rappel des concepts de base

À 9:21, Derek résume les concepts de base :

• Les événements capturent les faits.

• Les flux d'événements organisent les événements par entité.

• Les projections transforment les flux en modèles de lecture interrogeables ou en modèles d'écriture exploitables.

• Les abonnements permettent aux services de réagir et de se mettre à jour en conséquence.

Il souligne que vous devez conserver les événements dans un journal de type append-only, maintenir une piste d'audit et rejouer les événements si nécessaire.

Snapshots et optimisation

À 9:39, Derek aborde la question de l'instantané. Bien qu'il soit souvent question de l'approvisionnement par événement, il précise que les instantanés constituent une optimisation des performances plutôt qu'une exigence fondamentale.

Les instantanés réduisent la charge de travail liée à la relecture de tous les événements en sauvegardant périodiquement un état partiel, mais l'historique complet existe toujours via le journal "append only".

Distinction clé : Event Sourcing vs Event Driven Architecture

À 10:00, Derek met en garde contre une idée fausse très répandue : l'approvisionnement par les événements et l'architecture pilotée par les événements sont différents ! Des outils tels que Kafka facilitent la distribution des données, mais le véritable sourçage d'événements se concentre sur l'enregistrement des événements du domaine sous la forme d'une piste d'audit immuable.

Il est essentiel de comprendre cette distinction lorsque vous intégrez l'approvisionnement par événement dans vos systèmes complexes.

Conclusion

À la suite de la vidéo de Derek Comartin, il est clair que le sourçage d'événements consiste à enregistrer chaque changement en tant qu'événement, et pas seulement l'état final. En stockant les événements dans un système de stockage en annexe uniquement, vous créez un schéma d'événements riche qui fournit une piste d'audit, une flexibilité pour l'interrogation des événements et une prise en charge solide de la ségrégation de la responsabilité de l'interrogation de commande.

Que vous traitiez de l'approvisionnement en événements C# dans .NET Core ou toute autre plateforme, l'explication structurée de Derek sur les concepts de base, les gestionnaires d'événements, les ensembles privés, les ensembles protégés et l'application d'événements tels que private void Apply() dans vos modèles est incroyablement précieuse.

Si vous travaillez à la construction d'un modèle de domaine résilient, à l'amélioration de votre système de stockage ou à la création de modèles complexes présentant plusieurs avantages tels que la cohérence à terme, l'étude de l'approche de Derek est indispensable. Consultez son chaîne YouTube pour découvrir d'autres vidéos intéressantes.