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.
