L’Event-Sourcing et le DDD expliqués à nos experts métier

Introduction

Notre entreprise développe des logiciels orientés métier. Ils sont utilisés par des professionnels de notre domaine et par des particuliers qui veulent faire appel à certains de ces professionnels. Nos propres équipes vont utiliser ces logiciels. Ces logiciels sont juste un moyen pour nous d’atteindre un but, et généralement ce but est quelque chose de tout à fait pratique et réel. Les logiciels en production sont toujours représentatifs de ce que les développeurs ont compris du métier : ils traduisent en code, en interface utilisateur, en base de données ce que les experts métier ont tenté de leur transmettre.

Qui sont les experts métier ?

Les professionnels du métier, ceux dont c’est le quotidien. Ils connaissent tous les détails, tous les pièges, tous les problèmes possibles, toutes les règles du métier.

Note : les experts métier ne sont pas nécessairement les cadres, ceux qui organisent et dirigent le travail des autres. Ceux qui « font » ont une expérience tout aussi importante que ceux qui « dirigent ». Leurs visions sont complémentaires et toutes deux nécessaires à la conception de bons logiciels métier.

Or, le fait est que :

• Les experts métier ont une connaissance pratique et précise de leur métier que les développeurs n’ont pas.
• Les développeurs ont une connaissance profonde du fonctionnement des logiciels et de leur fabrication que les experts métiers n’ont pas.

Avant de programmer quoi que ce soit, il faut d’abord :

• Transmettre aux développeurs l’essentiel du métier nécessaire à développer tout ou partie des logiciels.
• Faire en sorte que les experts métier aient une idée du fonctionnement des logiciels métier en cours de développement.

Créer un espace commun

Les projets de développement logiciel ou les développeurs ne s’intéressent pas directement et activement au métier se soldent généralement par des échecs. En même temps, les développeurs ne peuvent pas tout apprendre du métier. Ils doivent s’en faire une idée sélective. Le DDD (Domain Driven Design) est une approche éprouvée pour transmettre aux développeurs ce qu’ils doivent savoir du métier pour concevoir de bons logiciels. Pour ce faire, le DDD vise deux grands objectifs :

• Créer un langage métier et une vision du métier communs entre experts métier et développeurs.
• Incarner ce langage et cette vision dans le code source des logiciels.

En complément, des méthodes itératives AGILE permettent d’associer les experts métier aux étapes clef du développement des logiciels.

Pour atteindre les grands objectifs du DDD, des échanges doivent être organisés entre les experts métier et les développeurs. Une des méthodes employée est l’organisation d’ateliers appelées « Event Storming ». L’idée de ces ateliers est de permettre d’explorer rapidement, en 2 heures environ, un domaine métier par le prisme de ses évènements clefs.

Qu’est-ce qu’un domaine métier ?

Dans une même solution logicielle, les diverses fonctionnalités peuvent répondre à des périmètres métier distincts. Par exemple, dans une gestion de site marchand, les fonctionnalités liées à l’approvisionnement, au stock, à la vente ou à l’expédition sont regroupées en modules répondants aux besoins de leur domaine métier respectif. Ces domaines métier ont des intentions complémentaires (ils servent tous la même cause) mais diffèrent dans leurs besoins fonctionnels et sont (éventuellement) assurés par des personnes différentes.

Intentions

• Approvisionnements : trouver les meilleures produits au meilleur prix, anticiper la demande du stock, passer des commandes, etc.
• Stock : entreposer, rendre accessible, suivre les marchandises, renseigner les approvisionnement de l’état des stocks, etc.
• Vente : renseigner les clients, réaliser des opérations marketing, gérer des promotions, suivre les commandes, etc.
• Expédition : contractualiser avec des transporteurs, négocier les prix de transport, suivre les livraisons, etc.

Event-Sourcing

