Imaginez un monde où le passé est la seule vérité… toute la vérité

Par éric de carufel

Vos systèmes informatiques contiennent sûrement plusieurs bases de données structurées et relationnelles. Vous devez faire des copies régulièrement pour ne pas perdre d’information. Malgré ces précautions, vous perdez tous les états intermédiaires (états du système après un événement passé) de vos systèmes d’information.

Si tout ce qui vous intéresse, c’est l’état final, ce n’est pas trop grave. Toutefois, il y a fort à parier que vous aurez un jour à répondre à des questions du genre :

  • Combien de temps s’écoule entre le moment où un client met un item dans son panier virtuel et le moment où il complète sa transaction?

  • Combien de fois cet item a-t-il été retiré d’un panier d’achats?

  • Quel était l’état de la commande avant le crash?

Si vous n’avez pas défini ces besoins lors de la conception initiale de votre système, vous ne pourrez pas répondre à ces questions. Bien sûr, il vous sera possible de le faire, mais seulement à partir du moment où vous aurez déployé les fonctionnalités nécessaires… Et encore, vous n’aurez des données qu’à partir de ce moment-là.

Je vous propose donc une solution que vous pourrez implémenter initialement et qui vous permettra de répondre à ces questions à tout moment, et même à celles que vous n’aurez pas encore pensé : CQRS et Event Sourcing.

La force de ce duo vient de l’Event Sourcing (J’aborderai CQRS dans un prochain billet.)

Vous souvenez-vous de tout ce qu’on vous a dit à propos des effets de bord? Entre autres, qu’il fallait tout faire pour les éviter?! Et bien dans ce cas-ci, ces effets sont les seules choses qui importent.

Comment fonctionne l’Event Sourcing?

Dans ce type de système, on ne conserve pas les données proprement dites, mais plutôt l’effet de celles-ci, sous forme d’événements dans le passé. Par exemple, si je lance la commande suivante :

var command = new AddItemToCart(cartId, itemId);

Le système produira l’événement suivant :

var @event = new ItemAdded(cartId, itemId);

Une des forces d’un système d’événements, c’est qu’il est maintenant possible de suivre les retraits faits au système, puisqu’au lieu d’effacer de l’information, on en ajoute :

var command = new RemoveItemFromCart(cartId, cartItemIndex);

Ce qui produira l’événement suivant :

var @event = new ItemRemoved(cartId, cartItemIndex);

Dans ce système, tous les événements dériveront de classes de base :

public class EventBase  {    public Guid Id { get; set; }    public int Sequence { get; set; }    public DateTime TimeStamp { get; set; }  }

Une classe d’infrastructure sera aussi nécessaire afin de s’assurer que tous les événements se voient attribué une date et une séquence.

Principe de base

Dans un tel système, seuls les événements ont de la valeur. Ils sont le reflet de ce qui s’est réellement passé. Ces événements serviront à bâtir des modèles de lecture propres à chaque système qui s’y intéresse. Chacun aura sa petite base de données pour répondre à ses besoins immédiats, et les changements n’affecteront qu’un seul système.

Ensuite?

Dans mon prochain billet, j’irai plus en détail et je donnerai quelques exemples sur la valeur apportée par les événements conservés de cette façon.

Autres articles qui pourraient vous intéresser

Développement de logiciels sur mesure | Done Technologies

La valeur des événements de l’Event Store

Dans le billet précédent, nous avons vu comment créer des événements à partir de commandes. Pourquoi ne pas mettre à jour la base de données directement? Pourquoi avons-nous besoin de passer par un Event Store? Parlons un peu de la situation actuelle…
CQRS et Event Sourcing : nos meilleures ressources

CQRS et Event Sourcing: nos meilleures ressources

CQRS est un schéma (« pattern ») d’architecture et de conception qui sépare la lecture des données (requête) des actions (commandes) dans le but de produire un système qui peut facilement être mis à l’échelle (« scaling ») et offrir des avantages utiles. Consultez la présentation d’un de nos experts. Voici quelques articles connexes (anglais...
Custom Software Development | Done Technologies

Les microservices : une architecture Agile — Deuxième partie

Lisez la première partie de cet article ici : « Les microservices : une architecture Agile — Première partie ». Utiliser le DDD (Domain Driven Design) pour créer des microservices En nous appuyant sur la séparation des modèles qu’offre le DDD, nous pouvons rejoindre facilement le même concept qui est à la base des microservices. Il suffit de décomposer...