Explorons Event Sourcing ensemble
ELEPHANT technologies, l’ESN locale et à taille humaine spécialisée sur 2 métiers : le développement et le pilotage autour de expertises : Embedded & IoT, Digital & Agile.
Aujourd’hui, retrouvez Robert notre elephantech développeur fullstack (java, angular) qui nous parle du pattern d’architecture Event Sourcing. Il va commencer par vous présenter dans cet article les patterns tactiques et les patterns d’architecture, puis il vous expliquera les concepts clés et les avantages d’Event Sourcing, et enfin il vous montrera son architecture et sa terminologie.
Let’s go !
Explorons Event Sourcing ensemble
Les patterns tactiques et d’architecture :
Event Sourcing est un pattern d’architecture qui permet de développer de manière très efficace des architectures pilotées par des évènements. Dans le design pattern, on y retrouve deux types : les patterns tactiques et les patterns d’architectures.
Les patterns tactiques sont les patterns de type structure, comportement et création. Les patterns structures montrent la meilleure façon de connecter des objets pour leur permettre d’évoluer indépendamment des évolutions futures, c’est-à-dire comment créer une application fermée à la modification et ouverte à l’extension ? Les patterns comportements montrent comment les objets doivent interagir pour pouvoir résoudre un problème de la meilleure façon, et les patterns création montrent quelle est la meilleure façon de créer des objets.
Les patterns d’architectures sont utilisés pour améliorer la qualité, l’efficacité et la fiabilité du logiciel de développement. On peut citer le pattern MVC, Inversion de contrôle, Injection de dépendance, CQRS, et Event Sourcing. Par exemple, le pattern MVC permet de développer la couche présentation d’une application, il est basé sur beaucoup de patterns tactiques.
Qu’est-ce que Event Sourcing ?
Event Sourcing est un pattern d’architecture qui consiste à capturer tous les changements d’états d’une application comme séquence d’évènements. Ce qui veut dire que, dans une application, il ne faut pas se concentrer sur l’état courant de l’application mais enregistrer tous les évènements qui s’y sont produits, et qui permettent à l’application d’être dans son état actuel. Il est donc important de se concentrer sur la séquence de changements d’états (évènement métiers) qui ont abouti à l’état courant de l’application.
Exemple :
Prenons le cas de figure suivant : Nous voulons créer une application pour gérer un compte bancaire. Si vous consultez votre compte aujourd’hui, ce qui va vous intéresser est son état, le solde. Si j’utilise l’approche Event Sourcing dans mon système, je ne vais pas enregistrer l’état actuel du compte, je vais plutôt enregistrer l’ensemble des opérations qui ont été effectuées sur le compte depuis sa création jusqu’à maintenant. L’état actuel de mon application est déterminé à partir de l’historique des opérations qui se sont produit dans le compte.
A partir d’une séquence d’évènements, nous pourrons agréger l’état courant de l’application. Et c’est le principe d’Event Sourcing, où tout changement de l’état a une cause unique.
Quels sont les avantages d’Event Sourcing ?
Les avantages sont nombreux, notamment le fait que l’on puisse construire facilement une base d’Audit avec Event Sourcing. C’est-à-dire qu’il faut enregistrer toutes les causes qui ont permis de changer l’état de l‘application. Ce qui vous permettra d’avoir une base lors de l’audit du système d’informations. Il sera donc plus simple d’auditer le système puisque vous pourrez revenir à une date précise dans l’historique.
Analyse et debug : retrouver facilement l’origine des bugs de production et les analyser en revenant sur une séquence d’évènements.
Reprise des données : supposons que vous avez perdu votre base de données. Grâce à Event store, il suffit de rejouer tous les évènements métiers enregistrés pour retrouver l’état de l’application.
Performance : utiliser Event Sourcing c’est utiliser un broker pour la communication asynchrone, où les brokers sont généralement scalables. Par exemple, un broker comme KAFKA a été développé pour supporter la charge, oubliez les problèmes de performance.
A partir des évènements contenus dans Event store, nous pouvons créer plusieurs projections dans des modèles différents. Un Event store est une base de données dans laquelle il n’y a qu’une seule table : on enregistre le numéro de l’évènement, son type, et son contenu (payload).
L’architecture et la terminologie d’Event Sourcing :
Pour commencer, une application reçoit des commandes. Une commande est une sollicitation externe dont l’intention est de changer l’état de l’application. Elle est un objet qui est immuable, c’est-à-dire qu’il n’y a pas de setter, et elle peut être une requête http.
Un agrégat représente l’état de l’application, et c’est sur cet état que l’on va prendre une décision. Pour un agrégat, il faut un constructeur sans paramètre obligatoire. Lorsque l’application reçoit une commande, il va déclencher le traitement métier, que l’on appelle fonction de décision ou CommandHandle. Ce sont des fonctions qui implémentent des règles métiers entrainées par une commande. Chaque fonction est un écouteur de commande, c’est-à-dire que lorsqu’une commande se produit, elle l’exécute. Lorsqu’une fonction de décision est exécutée, si les conditions sont également exécutées alors il faut publier les événements dans Event Store. Un Event Store est une base de données qui enregistre tous les évènements émis par la fonction de décision, qui sont enregistrés dans la table domain_event_entry.
La Fonction de décision = (state,command)=>List[Event]
L’état de l’application ne se trouve pas dans Event Store, on y enregistre plutôt l’historique de l’application. On trouvera dans l’application la fonction d’évolution, un Event Sourcing Handle qui sera déclenché à chaque fois qu’un événement est enregistré dans Event Store. La fonction d’évolution prend les données de l’événement et mute ensuite l’état de l’application. Il n’y a pas de règles métiers, celles-ci se trouvent dans la fonction de décision. La fonction d’évolution ne fait que mettre à jour l’état actuel de l’application.
La fonction d’évolution = (state,event)=>state.
Quand la fonction d’évolution s’exécute, on peut émettre une action qui est une commande interne qui déclenchera une fonction de décision.
Effets de bords : publier les évènements aux applications partenaires. Pour ne pas polluer les partenaires, c’est seulement une fois dans l’état stable qu’il faut informer les autres microservices. Ensuite, il faut publier l’évènement sur Event Bus ou dans un broker. Une fois que celui-ci est publié, les autres microservices vont recevoir cet évènement. Ceux qui sont intéressés vont projeter ces évènements dans leur base de données pour ensuite pouvoir les exploiter.
Il y a un autre pattern qui va venir améliorer la structure des microservices, c’est le pattern CQRS : Command Query Responsability Segregation. Il consiste à séparer la partie lecture de la partie écriture d’une application. Nous vous présenterons dans un autre article le pattern CQRS.
🐘 Nous remercions Robert pour son article et si vous souhaitez découvir d'autres articles techniques, c'est par ici !
Source : https://developer.axoniq.io/event-sourcing/overview