Imaginons un rôle « Intégrateur ». Ce rôle est celui des personnes qui réalisent la gestion et l’installation du matériel sur site. Ceci forme le domaine métier « Suivis Matériel » dont l’intention est la réception, le stockage et le déploiement sur site de tous les appareils. Ce domaine traite des UC (ordinateurs) installés chez les clients, des serveurs dans le Cloud, des téléphones, des switchs, etc. Chaque appareil doit être suivis pour savoir ou il est, depuis combien de temps et pourquoi.

Le rôle « Intégrateur » va exprimer plusieurs besoins dans son domaine métier :

• Enregistrer un matériel qui vient d’être reçu.
• Spécifier son utilisation tout au long de sa vie : affectation au stock, à une structure cliente, au retours en SAV, etc.
• Lorsque le matériel est obsolète, le mettre dans une remise et l’enlever des matériels disponibles. Il est alors affecté au « rebus ».

Mais plutôt que de lui faire exprimer ces besoins, on lui demande de raconter les « évènements du domaine ». Un évènement du domaine est un moment ou il se passe quelque chose de significatif sur le plan métier – une étape clef porteuse de changement. Ce sont des évènements que l’on va traduire en code et enregistrer :

• Quand un matériel a été référencé, notre expert métier va le désigner comme l’étape « matériel référencé ». Le développeur va le traduire dans le code par un enregistrement de type DeviceRegistered.
• Quand un matériel a été affecté au stock, à une structure ou est en retours au fabricant, notre expert métier va le désigner comme l’étape « affectation du matériel changé ». Le développeur va le traduire dans le code par un enregistrement de type DeviceAffectationChanged.
• Quand un matériel est en fin de vie, on va appeler cela un évènement du domaine métier « matériel enlevé du registre ». Le développeur va le traduire dans le code par un enregistrement de type DeviceRemovedFromRegister.

Note : on parle ici d’évènements qui se sont passé – ils sont tous au passé. Nous verront pourquoi plus tard. Également, l’informatique étant une industrie dominée par les Etats-Unis, par convention, tout logiciel qui a une vocation internationale est programmé avec des termes en Anglais.

Un évènement du domaine est une notion métier. Pour chaque évènement du domaine le développeur créé un type d’évènement dans le code du logiciel, les Events. Chaque Event s’accompagne d’informations clefs. Ces informations sont des informations métier. Dans le cas de notre gestion de matériel, chaque Event porte les informations métier nécessaires à son interprétation :

• DeviceRegistered : le numéro de série de l’appareil nécessaire à l’identifier + le type d’appareil pour savoir de quoi il s’agit.
• DeviceAffectationChanged : le numéro de série de l’appareil, nécessaire à identifier l’appareil en question + une référence de la structure ou du lieu d’affectation (référence client, SAV fabriquant, stock, rebus, etc.)
• DeviceRemovedFromRegister : le numéro de série de l’appareil, nécessaire à identifier l’appareil en question.

Ces évènements du domaine informatisés (les Events) sont enregistrés dans un journal des évènements appelé Event Store ou Event Log, un fichier informatique. Une fois enregistrés dans le journal, ils ne changeront plus jamais : ils sont immuables. C’est pour cela qu’on les nomment au passé. Par exemple, dans un journal de bord d’un navire, on notera qu’une pièce s’est cassé, c’est un évènement passé immuable qui ne peut être changé.

La persistance dans le temps de ces Events n’est pas suffisante. Les utilisateurs du logiciel veulent connaitre l’état des appareils à l’instant T. Sur la base de ces évènements enregistrés est créée une base de données contenant l’état de chaque appareil. La suite des évènements du domaine qui concernent un appareil donné font varier son état dans cette base de donnée. L’enregistrement qui représente l’état d’un appareil s’appel une Entité (ou Entity en anglais). Dans notre exemple, nous avons des Entités Device (appareil) qui sont une modélisation des états résultants de l’accumulation des Events enregistrés dans le journal des évènements du domaine, un peu comme l’est le solde d’un compte bancaire qui varie en fonction des crédits et des débits.

Un système qui raconte l’histoire

