Adopter l'event sourcing

Les clients disposent de nombreuses expériences et connaissances qui servent de base à leurs projets et influencent la plupart de leurs décisions. Dans bien des cas, suggérer des solutions qui s'éloignent de ces modèles suscite des interrogations qui sont tout à fait compréhensibles. C’est pourquoi il est essentiel de pouvoir expliquer clairement en quoi il vaut la peine de se tourner vers de nouvelles façons de résoudre les problèmes, en remplacement de celles qui sont déjà bien établies.

Cet article parle d’un cas de ce type, dans lequel la résolution d'un problème a exigé une profonde remise en question des pratiques existantes. Il a fallu veiller à expliquer les limites des systèmes existants et s'assurer que tous les usages chers au client seraient également possibles, même avec une solution adoptant une approche différente.

Le défi

Commençons par détailler brièvement l’ampleur du défi puis commençons à esquisser d’éventuelles solutions. L’un de nos clients souhaitait développer un logiciel appelé DAN, dont la tâche principale consiste à calculer la combinaison de données fournies par de multiples sources de données. Chaque source de données fournit des informations sur les entités au fil du temps, et DAN est chargé d'assembler ces fragments pour former une représentation complète de chaque entité.

Toutes les informations traitées par DAN sont livrées via des messages, exposant DAN aux défis propres aux architectures basées sur les messages, tels que des livraisons dans le désordre, manquantes, répétées, etc.

La solution initiale et sa fiabilité

En raison du contexte et de l'expertise du client, la première implémentation de DAN s'appuyait sur un modèle relationnel qui utilisait PostgreSQL en tant que base de données. Ce modèle relationnel est normalisé à l'aide de tableaux dotés d'une fonctionnalité bi-temporelle, créée manuellement. La base de données fonctionne comme un log d’ajout : suite à la réception d'un message, le résultat partiel le plus récent est dupliqué, et le duplicata est combiné avec les informations du message reçu. Toutes les lignes du résultat partiel précédent demeurent intactes et sont marquées comme étant obsolètes, garantissant ainsi qu'il n'existe qu'un seul résultat partiel valable à un moment donné. La conservation de tous ces résultats partiels est cruciale pour que DAN puisse permettre d’effectuer des contrôles en cas d’erreurs d’usage ou de fonctionnement.

À premier abord, cette approche semble fournir toutes les fonctionnalités de base que le client exige. Alors pourquoi la remettre en cause ?

Que se passe-t-il si une livraison manquante est finalement envoyée plus tard ?

Recevoir une livraison manquée ultérieurement est en réalité une livraison hors commande. Un modèle relationnel rend ces livraisons difficiles : nous avons conservé des résultats partiels qui ont peut-être été construits avec une séquence de messages incorrecte.

Prévenir ce problème est impossible : cela nécessite une connaissance approfondie de la séquence complète des messages, qui, par définition, est infinie (ou aussi longue que la durée de vie d'un citoyen).

Résoudre un tel scénario n’a rien de simple. Nous devons reconstruire tous les résultats partiels erronés, calculés précédemment, en utilisant des messages plus récents que ceux entrant. Pour ce faire, nous éliminons tous les résultats partiels erronés, puis nous évaluons, à nouveau et dans un ordre logique, tous les messages qui provenaient des résultats partiels éliminés. Cette solution implique de stocker tous les messages délivrés à DAN, car il serait impossible de recalculer un quelconque résultat partiel sans le message source.

Quel rapport avec l’event sourcing ?

L'idée des modèles d’event sourcing est de capturer les changements dans le statut de l'application sous la forme d'une séquence d'événements, puis de rejouer l'ensemble de la séquence sur demande, pour reconstruire le statut. L’approvisionnement événementiel possède une fonctionnalité intéressante : la cohérence à terme. Cette fonctionnalité du système garantit que, si aucune nouvelle modification n'est apportée à un élément de données, la lecture de cet élément de données renverra, au fil du temps, la dernière valeur mise à jour.

La cohérence à terme simplifie énormément le traitement des livraisons qui ne suivent pas un ordre logique. Les résultats sont calculés de façon dynamique. Par conséquent, à mesure que de nouveaux messages arrivent, tout calcul de résultat ultérieur incorporera implicitement, dans un ordre logique, tous les nouveaux et anciens messages.

Proposer l’event sourcing

Naturellement, proposer un event sourcing à notre client pour remplacer un modèle relationnel a suscité un scepticisme compréhensible. Après tout, nous remettons en question une solution bien comprise et largement implémentée, avec une approche entièrement différente, qui n’enregistre même pas le statut réel de l'application. Ce qui complique la création de rapports et empêche d'interroger librement les données de l'application. Même si de telles fonctionnalités ne constituaient pas des exigences impératives, elles étaient fortement appréciées par le client.

Dans ce genre de situation, il est crucial de communiquer clairement toutes les difficultés techniques découlant d’une solution. Dans ce cas, l’approche choisie a été de décrire une liste du problème puis de préparer une simulation en imitant des tableaux de base de données à l'aide de Microsoft Excel. Une fois le problème compris, une autre simulation est utilisée pour démontrer comment le problème est automatiquement résolu à l'aide du modèle d’event sourcing.

Discuter et comparer l’event sourcing

Une autre étape délicate consistait à nous assurer que le client adopte la méthode de l’event sourcing en la comparant honnêtement avec la solution antérieure. Il est important de se rappeler que l’on peut facilement passer pour un « charlatan » qui essaie de facturer des heures supplémentaires au client sans réel besoin.

Pour ce projet, un document décrivant l’event sourcing et les modèles relationnels a justement servi à relever ce défi. Le document comparait les deux solutions et mettait en évidence tout élément manquant, qui pourrait freiner ou empêcher l'a mise en place. Il est important de ne jamais juger une solution. Il faut d’abord fournir des données et des informations de façon neutre afin d’alimenter la discussion et obtenir des feedbacks de qualité. Il faut considérer le temps consacré à répondre aux questions et lever les doutes comme un investissement qui permet d’accroître la confiance et de soutenir la solution.

Accepter l’event sourcing

En bref, il faudra parfois se résoudre à accepter que les politiques spécifiques d’un client empêchent la mise en place de certaines solutions. Cette décision peut sembler arbitraire (après tout, c'est le cas), mais nous devons respecter la culture technologique et organisationnelle de nos clients.

Heureusement, nous n’avons pas été confrontés à ce problème ici. L'event sourcing peut offrir à nos clients un mécanisme plus simple et plus facile à maintenir pour garder une trace de toutes les informations dans le système DAN. En effet, des ressources de développement supplémentaires ont été nécessaires pour constituer une base de données interrogeable quotidiennement. Comme cette exigence n’était pas essentielle, la solution a été jugée acceptable.

En conclusion, consulter le client en présentant objectivement les faits (y compris ceux qui ne sont pas bénéfiques) et en soulignant de manière transparente les avantages et les inconvénients, s'est avéré être une stratégie gagnante pour instaurer la confiance et promouvoir l'innovation. Un tel environnement collaboratif est idéal pour créer et proposer des solutions qui simplifient le développement, réduisent les coûts et renforcent la confiance du développeur.