La recherche d'événements ( source d' événements, journalisation d'événements, génération d'événements) est un modèle architectural puissant dans lequel toutes les modifications apportées à l'état de l'application sont enregistrées dans l'ordre dans lequel elles se sont produites. Ces enregistrements servent à la fois de source pour obtenir l'état actuel et de piste d'audit de ce qui s'est passé dans l'application pendant sa durée de vie. L'approvisionnement d'événements facilite la modification et la lecture décentralisées des données. Cette architecture s'adapte bien et convient aux systèmes qui travaillent déjà avec la gestion des événements ou qui souhaitent migrer vers une telle architecture.
Qu'est-ce que l'approvisionnement d'événements
Les experts du domaine décrivent généralement leurs systèmes comme un ensemble d' entités , qui sont des conteneurs pour stocker l'état et les événements reflétant les changements dans les entités à la suite du traitement des données d'entrée dans divers processus métier. Les événements sont souvent déclenchés par des commandes provenant d'utilisateurs, des processus d'arrière-plan ou des intégrations avec des systèmes externes.
Essentiellement, l'approvisionnement d'événements se concentre sur les événements liés aux changements dans le système.
De nombreux modèles architecturaux considèrent les entités comme un concept principal. Ces modèles décrivent comment les enregistrer, comment y accéder et comment les modifier. Dans ce style architectural, les événements sont souvent «de côté»: ils sont les conséquences du changement d'entités.
En règle générale, ces architectures sont basées sur un magasin d'entités tel qu'une base de données relationnelle ou un magasin de documents. Bien que les événements puissent être présents dans une telle architecture, ils ne constituent pas, dans leur essence, un concept primaire et peuvent être séparés des entités auxquelles ils sont associés, ainsi que cachés derrière des couches de logique métier.
Event Sourcing renverse cette approche en se concentrant sur l'implémentation des événements: comment ils sont persistants et comment ils peuvent être utilisés pour obtenir l'état d'une entité. Dans ce cas, la base de données contiendra un journal séquentiel de tous les événements survenus pendant la durée de vie du système.
Vous trouverez ci-dessous une comparaison du magasin d'événements avec le magasin d'entités (décrit plus en détail ci-dessous): La recherche d'
événements, en utilisant les événements comme concept architectural principal, est également un paradigme de modélisation de domaine qui reflète mieux la vision du client du système. La conception de systèmes mettant l'accent sur les événements et les journaux d'événements offre les avantages suivants:
- , « » .
- (command/query responsibility), .
- , , , .
Event Sourcing
Regardons un exemple simple avec un compte bancaire. Nous aurons une entité représentant un compte bancaire. Pour plus de simplicité, nous ne créerons qu'un seul compte sans l'identifier à l'aide du numéro de compte ou de toute autre manière. Le compte conservera le solde actuel des fonds.
Deux commandes (commande) seront disponibles pour le compte : déposer de l'argent (dépôt) et retirer de l'argent (retirer). Les commandes indiqueront le montant à déposer ou à retirer. Nous définirons également une règle métier qui vérifie qu'une commande de retrait ne peut être traitée que si le montant demandé est égal ou inférieur au solde du compte courant.
Avec cette approche, deux événements peuvent être distingués (événement)- «Compte crédité» et «Compte débité». Ces événements contiennent des informations sur le montant qui a été déposé ou retiré. Cela pourrait être simplifié en un seul événement avec une somme positive ou négative, mais dans cet exemple, nous les diviserons.
Le diagramme ci-dessous montre le modèle de données.
Notez que les événements sont «au passé». Ils indiquent ce qui s'est passé dans le système au moment où ils ont été écrits et ne sont enregistrés que si la commande a été traitée avec succès. Avec cette approche, il faut veiller à ne pas confondre les commandes avec les événements. Surtout s'ils se reflètent.
La séquence de commandes peut ressembler à ceci:
1. dépôt {montant: 100} - dépôt 100
2. retirer {montant: 80} - retirer 80
3. retirer {montant: 50} - retirer 50
La mise en œuvre la plus simple de Event Sourcing nécessite un journal des événements , qui est simplement une séquence d'événements. Lors du traitement des commandes ci-dessus, vous obtenez un tel journal.
La troisième commande ne peut pas être exécutée car le montant demandé dépasse le solde disponible.
Pour obtenir le solde actuel, le système doit traiter ou "générer" les événements dans l'ordre de leur occurrence. Pour notre exemple, cela pourrait ressembler à ceci:
- compte bancaire {solde actuel: 0} (état de départ)
compte bancaire {solde actuel: 0} (état de départ) - bank account { current balance: 100 } (processed: Account Credited, +100)
{ : 100 } (: , +100) - bank account { current balance: 20 } (processed: Account Debited, -80)
{ : 20 } (: , -80)
Le solde actuel est calculé par le traitement de tous les événements jusqu'au moment actuel. Étant donné que chaque événement a un horodatage implicite, il est possible de calculer l'état du compte à tout moment en traitant tous les événements pendant la période de temps requise.
Ceci est un exemple complet (quoique trivial) de Event Sourcing. Dans un système réel, cet exemple devra probablement être étendu.
Il peut être nécessaire d'enregistrer une séquence de commandes pour être en mesure d'identifier comment l'événement s'est produit, ainsi que de créer un journal des événements d'erreur séparé dans lequel enregistrer les commandes qui n'ont pas abouti, pour une gestion plus poussée des erreurs et maintenir un historique complet des réussites et équipes infructueuses.
Au fil du temps, à mesure que le nombre de commandes augmente, il peut être nécessaire de maintenir le solde du compte actuel de sorte que lorsqu'une commande de retrait est reçue, il ne soit pas nécessaire de traiter la liste complète des événements pour déterminer si la commande peut être exécutée (c'est-à-dire si le compte dispose de suffisamment de fonds). Ceci est un exemple de magasin dérivé et est essentiellement identique à un magasin d'entités.
Voici comment le magasin d'entités recherchera notre exemple après avoir traité toutes les commandes.
De toute évidence, par rapport à un Event Store à part entière, il s'agit d'un exemple très primitif. Et c'est l'une des raisons pour lesquelles de nombreux développeurs n'utilisent que le magasin d'entités. Dans ce cas, le solde du compte courant est disponible immédiatement et il n'est pas nécessaire de traiter tous les événements historiques.
Cependant, Event Sourcing n'exclut pas les magasins d'entités. Souvent, les magasins d'entités sont également présents dans les projets Event Sourcing.
Fin de la première partie.