Ici, les entités Device (appareil) représentent les états des divers appareils à l’instant T. Chaque Event réalise une transformation des Entités Device. De ce fait, si l’on souhaites reconstruire la bases de données des entités Device, il suffit de réappliquer l’ensemble des évènements du journal des évènements pour retrouver le dernier état des appareils. Ici, ces évènements à rejouer sont de type DeviceRegistered, DeviceAffectationChangedetDeviceRemovedFromRegister.

Retrouver un état antérieur

Pour reconstruire la base de données des Devices dans un état antérieur, il suffit de réappliquer l’ensemble des évènements du journal des évènements jusqu’à la date souhaitée. Cela permet de comprendre des situation anormales ou de retracer un bug.

Comprendre ce qu’il s’est passé

A l’instant T, notre base de données des Device ne contient que le dernier état de chaque appareil. Grâce à l’ensemble des évènement du domaine, on peut retracer la suite des évènements relatifs à toute entité de la base de données. Cela permet de comprendre la suite des évènements qui a permis d’atteindre l’état actuel d’une Entité.

Une source de calcul

Sur la base du journal des évènements, il est possible de réaliser des calculs utiles au métier : KPI, aide à la décision, statistiques, machine learning, détection de fraude, etc. Toutes les autres formes de données étant créé sur la base des évènements du domaine, on peut créer des modèles d’interprétation des évènements spécifiques aux divers cas d’utilisation et répondant aux besoins des divers domaines métier.

Création des événements

Dans le logiciel, le journal des évènements du domaine est la source unique de vérité. Tout est construit depuis les informations que contiennent les Events. La création de ces évènements ont généralement comme origine la volonté d’un utilisateur. On ne saisie jamais directement des évènements : ils sont le résultat indirecte des actions des utilisateurs.

Note : les évènements peuvent aussi avoir comme origine des automates ou des système externes à la solution logicielle.

La volonté d’un utilisateur de changer l’état du système se matérialise par une « commande » (ou Command an anglais). Aucun utilisateur ne peut enregistrer directement un évènement dans le journal des évènements. L’émission des commandes se fait via l’interface utilisateur du logiciel. Une commande est une demande de changement qui va se traduire par la création et l’enregistrement d’un ou plusieurs nouvel événement, si cette commande est acceptée par le composant logiciel – le Command Handler (le processeur de commande)- qui vérifie que chaque commande est exécutable, donc transformable en évènement du domaine.

Le Command Handler « décide » si chaque commande est valide ou pas.

Ici, notez bien le nom de de la commande. La commande contient une volonté ou un ordre, ici « référencer l’appareil » – RegisterDevice – alors que l’évènement du domaine contient un fait, il est au passé – DeviceRegistered.

Règles métier et règles d’intégrités

Chaque commande (chaque volonté de transformation initié via l’interface utilisateur du logiciel) doit respecter des règles pour être transformable en évènement du domaine :

• Des règles métier : ce sont des critères d’acceptation de la commande basés sur des réalités métier, donc déterminés par les experts métier.
• Des vérifications d’intégrité des données : il s’agit de vérifier que les états resteront cohérents après l’application des évènements du domaine. Plus marginales, ces règles peuvent être déterminées par les développeurs.

Exemple de règle métier

Imaginons que notre expert métier nous explique qu’il est impossible de changer l’attribution d’un appareil au « rebus ». Le développeur va intégrer une règle selon laquelle une fois qu’un appareil est attribué au « rebus » suite à l’application d’un Event de type DeviceRemovedFromRegister, il est interdit de changer son attribution. Quand on soumet une commande de type ChangeDeviceAffectation, le Command Handler va vérifier l’état de l’appareil en question. Il « décide » si la commande est valide :

• Si l’état actuel de l’entité Device est attribué au « Stock », à un client ou à autre chose, il va émettre l’évènement DeviceAffectationChanged.
• Si l’état actuel de l’entité Device est attribué au « Rebus » l’évènement DeviceAffectationChanged ne sera pas émis et une erreur sera retournée à l’utilisateur via l’interface utilisateur du logiciel.

