Comment l’approvisionnement d’événements vous aide à suivre l’état de votre application –

L’approvisionnement en événements est une architecture logicielle dans laquelle les modifications de l’état de l’application sont capturées sous la forme d’une série «d’événements» stockés en permanence. Alors que la plupart des systèmes n’exposent que leur état actuel, l’approvisionnement en événements crée un enregistrement complet de tous les états antérieurs.

Les fondamentaux

Le sourcing d’événements est le plus souvent utilisé avec des systèmes basés sur le temps ou des processus linéaires. Une application de commande en magasin peut faire la transition des transactions entre les états «en attente», «approuvé» et «expédié». La transition entre chaque état est un «événement» distinct dans le cycle de vie de cet ordre.

Ce système pourrait être modélisé à l’aide d’une base de données relationnelle traditionnelle:

order_id | order_status
---------|-------------
1000     | APPROVED

Dans la plupart des systèmes, connaître l’état actuel ne suffit pas. Vous voulez aussi voir lorsque l’ordre a été approuvé. Nous pourrions le faire en ajoutant des champs supplémentaires:

order_id | order_created_time | order_approved_time | order_shipping_time
---------|--------------------|---------------------|---------------------
1000     | 2021-04-30         | 2021-05-01          | NULL

Il est maintenant clair que la commande a été créée le 30 avril et approuvée le 1er mai; son expédition est toujours en attente. Pour de nombreuses applications, cette structure fonctionne bien. Cependant, cela peut devenir restrictif à mesure que de nouveaux états sont ajoutés.

Regardons maintenant cet exemple restructuré pour utiliser le sourcing d’événements:

event_id | event_order_id | event_type     | event_timestamp
---------|---------------------|----------------|----------------
2        | 1000                | order.approved | 2021-05-01
1        | 1000                | order.created  | 2021-04-30

Les transitions d’état de la commande ont été séparées dans un journal d’événements dédié. Avec ce modèle, il est trivial d’ajouter un nouveau type d’événement à l’avenir. Si un client a besoin d’annuler une commande, nous pouvons rédiger un order.cancelled événement dans le journal.

L’approvisionnement d’événements peut également être utilisé pour suivre les données sur la commande elle-même. Vous pouvez ajouter des types d’événements pour order.apply_discount ou alors order.process_refund. Vous pouvez enregistrer un événement à tout moment, en créant un nouvel état pour la commande tout en gardant ses états précédents accessibles.

Reconstruire l’état d’un objet

Vous pouvez déterminer l’état actuel d’un objet en récupérant tous les événements qui s’y rapportent. Si vous voulez savoir si une commande a été approuvée, vérifiez si sa collection d’événements contient un order.approved un événement.

Vous pouvez reconstruire des états historiques exactement de la même manière. Si vous avez besoin de connaître l’état de la commande à une date particulière, récupérez tous les événements enregistrés le ou avant ce jour.

La recherche d’événements est un modèle incrémentiel qui suit automatiquement la chronologie d’un objet. Chaque modification de l’état de l’objet doit être capturée en tant qu’événement horodaté. Lorsque vous utilisez l’approvisionnement d’événements, vous disposez d’un contrôle de version automatique et d’un journal d’audit complet des transitions d’état.

Si jamais vous avez besoin de reconstruire l’historique d’un objet, vous pouvez ignorer tous les événements créés après une date donnée. Imaginez que le compte d’un utilisateur a été compromis par un acteur malveillant qui a pris diverses actions en son nom. Dans un système entièrement basé sur des événements, vous pouvez supprimer tous les événements liés à cet utilisateur dans un délai douteux. Cela permettrait de récupérer leur compte dans un bon état.

Pour conserver cette capacité, vous devez vous assurer que les événements sont immuables. Une fois qu’un événement a été enregistré, vous ne devez jamais modifier ses propriétés. Si un événement doit être ajusté, vous enregistrez un autre événement pour effectuer la modification.

L’immuabilité du système signifie que vous pouvez l’utiliser en toute sécurité pour voyager dans le temps et reconstruire des états historiques. Si vous souhaitez reproduire votre base de données telle qu’elle était il y a deux ans, vous pouvez supprimer tous les événements enregistrés dans l’intervalle.

Un autre avantage de l’approvisionnement d’événements est une visibilité accrue sur l’état du système. Si un utilisateur signale un bogue, vous pouvez cloner la base de données, ignorer de nouveaux événements et répéter leurs étapes à partir d’un bon point connu. L’analyse des événements enregistrés peut vous aider à identifier les bogues dans votre base de code.

Sourcing événementiel dans le monde réel

L’approvisionnement en événements a la réputation d’être complexe, peu maniable et trop compliqué. Historiquement, l’approvisionnement d’événements a été lié aux applications avec des exigences d’audit strictes et un besoin avéré de rejouer les événements.

