L’Architecture event-driven au cœur du SI Maisons Du Monde

Pour construire un SI robuste et évolutif, il convient de limiter le couplage entre les composants. Le style d’architecture event-driven offre une opportunité d’y parvenir.

Nous vous proposons de découvrir la manière dont nous l’avons abordé pour construire le SI Maisons du Monde.

Le système fonctionnel c’est quoi ?

Nous sommes convaincus que la donnée doit être au centre de toutes nos préoccupations. A ce titre, nous avons organisé le SI autour de blocs fonctionnels cohérents, chacun d’entre eux portant un périmètre unique de données métier. On parle souvent de produit pour définir chacun de ces blocs fonctionnels, nous avons choisi le terme système fonctionnel, pour éviter tout amalgame lié à notre activité de retailer.

Chez Maisons Du Monde, les données sont gouvernées par l’équipe Data Gouvernance, en collaboration avec les métiers, puis documentées dans le dictionnaire de données.

On parle alors d’un SI data-centric.

Le référentiel

Le principe adopté pour implémenter notre SI et l’organiser en systèmes fonctionnels, est donc de créer des référentiels de données uniques pour chaque SF.

Chaque référentiel de données est responsable de :

• Persister les données dont il est référent, en s’appuyant sur une base de données (n° 1 sur le schéma).
• Exposer des services synchrones (API), pour permettre aux IHM et aux autres composants back-office du SI de les manipuler (n° 2 sur le schéma).
• Informer le reste du SI lorsqu’une donnée est créée/modifiée, en publiant un message dans un topic (n°3 sur le schéma).

On parle d’émettre un event, dans une architecture event-driven (voir $ « Les topics »).

En aucun cas un composant du SI autre que celui qui porte l’API du référentiel n’est autorisé à interroger la base de données d’un référentiel en direct, il doit passer par une API du référentiel.

Les fronts

Un front porte la responsabilité de présenter les données au client et de lui permettre de suivre un parcours fonctionnel pour agir dessus.

Un système fonctionnel peut donc mettre à disposition des fronts qui interrogeront les référentiels du SF pour présenter les données (n°4 sur le schéma).

Ces fronts pourront également s’appuyer sur les référentiels d’autres SF, uniquement en lecture, pour faciliter et améliorer l’expérience utilisateur.

Enfin, ces fronts pourront mettre à jour les données des référentiels du SF, en s’appuyant sur leurs API.

Prenons par exemple le système fonctionnel responsable du produit. Il dispose d’un front permettant de créer des produits, d’en modifier les caractéristiques (taille, poids, …). Il peut aussi présenter des informations connexes, portées par d’autres SF, telles que le stock du produit ou les photos du produit. Ce sont des infos utiles aux utilisateurs mais qui ne sont pas portées par le même système fonctionnel.

Les orchestrateurs

Certaines données métier possèdent un état qui évolue selon un workflow métier. Les orchestrateurs sont chargés de faire évoluer l’état de ces objets.
Chaque référentiel peut donc être équipé d’un ou plusieurs orchestrateurs.

Un orchestrateur peut réagir aux événements produits par d’autres référentiels (n°5 sur le schéma).

• Exemple : Un orchestrateur de type flow qui mettra à jour le statut de la commande client en réagissant aux événements publiés par le référentiel transport.

Un orchestrateur peut aussi être autonome pour faire évoluer l’état des objets métier du référentiel (n°6 sur le schéma).

• Exemple : Un orchestrateur de type batch qui annulera une commande au bout de 10 jours si elle n’est pas payée.

Un orchestrateur peut enfin recevoir des demandes pour déclencher une mise à jour de l’état d’un objet, on parle de request (ou de command), dans une architecture event-driven (n°7 sur le schéma).

• Exemple : Un orchestrateur de type flow permettant de traiter des demandes d’impression asynchrones d’étiquettes de produits.

On parle de réponse à un event, dans une architecture event-driven (voir $ « Les topics »).

Un référentiel maître de la donnée, des orchestrateurs pour faire évoluer les états de celle-ci, des fronts pour la présenter et interagir avec l’utilisateur et enfin des topics pour la communication : Ce sont tous ces éléments qui composent l’architecture Event Driven de Maisons Du Monde.

Les Topics

Les topics permettent la communication entre les différents systèmes fonctionnels. Dans une architecture event-driven, cette communication est massivement asynchrone, de manière à découpler au maximum les composants.

On distingue alors 2 types de topics, liés à ce style d’architecture et de communication :

• Les topics de type event : Chaque fois qu’un référentiel crée/modifie une donnée, il a la responsabilité d’en poster la photo (l’état complet de l’objet à l’instant t) dans un topic de type event (n°3. sur le schéma ci-dessus).
  Exemple : Le référentiel des commandes publie dans un topic chaque commande passée par un client pour que le SI puisse réagir à cet événement.
• Les topics de type request : Les orchestrateurs qui proposent des services asynchrones le font au travers de topics de type request (n°7 sur le schéma ci-dessus). Ce type de topic fait sens quand l’appelant a seulement besoin d’une confirmation de prise en compte de sa demande mais pas un besoin transactionnel sur le résultat.
  Exemple : Le référentiel des contacts propose un topic de type request permettant de désabonner un client aux e-mail marketing.

Article co-écrit avec Pierre FEVRIER

Illustrations signées Alexia Robinet