Exemple de règle d’intégrité

Si un appareil avec le N. de série 1357 a été enregistré via un évènement DeviceRegistered, une Commande RegisterDevicequi induit la création d’une nouvelle entité Device avec ce même numéro de série serra rejetée par le Command Handler : sur le plan informatique, deux appareils avec le même numéro de série ne peuvent co-exister, sinon on ne sait plus à quel appareil appliquer les évènement.

Les états

Nous avons vu que les entités (Device, dans notre exemple) sont enregistrées dans des bases de données, et que ces enregistrements sont mis à jours en fonction des évènements émis. Ces entités sont consultées à plusieurs moments :

• Quand le Command Handler vérifie les critères d’acceptation de chaque commande.
• Quand on renseigne l’utilisateur de l’état des entités, de sorte à lui permettre de prendre des décisions et soumettre de nouvelles commandes au système via l’interface utilisateur – commandes qui vont changer l’état des entités.

On a donc un système circulaire piloté par la possibilité ou non d’exécuter des commandes.

Détail du processus

(1) L’utilisateur visualise les entités telle qu’elles sont dans les bases de données : il dispose, par exemple, de la liste des appareils.

(2) Dans cette liste, il sélectionne un appareil pour lui changer son affectation. Cela génère une commande qui est envoyée au Command Handler.

(3) Le Command Handler vérifie que cette commande est conforme aux règles métier. (4) Pour cela, il consulte l’état de l’entité.

(5) Si la commande est valide, le Command Handler créé un nouvel événement qu’il envoi pour stockage dans l’Event Log. (6)

(7) L’Event Handler actualise l’entités Device pour refléter la mutation induite par l’évènement du domaine.

(8) Désormais, ces évolutions sont visualisables par les utilisateurs.

Les données liées à une entité (Device, dans notre exemple) ne sont jamais « entrée » ou « saisies ». Elles ne sont pas directement éditables. Chaque intention passe par une commande, qui donne lieu à l’émission d’un évènement qui a une signification sur le plan métier, et c’est cet évènement qui donne lieu à la modification des informations liées à une entité. Il y a toujours un lien entre un évènement signifiant sur le plan métier (« affectation d’un matériel à un client » – « affectation au stock »…) et une mutation dans les bases de données des Entités.

Rôles des experts métier

Reprenons notre « Intégrateur » du domaine « Suivis Matériel » et demandons lui ce que pourrait être un bon logiciel métier, par écrit, sous la forme d’un cahier des charges. Voici ce qu’il pourrait écrire :

« Le logiciel doit m’aider à faire en sorte que les clients aient le bon matériel et à temps, de les dépanner et de retirer le matériel quand il est obsolète. La traçabilité est fondamentale. Trop souvent on perd l’information, donc il faut la stocker (…) Il faut des fiches pour chaque appareil avec un champs N de Série, des zones ou on renseigne les affectations, avec pour chaque affectation des champs dates et un champs texte pour rentrer les références clients…»

Avec un tel descriptif, le développeur va construire un logiciel centré sur l’information : il ressemblera probablement à une suite de tableaux Excel sans réellement signification sur le plan métier, avec de grands formulaires ou on décrit l’état des appareils à l’instant T.

Un échange centré sur les évènements du domaine

Dans le cadre d’un atelier de type Event Storming, on ne demande pas à l’expert métier ce que pourrait être un bon logiciel métier, on va simplement lui demander de décrire les évènements qui jalonnent son flux de travail :

L’expert : « En tout premier lieu, je référence chaque matériel – ca c’est important parce que trop souvent on perd l’information. Ensuite je l’affecte à des espaces internes, le stock par exemple, ou l’atelier, ou bien à des clients. (…) »

Le développeur : « Quelles informations doivent accompagner l’évènement d’enregistrement ? Peut-on parler de référence ? Est-ce qu’une affectation c’est le bon terme ? Doit-on parler d’espace d’affectation ? »

