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

Par éric de carufel

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… Présentement, la majorité des systèmes conservent leurs données dans une base de données relationnelle commune à plusieurs systèmes d’information. La raison de cette centralisation est simple : il est très facile de partager des tables communes entre les différents systèmes. Cette commodité répond à certains besoins :

  • Facilité de maintenance des tables communes;
  • Information intersystème cohérente;
  • Réutilisation de l’information.

Cette centralisation comporte également des inconvénients qui ne sont pas négligeables. Si un ou deux systèmes utilisent ces tables, ce n’est pas un problème, mais dès qu’on ajoute des systèmes dépendants, les problèmes peuvent commencer. Il arrive souvent qu’un nouveau système ait un besoin d’information qui n’est pas couvert par les données actuelles. L’ajout d’une colonne dans la table aura des répercussions sur tous les systèmes qui l’utilisent. De plus, cette nouvelle information sera considérée comme de la pollution pour les autres systèmes. La quantité d’information à transporter sur le réseau augmentera également.

Comment faire pour obtenir les bienfaits de la centralisation sans les inconvénients? C’est là que l’Event Sourcing est intéressant. Considérer le domaine d’affaires comme une succession d’événements simplifie énormément le problème. Même si cette liste d’événements est distribuée sur plusieurs nœuds, ce n’est pas un problème. Chaque événement est écrit une seule fois et il ne changera plus. Si le nœud qui contient les événements n’a plus d’espace, on peut ajouter du stockage sans problème et sans risque de perdre les événements que l’on a déjà. Pour éviter la perte d’événements, nous pouvons utiliser des méthodes de stockage distribué telles que MongoDB auxquelles il est facile d’ajouter des nœuds à la grappe. Dans le prochain billet, je vous expliquerai plus en détail comment faire évoluer vos événements dans le temps.

Autres articles qui pourraient vous intéresser

comment les microservices aident à l'agilité

Microservice et Agiilité: les changements requis à l’ère numérique

L’ère numérique dans laquelle nous vivons présentement nécessite que nous apportions plusieurs changements dans nos manières de faire. Les entreprises qui perçoivent encore le développement logiciel comme un fardeau coûteux et non comme une force de frappe feront bientôt face à de nombreux défis importants. Pour surfer sur la vague technologique, les entreprises doivent pouvoir...
Custom Software Development | Done Technologies

Technique spike : tout ce qu’il y a à savoir sur la technique

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...
Explorer et innover au sein de notre laboratoire | Done Technologies

Développement web: Pourquoi Blazor est le framework idéal?

Début novembre 2018, alors que ce n’était encore qu’un produit expérimental, j’en parlais lors d’un événement que nous avions organisé à nos bureaux. D’ailleurs, mon powerpoint pour la présentation avait été fait avec Blazor, j’en avais surpris plus d’un lorsque j’ai dévoilé le punch à la fin. J’ai suivi l’évolution de cette expérience, qui est...