Cela ne doit pas être le cas cependant. Si vous êtes un développeur expérimenté, vous avez probablement mis en œuvre quelque chose de proche de l’approvisionnement d’événements dans le passé. Tout système qui conserve un enregistrement des «événements» – tels que les tentatives de connexion des utilisateurs, les visites de pages Web ou les étapes de traitement des commandes – gravite naturellement vers une approche événementielle, même si vous n’en implémentez pas intentionnellement.

Une implémentation délibérée de l’approvisionnement d’événements dans le code peut être fastidieuse. Les développeurs supposent généralement que les données extraites des bases de données sont une représentation précise de l’état actuel d’un objet. Avec l’approvisionnement d’événements, les données que vous récupérez ont peu de valeur en soi. Vous devez «rejouer» les événements dans votre base de code pour créer une représentation de l’état.

L’approvisionnement en événements peut entraîner des surcoûts de performance. Dans l’exemple ci-dessus, la création d’une représentation complète de l’objet de commande nécessite maintenant beaucoup plus de données à extraire. Dans le modèle traditionnel, une seule sélection fournit toutes les données associées à la commande.

Il y a aussi d’autres inconvénients. En cas de problème, la recherche d’événements peut être plus difficile à résoudre. Vous ne pouvez pas écrire un correctif rapide ou corriger manuellement la base de données. Vous devrez effectuer une transition gracieuse de vos schémas d’événements tout en vous assurant que la chronologie historique reste intacte.

Combinaison de l’approvisionnement d’événements et du CQRS

L’approvisionnement d’événements est généralement combiné avec CQRS (Command Query Responsibility Segregation). Ce modèle préconise la séparation des commandes (qui écrivent des données) à partir de requêtes (qui lit les données).

L’utilisation de l’approvisionnement d’événements nécessite un degré de CQRS. Les données sont écrites dans votre base de données via des événements. Le modèle d’écriture est donc extrêmement simple: il s’agit d’un journal à sens unique des événements qui se produisent. Les événements sont une manifestation des «commandes» décrites par le CQRS.

Le modèle de récupération des données est totalement indépendant. Vous pouvez utiliser le système de requête le plus approprié pour récupérer les événements et les superposer dans l’état actuel de l’application. le commandes (événements) font passer le système dans un nouvel état; Les requêtes exposent les aspects d’état demandés par votre application.

En d’autres termes, les modèles de lecture et d’écriture n’ont aucune conscience du fonctionnement des autres. Les entités de votre base de code (comme un ordre) sont stockées sous la forme d’une séquence d’événements chronologiques. Les événements stockés ne peuvent pas être réhydratés dans l’entité à laquelle ils appartiennent sans savoir comment l’état de cette entité est dérivé. Ces connaissances sont implémentées dans le modèle de lecture (requête), qui ramène les données dans votre application.

Cette caractéristique permet de simplifier la couche de persistance à une seule insertion d’enregistrement pour chaque opération. Les données stockées n’ont pas besoin de représenter précisément une entité particulière car le modèle de requête la manipulera plus tard. Cela contraste avec une base de données relationnelle «traditionnelle» où les champs de table s’alignent souvent étroitement avec les propriétés des objets de votre base de code.

La sortie du modèle de requête est connue sous le nom de projection. Une projection est une représentation de données utilisant une perspective différente de son système de stockage. Lors de l’utilisation de la source d’événements, les données sont stockées sous forme de flux d’événements mais projeté en une représentation de l’état actuel de l’application. Cette représentation est sans état, immuable et idempotente – la création de la représentation ne modifie en aucune façon les données d’événement sous-jacentes.

Une seule projection peut avoir besoin d’interagir avec plusieurs types d’événements différents. Les projections examinent les données de manière agrégée, d’une manière qui a du sens pour les fonctions de l’application. Dans notre exemple précédent, une projection Order pouvait générer un objet contenant CreatedDate, ApprovedDate et ShippedData properties en examinant les événements associés à l’ordre des sujets.

Conclusion

L’approvisionnement d’événements est une architecture logicielle spécialisée avec un soutien inné pour la responsabilité, la chronologie et les loisirs d’État. Le modèle peut simplifier considérablement la mise en œuvre d’applications où ces qualités sont souhaitables.

L’approvisionnement en événements peut également être utile dans d’autres scénarios, bien que des rendements décroissants puissent être rencontrés. L’adoption de l’approvisionnement en événements nécessite que les développeurs implémentent du code pour déterminer l’état actuel, ajoutant des frais généraux qui ne surviennent pas dans les systèmes qui stockent uniquement l’état actuel dans leur base de données.

L’approvisionnement d’événements est mieux combiné avec d’autres techniques d’architecture logicielle telles que le CQRS, le modèle d’observateur et la cohérence éventuelle. Vous n’avez pas besoin d’utiliser l’approvisionnement d’événements dans toute votre application – souvent, les sous-modules individuels bénéficieront de l’approvisionnement d’événements tandis que la majeure partie de votre projet s’en tient à une base de données relationnelle traditionnelle.