Les évènements du domaine, les commandes et les règles métier sont identifiée grâce au dialogue entre les experts métier et les développeurs. Les états – c’est-à-dire les Entités – sont identifiés par déduction de la combinaison des évènements, des commandes et des règles métier. Ce processus mental est « naturel » pour les experts métier et est beaucoup plus efficace sur le plan du développement de logiciel.

Bénéfices d’une vision évènementielle

• Les experts métier ne parlent pas de formulaire, de listes, de champs, de menus ou de boutons : ils parlent de leur métier. Quand les experts métiers parlent de formulaire, de listes, de champs, de menus ou de boutons, ils parlent d’un métier qu’ils ne connaissent pas qui est celui des développeurs – et pas seulement : celui des Designer UI/UX ou des ergonomes.
• Ce sont les questions des développeurs aux experts métier qui font émerger le langage commun (nommé Ubiquitous Language en DDD) : ils se mettent d’accord sur des termes qui, quand il sont employés par les développeurs, font toujours sens pour les experts métier. Ce sont ces termes qu’on retrouvera dans le code source des logiciels.
• Il n’y a pas de modélisation de la réalité. Les développeurs ne cherchent pas à inventer des concepts, des boites, des modèles pour essayer de faire rentrer dans leur logiciel les concepts qu’ils déduisent d’un cahier des charges produit par les experts métier. On ne parle que d’intentions, d’évènements et de règles métier : on ne modélise pas des données avec des relations dans le but de reproduire la réalité, on retrace les intentions et on enregistre les évènements qui en découlent.
• Le modèle de données (c’est-à-dire la définition des Entités, de leurs champs et de leurs relations), découlent des évènements répertoriés et des commandes à valider. Le modèle de données n’est là que pour rendre disponible les informations agrégées que contiennent les évènements. Ces informations permettent aux utilisateurs de prendre des décisions et au Command Handler de décider si une commande est conforme aux règles métiers et d’intégrité.
• Les vraies données, celle sur lesquelles tout repose, ce sont les évènements enregistrés dans le journal des évènements : toutes les autres données en dérivent. Toutes les autres données ne sont que transitoires. Toutes les autres données peuvent être supprimées et reconstruites sur la base de évènements enregistrés dans le journal des évènements.

Modèle vs Evènement

Quand la conception d’un logiciel est réalisée via une modélisation de la réalité (on a des appareils donc on créé une table « Device »), cela donne généralement un logiciel à faible valeur ajoutée. Il dispose de grandes listes et de formulaires de saisie avec un nombre très important de champs à remplir. Ils amplifient la complexité. Ce type de logiciel n’a pas plus de valeur qu’un fichier Excel.

Quand la conception d’un logiciel repose sur l’émergence du langage métier commun entre développeurs et experts métier (principes du DDD) et considère les évènements du domaine comme unique source de données (principe de l’Event-Sourcing), le logiciel est bien davantage aligné sur les besoins réels du métier. On considère que l’automatisation, la gestion des états et la présentation de l’information strictement essentielle à la prise de décision à l’instant T sont les bénéfices de tout logiciel métier : le but de ce type de logiciel est de masquer ou gérer la complexité.

Lexique du domaine DDD et Event Sourcing

Par la lecture de ce document, en quelques minutes vous venez d’acquérir un langage commun avec les développeurs DDD, celui du domaine métier de la programmation informatique en Event Sourcing. C’est cette même démarche que le DDD recommande de faire avec tous les experts des divers domaines métiers.

Termes du langage commun

Langage commun / Ubiquitous Language
Domaine métier / Domain
Evènement du domaine / Domain Event ou Event
Journal des évènements / Event Log ou Event Store
Commande / Command
Processeur de commande / Command Handler
Processeur d’évènement / Event Handler
Entité / Entity
Règle métier / Business Rule
Intégrité des données / Data Integrity