Introduction à l’Event Sourcing en PHP

Lors de l’AFUP Day à Nancy, j’ai assisté à la conférence de Maxime Veber intitullée « EventStore & PHP ». Durant cette présentation, Maxime nous a présenté l’event sourcing en PHP. Ce modèle architectural, combiné au pattern CQRS (Command Query Responsibility Segregation), offre une nouvelle manière de gérer l'état des applications tout en conservant un historique complet des changements.

De cette conférence, je vous propose une introduction à l’event sourcing. Dans cet article, je vous explique aussi comment cette approche peut être implémentée en PHP.

Qu’est-ce que lʼevent sourcing ?

L'event sourcing est un modèle architectural utilisé dans les applications Web pour gérer l'état de l'application de manière révolutionnaire. Contrairement à une approche « traditionnelle » où l’état est stocké directement dans une base de données, l’event sourcing capture chaque changement d’état sous forme d’évènements distincts et immuables. Ces évènements sont ensuite stockés de manière séquentielle, permettant de reconstituer l’état actuel de l’application à tout moment en rejouant ces évènements.

Dans quels cas est-ce intéressant ?

La grande force de lʼevent sourcing est l’historisation complète des évènements. Chacun changement étant inscrit dans la base de données, il devient donc beaucoup plus simple de tracer les étapes pour arriver à l’état courant. Cette caractéristique rend l’event sourcing particulièrement adapté aux systèmes nécessitant une auditabilité précise. Des exemples d’utilisation ? Je pourrais vous citer les applications bancaires ou encore les systèmes de gestion de commandes qui ont besoin de tracer les opérations réalisées sur les comptes ou durant les commandes.

Rejouer tous ces évènements dans l’ordre chronologique permet non seulement de conserver un historique complet des modifications, mais aussi de faciliter le débogage, l’audit et la mise en œuvre de nouvelles fonctionnalités sans altérer les données existantes.

Enfin, l’event sourcing est également bénéfique dans les processus de récupération après sinistre, où il est essentiel de reconstituer l’état d’une application après un crash.

Comment implémenter l’event sourcing dans une application PHP ?

Avant d’aborder l’implémentation des events, penchons-nous sur le concept de CQRS (Command Query Responsibility Segregation), qui se marie bien avec lʼevent sourcing.

Command Query Responsibility Segregation, c’est quoi ?

CQRS est un pattern qui vise à séparer les opérations d’écriture et de lecture au sein de votre application. Il est important de différencier les « query » qui sont les opérations de dites de lecture, des « command » qui sont celles d’écriture.

Dans une application complexe, il est courant d’avoir plusieurs bases de données, chacune dédiée à des tâches spécifiques. Cette séparation des flux est cruciale pour optimiser et spécialiser chaque type d’opération. En segmentant ainsi les tâches, on réduit la complexité globale de l’application et par conséquent, on améliore ses performances.

Chaque type d’opération est pris en charge par un « handler », une classe dédiée qui a pour mission de gérer et d’appliquer la logique propre à chacune des opérations. Cette approche, a pour bénéfice, de structurer davantage le code et de rendre l’application plus maintenable et évolutive.

Enfin, CQRS s'intègre très bien dans une architecture hexagonale. On pourra finalement rajouter notre système de gestion d'event sourcing au sein de cette architecture. Pour aller plus, nous avons un article sur ce sujet : Implémentation d’une architecture hexagonale avec Symfony.

Création dʼun Event Store

Lʼevent store est lʼespace persistant où sont stockées les séquences dʼévènements de votre application. Il existe plusieurs solutions pour implémenter un event store en PHP. Vous pouvez opter pour votre base de données relationnelle classique dans laquelle vous créerez une table prévue à cet effet ou bien utiliser une solution de base de données exclusive à lʼevent sourcing telle que EventStore. Voir exemple ici.

Voici un exemple pour créer une nouvelle table pour un Event Store dans la base de données habituelle, qui stockerait tous nos évènements :

CREATE TABLE events
( 
    id        SERIAL PRIMARY KEY, 
    stream_id BIGINT NOT NULL, 
    version   BIGINT NOT NULL, 
    data      JSONB  NOT NULL, 
    UNIQUE (stream_id, version) 
);  

• stream_id : entité ciblé par la modification
• version  : entier incrémenté à chaque modification sur un certain flux
• data : la donnée mise à jour dans cet évènement

À partir de cette table, il est possible d'enregistrer toutes les opérations effectuées sur une entité précise, identifiée par son stream_id. Lorsqu’une nouvelle modification est apportée, une nouvelle entrée est ajoutée en base pour ce stream_id. Pour obtenir l'état actuel d'une entité, il faut parcourir ses évènements en respectant, évidemment, l’ordre des versions. Une fois tous les évènements empilés, nous obtenons l’état courant.

Quels sont les défis de l’event sourcing ?

Si l’event sourcing offre de nombreux avantages, il comporte également des défis importants. Je vous ai listé les points essentiels à prendre en compte :

• Préparation - Ce modèle d’architecture est bien plus complexe que le modèle classique. En amont, Son implémentation demande un temps de préparation, de réflexion et de recherche sur le fonctionnement.
• Complexité – L’event sourcing introduit une complexité supplémentaire dans le projet. En effet, vous devez gérer le stockage et la diffusion des évènements… et la reconstruction de l’état.
• Évolution des schémas d’évènements – Au fur et à mesure que votre application évolue, il est probable que le schéma de vos événements doive changer. Cela nécessite une gestion rigoureuse des versions d'événements et potentiellement des mécanismes de migration pour mettre à jour les anciens événements.

En résumé, l'event sourcing, associé à CQRS, offre une approche puissante et flexible pour la gestion de l'état des applications. En particulier pour les environnements complexes qui nécessitent un audit et une traçabilité détaillées. En capturant chaque changement sous forme d'événements immuables, il devient possible de reconstruire l'état actuel de n'importe quelle entité à tout moment. Cependant, pour une mise en œuvre efficace, cette approche demande, en amont, une réflexion approfondie et une bonne compréhension de vos besoins. Et après son déploiement, il est crucial d’avoir une stratégie d’évolution des schémas d’évènements.

Voilà, j’espère que cette introduction vous sera utile pour mieux comprendre ce modèle architecturale. Mes collègues ont également rédigé d’autres articles issus des conférences vues pendant cette journée. Je vous invite à les consulter :

• Architecture à mettre en place pour un SaaS en fonction du client
• Maintien et scalabilité d'une application vieille de 20 ans
• Principes et implémentation d’OpenTelemetry dans des projets PHP
• Game-changing CSS : les techniques pour des sites Web performants
• Container, the hard way : un voyage à travers la complexité des conteneurs
• Comprendre le TDD : principes, architecture hexagonale et types de tests

Crédit photo : scyther5