4 mois avec Broadway

Voilà maintenant 4 mois que j’utilise au quotidien la librairie Broadway pour la gestion de l’EventStore dans un projet en production.

Il y a maintenant plus d’un million d’agrégats et il en est prévu quasiment 5 millions.

Comment cela réagit-il ?

Le système réagit très bien, même en cas de décalage de version entre l’EventStore et le ReadModele.

MS SQL Serveur encaisse plutôt bien la volumétrie, sachant qu’un agrégat a, au minimum, 10 events au cours de sa vie.

Quelles sont les difficultés rencontrées ?

La principale difficulté est liée à l’une des contraintes du projet qui demande l’usage intensif des scripts pour les traitements. Cela nécessite une gestion poussée des transactions SQL afin de limiter les problèmes d’annulation de transaction. En effet, l’EventStore est stocké en base de données et dispose d’une connexion distincte de celle du ReadModel.

Pour le stockage des Events, une transaction ne contient qu’un seul Event (selon le principe de l’Event sourcing, un Event non enregistré ne peut pas être émis sur le bus) alors que la transaction pour le Read Model est enregistrée à la fin du traitement batch effectué sur l’agrégat.

Dans tous les cas, si votre EventStore et votre ReadModel sont dans la même base de données, je vous conseille d’utiliser deux connexions distincte afin d’éviter des problèmes lors de ROLLBACK.

Une autre difficulté rencontrée est la faible résilience du bus de commande. En effet, si le Command Handler ou l’agrégat émet une Exception, les commandes émises ensuite ne seront pas traitées.

Dans mon cas, une commande est envoyée, son traitement dans le Command Handler lève une exception. Le script principal catch l’exception et émet une commande selon la situation. Cette dernière sera mise en file d’attente mais ne sera pas traitée.

Pour contourner le problème, la commande qui lève une exception doit émettre un Event indiquant l’erreur. Charge au script principal de recharger l’agrégat et de vérifier son état.

Il y a sûrement une meilleure méthode pour gérer plus efficacement ces cas. J’attends vos idées dans les commentaires.

Les points positifs ?

Le gros point positif est le suivi de toutes les modifications de l’agrégat tout au long de sa vie. Pouvoir remonter dans le temps et analyser ce qu’il s’est passé est un point très important. La possibilité d’ajouter des informations sur chaque Event est également un plus. Savoir comment a été modifié l’agrégat (ligne de commande ou interface web) et par qui sont parfois des informations très précieuses.

La possibilité de rejouer les événements passés en environnement de développement ou de test est très appréciable. Quoi de mieux que l’utilisation réelle pour vérifier le bon fonctionnement du système?

Est-il envisageable de l’utiliser dans d’autres projets ?

Oui, en utilisant une version stable de la librairie. Mais l’écoute des nouvelles librairies dans le domaine est important.

Quelques liens sur le sujet :