Dans un article précédent, nous avons expliqué ce qu’est l’event sourcing : vous ne conservez pas seulement l’état actuel, mais chaque événement qui y a mené, comme un grand livre comptable dans lequel on ne gomme jamais rien.
Ce que nous avions volontairement laissé de côté, c’est sa limite la plus connue. Et c’est précisément cette limite qui explique l’existence du DCB. En event sourcing classique, vous fixez votre frontière de cohérence au moment où vous modélisez vos événements, et ce choix est ensuite largement figé. Dès qu’une règle métier traverse deux de ces frontières, ça commence à coincer. Le DCB supprime cette rigidité. Nous expliquons ci-dessous comment, avec les vrais concepts, mais sans plonger dans le code.
La limite de l’event sourcing classique
En event sourcing classique, votre frontière de cohérence est l’agrégat (aggregate) : une partie délimitée de votre domaine (un client, une commande, un produit) avec sa propre suite d’événements. Un agrégat, un stream, une frontière. À l’intérieur de cette frontière, vous avez une cohérence forte, garantie par un numéro de version et un verrouillage optimiste (optimistic locking) : vous lisez jusqu’à la version N, et votre écriture ne réussit que si personne n’a ajouté entre-temps la version N+1. C’est simple, et ça passe bien à l’échelle, car chaque agrégat est autonome.
Le prix à payer, c’est que cette frontière est fixée pendant l’analyse, avant même le développement. Deux choses qui doivent toujours changer ensemble doivent se trouver dans le même agrégat. Et une règle qui porte sur deux agrégats, vous ne pouvez pas l’imposer en une seule transaction. L’exemple d’école : une commande qui touche à la fois le stock d’un produit (un agrégat) et la limite de crédit d’un client (l’autre). Ces deux-là, vous ne pouvez pas les contrôler ensemble, en une fois.
Les échappatoires habituelles sont toutes des détours. Un agrégat géant qui englobe tout, mais qui tue le parallélisme et devient ingérable à la longue. Ou un mécanisme de réservation avec une saga qui coordonne les deux : ça fonctionne, mais ça ajoute beaucoup de pièces mobiles, et un état intermédiaire dans lequel le système est momentanément incohérent. Et si vous choisissez mal vos frontières, corriger le tir signifie redécouper vos événements en nouveaux streams : une migration que vous préférez ne pas faire sur un système en production.
Ce que le DCB fait autrement
Le DCB (Dynamic Consistency Boundary) ne fait pas de la cohérence une frontière fixe, mais une condition par commande (au sens CQRS : une action demandée au système), exprimée sous forme de requête sur vos événements.
Voici comment ça marche. Chaque événement reçoit des tags, par exemple produit:123 et client:456. Une frontière de cohérence n’est alors rien de plus qu’une requête sur ces tags. Pour une commande, vous lisez les événements dont votre décision a besoin, vous retenez jusqu’à quelle position vous avez lu et, au moment d’écrire, le store vérifie qu’aucun nouvel événement correspondant à cette même requête n’a été ajouté depuis cette position. C’est exactement le même verrouillage optimiste qu’avant, sauf que la frontière est désormais dynamique au lieu d’être rivée à un seul stream.
Revenons à la commande du client. Nous taggons l’événement de commande à la fois avec le produit et avec le client. Au moment de passer la commande, nous lisons les deux types de faits (les mouvements de stock de ce produit-là et les montants impayés de ce client-là) et nous n’enregistrons la commande que si les deux règles sont encore respectées. Si un collègue a vendu entre-temps la dernière pièce, ou vient de faire passer le client au-dessus de sa limite, l’ajout échoue et une nouvelle tentative suit. Deux règles sur deux choses différentes, imposées de façon atomique en un seul ajout (append), sans saga et sans état intermédiaire.
La seule chose à fixer à l’avance, ce sont les tags eux-mêmes. Si vous oubliez de tagger quelque chose dont vous aurez besoin plus tard, il faudra le rattraper après coup. Mais une nouvelle règle portant sur des tags qui existent déjà ne demande aucune restructuration : c’est simplement une nouvelle requête.
Pourquoi c’est intéressant pour votre PME
1. Des règles sur plusieurs entités, imposées de façon atomique
Beaucoup de vraies règles métier sont du type « seulement si X et Y ». Ne livrer que si c’est en stock et que le client reste dans sa limite de crédit. Ne planifier une intervention que si le technicien est libre et que le client n’a pas de rendez-vous qui se chevauche. Le DCB impose une telle règle en un seul contrôle, au lieu de passer par une coordination fragile entre des éléments séparés.
2. Moins de détours, donc moins de code et moins de bugs
Les sagas et les mécanismes de réservation, c’est beaucoup de machinerie : des événements en plus, des états intermédiaires, une logique de compensation pour le cas où ça échoue à mi-chemin. Le DCB en supprime l’essentiel. Moins de code, c’est moins de choses qui peuvent casser, moins de maintenance et, au bout du compte, moins de budget : un thème récurrent dans notre façon d’éviter l’overengineering.
3. De nouvelles règles sans revoir la structure
Comme la frontière est une requête et non une structure fixe, un nouvel invariant n’est généralement qu’une nouvelle requête sur des tags existants, sans redécouper votre historique. Votre logiciel plie au lieu de casser à chaque nouvelle question métier.
4. L’unicité et le « une seule fois » deviennent triviaux
Pas deux clients avec le même numéro client, un créneau de rendez-vous qui ne peut être réservé qu’une fois, pas de double traitement quand quelqu’un clique deux fois sur « envoyer ». En classique, ce sont des problèmes étonnamment tenaces, que l’on résout souvent avec une table de réservation séparée ou un read model. Avec le DCB, ils se ramènent à ce même contrôle unique : n’enregistrer que si rien ne s’est passé entre-temps avec cette donnée.
Tout se joue dans vos tags
Bien utiliser le DCB revient à un seul choix : la largeur de vos frontières. Si vous taggez une règle aussi précisément qu’elle l’exige, vous obtenez une cohérence forte exactement là où ça compte, sans collisions inutiles. Si vous tracez la frontière trop large, par exemple « tout ce qui concerne ce client très actif doit toujours être cohérent ensemble », les écritures se bousculent et doivent réessayer. Bien choisir ses tags, c’est donc la moitié du travail, et c’est justement là qu’intervient notre expérience.
Si vous voulez voir des exemples détaillés, vous les trouverez sur dcb.events.
En bref
L’event sourcing donne à votre entreprise une mémoire qui grandit avec elle. Le DCB fait en sorte que les règles qui portent sur plusieurs parties de cette mémoire à la fois restent applicables de façon fiable, sans les détours qui rendaient autrefois ces règles coûteuses et sources d’erreurs.
Pour les PME dont les processus sont vraiment imbriqués (stock, facturation, réservations, un pipeline CRM), c’est exactement l’outil qui lime les angles vifs de l’event sourcing. Pour nous, ce n’est d’ailleurs plus une question à part : quand nous faisons de l’event sourcing, nous le faisons de cette façon.
Vous vous demandez si c’est adapté à votre projet ? Un échange sans engagement avec Tandem Studio ne vous coûte rien et vous apporte au minimum une réponse claire.
