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

Custom Software Development | Done Technologies

Spike Agile : Réduisez les Risques en Développement

Initialement introduite par l’Extreme Programming, il existe une technique qui consiste à ajouter un élément au carnet de produit (product backlog) qu’on peut qualifier de « Spike ». Il s’agit d’un item pour lequel l’équipe s’entend sur une limite de temps à investir. Le but est d’acquérir des connaissances qui sont nécessaires pour réduire le risque, pour...
Votre partenaire de solutions logiciels sur mesure | Done Technologies

Pair Programming : Comment Tirer Profit au Maximum du Codage en Binôme ?

La programmation en paire, communément appelée « Pair Programming », est une technique de développement logiciel Agile qui a été popularisée dans les années 90 par la méthodologie « Extreme Programming ». Une de ses règles est que chaque unité de travail réalisée doit passer entre les mains d’au moins deux membres de l’équipe. Par réflexe, nous pourrions penser...
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...