L’approvisionnement en événements n’est pas un nouveau terme. Si vous travaillez dans la technologie, vous devez avoir rencontré le sourcing événementiel. L’approvisionnement en événements est un outil puissant, et il est adapté par de nombreuses grandes organisations en tant que conception architecturale de leur base de données. Il a la capacité d’évoluer et de répondre aux besoins de l’industrie moderne des données.
Dans cet article, nous en apprendrons davantage sur le sourcing d’événements et pourquoi il gagne en popularité. Nous discuterons également de la question populaire : le sourcing d’événements va-t-il dépasser les bases de données ?
Qu’est-ce que l’Event Sourcing ?
L’approvisionnement en événements est un modèle architectural permettant de stocker des données sous la forme d’une séquence d’événements. Un événement n’est rien d’autre qu’un contexte à l’opération commerciale. Par exemple, si un client a demandé un remboursement mais que vous ne savez pas pourquoi, le sourcing d’événements donne le contexte de la raison pour laquelle un remboursement a été effectué.
Comprenons quelques termes clés associés à l’approvisionnement en événements :
Événements
Les événements représentent un changement dans l’état des données. Ce sont des faits immuables qui fournissent un contexte à l’entreprise. Prenons l’exemple d’une boutique e-commerce. Toutes les modifications de données seront stockées sous forme d’événements, tels que ProductAdded, ProductOrdered, ProductShipped, PaymentReceived, etc.
Les événements sont enregistrés au passé et fournissent la source de vérité à l’état actuel de l’entreprise. En plus du contexte, les événements stockent également des métadonnées pour fournir plus d’informations.
Base de données des sources d’événements
Une base de données de sources d’événements, également appelée base de données de sources d’événements, enregistre tous les événements dans une base de données en ajout uniquement. Dans une base de données source d’événements, l’historique des modifications est conservé dans l’ordre chronologique.
La base de données de source d’événement peut également être appelée journaux d’événements. Ils ne peuvent pas être modifiés, car les événements sont immuables. Il y a un contre-argument, cependant, qui dit que la base de données de la source d’événement peut être modifiée en ajoutant un autre événement – l’état de la base de données de la source d’événement ou son résultat change.
La base de données source d’événement pour la boutique de commerce électronique enregistrera chaque événement avec les métadonnées associées. Supposons qu’il y ait deux événements dans la base de données source d’événement du produit et qu’un troisième produit soit ajouté à la base de données source d’événement. Ce produit ajouté n’est pas nouveau mais est retourné par le client, donc le contexte de l’événement produit est retourné et le nombre d’événements est mis à jour. La base de données source d’événements contient tous ces événements dans l’ordre chronologique.
Le contexte et l’ordre chronologique des événements fournissent des informations utiles pour une analyse approfondie.
Ruisseaux
Les flux d’événements fournissent un historique complet des modifications liées à un événement particulier. Les événements résident dans la base de données source d’événements et les flux d’événements représentent l’ordre dans lequel les événements se produisent. Les flux d’événements peuvent être de courte ou de longue durée en fonction du scénario particulier. Les événements dans le flux d’événements sont identifiés par une valeur numérique unique et sont incrémentés à mesure que les événements sont mis à jour. Vous pouvez récupérer l’état d’origine des événements grâce à ces identifiants. Dans l’exemple de la boutique de commerce électronique, le paiement est un objet entité/domaine distinct. L’objet de paiement a son propre identifiant unique et son flux d’événements sera : Paiement confirmé -> Paiement reçu -> Le remboursement est demandé -> Montant du remboursement déduit.
Affichage de la requête
Dans l’approvisionnement en événements, les modèles de requête représentent la transition logique du modèle d’écriture source vers le modèle de lecture. Ils sont également appelés projections ou modèles de vue. Dans la vue de la requête, il existe deux types de concepts : le modèle de lecture et le modèle d’écriture. Rappelons l’exemple d’une boutique e-commerce où les événements du modèle d’écriture qui sont ajoutés à la vue de la requête sont : Commande passée, paiement reçu, commande expédiée, produit déduit, puis nous utilisons la vue de la requête pour générer un résumé de tous les les commandes passées et les paiements reçus dans le modèle de lecture.
Pourquoi avons-nous besoin d’un sourcing d’événements ?
L’approvisionnement en événements est un excellent choix dans une variété d’applications. Examinons quelques scénarios où l’approvisionnement en événements est une solution acceptable.
- L’approvisionnement en événements est utile dans les systèmes d’audit où les journaux peuvent être stockés dans l’ordre chronologique et disposent d’une option de sauvegarde à la demande.
- Les méthodes traditionnelles collectent des données dans des emplacements spécifiques à utiliser uniquement en cas de besoin. En répondant rapidement aux nouvelles informations disponibles, une approche axée sur les événements peut être plus efficace. En s’abonnant au flux, une organisation peut recevoir des mises à jour sur les nouvelles occurrences et y répondre immédiatement. Cela simplifie la modélisation et la création de procédures commerciales complexes.
- Il est possible de migrer lentement des systèmes hérités vers des architectures distribuées contemporaines, en remplaçant éventuellement des fonctionnalités particulières par des services événementiels. Alors que les écritures sont dirigées vers les services, les voies de lecture actuelles du système hérité peuvent continuer à être utilisées.
- Les services dépendants peuvent « rattraper » lorsque le service d’origine reprend ses activités si l’un d’entre eux tombe en panne. Lorsque chaque service revient, la synchronisation peut être effectuée car les événements sont stockés dans le flux dans un ordre spécifique.
- Dans un système événementiel, les données voyagent dans une direction à travers des modèles distincts pour lire ou mettre à jour les données. En raison de la responsabilité unique de chaque partie du flux de données, il est plus facile de raisonner sur les données et de résoudre les problèmes.
En quoi une base de données de sources d’événements (db) est-elle différente des bases de données traditionnelles ?
Les données sont stockées dans des bases de données traditionnelles à l’aide de l’opération CRUD, c’est-à-dire Créer, Lire, Mettre à jour et Supprimer. Chaque fois qu’un changement se produit, l’enregistrement est mis à jour dans la base de données et il préserve l’état actuel du système. Dans toutes les bases de données relationnelles et non relationnelles, les enregistrements peuvent être supprimés et l’état du système sera perdu.
Dans une base de données source d’événements, les événements sont immuables ; ils ne peuvent pas être supprimés ou modifiés. La base de données de source d’événement conserve l’historique des journaux dans l’ordre chronologique. En suivant les modifications, les écarts entre les données d’audit et les données transactionnelles sont évités. Tout comme dans la conception du système CRUD, le sourcing d’événements stocke les événements dans des tableaux, mais dans l’ordre chronologique. Étant donné que les données sont en ordre avec les dernières données en haut, le filtrage de l’approvisionnement en événements est plus facile par rapport aux bases de données traditionnelles.
L’Event Sourcing dépassera-t-il les bases de données ?
Dans les applications du monde réel, plusieurs utilisateurs simultanés mettent à jour des enregistrements dans le magasin de données, et souvent les données ne sont pas mises à jour partout. Cela entraîne une incohérence entre les magasins de données. Il n’existe aucun mécanisme pour stocker les métadonnées de l’historique des modifications qui peuvent être utilisées pour une analyse approfondie.
L’approvisionnement en événements fournit également un contexte au changement qui se produit dans la base de données, ce qui aide à répondre aux questions commerciales. L’approvisionnement en événements fonctionne mieux avec les microservices et est fiable pour partager des données entre d’autres services.
Voici quelques avantages qui font du sourcing événementiel un meilleur choix que les bases de données traditionnelles :
- Les événements peuvent être enregistrés à l’aide d’une opération d’ajout uniquement et sont immuables. Les tâches qui traitent des événements peuvent s’exécuter en arrière-plan tandis que l’interface utilisateur, le flux de travail ou le processus qui les a démarrées peut continuer. Ceci, associé à l’absence de conflit lors du traitement des transactions, peut considérablement améliorer les performances et l’évolutivité d’une application, en particulier au niveau de la présentation ou de l’interface utilisateur.
- Les événements sont des objets simples qui expliquent une action qui a eu lieu avec toute information supplémentaire nécessaire pour décrire complètement l’action que l’événement représente. Un magasin de données n’est pas directement mis à jour par les événements. Ils sont simplement enregistrés pour être manipulés si nécessaire. Cela peut simplifier l’administration et la mise en œuvre.
- Pour un expert du domaine, les événements ont souvent un sens. Cependant, la non-concordance d’impédance relationnelle-objet peut rendre difficile la compréhension des tables de base de données complexes. Les tableaux sont constitués d’objets qui décrivent l’état actuel du système plutôt que des événements réels.
- Étant donné que la recherche d’événements ne nécessite pas de mettre à jour directement les objets du magasin de données, elle peut aider à prévenir les conflits causés par des modifications simultanées. Cependant, le modèle de domaine doit toujours être construit pour résister aux requêtes qui peuvent provoquer un état incohérent.
- Les tâches répondent aux événements en effectuant des actions lorsqu’elles sont déclenchées par la base de données source d’événement.
- Les tâches et les événements sont séparés, ce qui offre flexibilité et extensibilité. Les tâches connaissent le type d’événement qui s’est produit et ses données, mais pas l’opération qui l’a provoqué.
- De plus, chaque événement peut être géré par de nombreuses tâches. Cela permet d’intégrer facilement des services et des systèmes supplémentaires qui se limitent à la surveillance de nouveaux événements déclenchés par la base de données source d’événements. Les événements de sourcing d’événements, cependant, ont souvent un niveau très bas, il serait donc essentiel de créer à leur place des événements d’intégration particuliers.
Défis liés à la recherche d’événements
Bien qu’il présente de nombreux avantages, le sourcing d’événements présente également de nombreux défis. Discutons de quelques défis associés à la recherche d’événements.
- La base de données de la source d’événement est immuable et sert de référentiel permanent pour les données. Les données d’événement ne doivent jamais être modifiées. L’ajout d’un nouvel événement à la base de données source de l’événement est la seule option pour mettre à jour une entité afin d’annuler une modification. Il peut être difficile de mélanger les événements actuels dans le magasin avec la nouvelle version si le format (plutôt que le contenu) des événements persistants doit changer, éventuellement lors d’une migration. Il pourrait être nécessaire d’introduire de nouveaux événements qui utilisent le nouveau format ou de boucler tous les événements existants en faisant des ajustements pour les mettre en conformité avec le nouveau format. Pour conserver à la fois l’ancien et le nouveau formulaire d’événement, pensez à utiliser un tampon de version sur chaque itération du schéma d’événement.
- Interroger des données ou lire des données à partir de magasins de données de sources d’événements peut être difficile, car il n’y a pas de mécanisme SQL standard. Pour lire les données, le flux d’événements est extrait par rapport à l’identifiant d’événement.
- La base de données source d’événements peut contenir des événements qui ont été stockés par des programmes multithreads et plusieurs instances d’applications. La cohérence des événements dans la base de données source d’événements et la synchronisation des événements qui ont un impact sur une entité particulière sont cruciales (l’ordre dans lequel les modifications se produisent sur une entité affecte son état actuel). Chaque événement doit avoir un horodatage…