Des contrats d’événements entre contextes bornés

Un événement partagé ressemble à l'intégration la moins chère possible. Une équipe publie, une autre consomme, personne ne bloque personne. Ça reste bon marché jusqu'à la première dérive de sens — et le sens dérive en silence, parce que le schéma valide toujours.

Le schéma est la plus petite moitié

OrderPlaced { orderId, customerId, total, currency } dit au consommateur quels champs arrivent. Il ne dit pas :

• Si total inclut la taxe, et dans quelle juridiction cela a été tranché
• Si la commande peut encore être annulée au moment où l'événement part
• Si le même orderId peut apparaître deux fois
• Ce que fera le producteur si le consommateur est indisponible une heure

Chacun de ces points est une décision que quelqu'un a prise. Si elle n'est pas écrite à côté du schéma, chaque consommateur devinera — et ils devineront différemment.

Écrivez les trois choses qu'un schéma ne peut pas dire

Quand il est émis. Pas « à la création de commande » : la transition exacte. Après le succès de l'autorisation de paiement et avant la notification de la préparation. Un consommateur qui le suppose plus tôt construira une fonctionnalité sur un état qui n'existe pas encore.

Ce qu'il promet sur la livraison. Au moins une fois, au plus une fois, ou exactement une fois au seul sens qui existe vraiment : un traitement idempotent côté consommateur. Dites lequel, et dites quelle est la clé de déduplication.

Ce qui a le droit de changer. Ajouter un champ optionnel est sûr. Restreindre une énumération ne l'est pas, et ça se ressemble dans un diff. Nommez la règle de compatibilité pour qu'un relecteur puisse l'appliquer.

Testez la frontière des deux côtés

La chose la plus utile qu'un producteur puisse faire est de publier un test de contrat que le consommateur exécute dans sa propre chaîne. Pas un environnement d'intégration partagé : celui-ci vous dit que les deux systèmes ont marché une fois, ce jour-là, avec ces données-là.

producteur  : publie des payloads d'exemple pour chaque version supportée
consommateur: vérifie que son handler les accepte et produit l'état attendu
CI          : les deux tournent à chaque changement, dans les deux dépôts

Quand un producteur casse la compatibilité, ça échoue dans sa chaîne, avec le nom du consommateur qui va casser. C'est une conversation avant un déploiement plutôt qu'un incident après.

Versionnez le sens, pas seulement le payload

Un champ ajouté est une nouvelle version du payload. Une règle changée — la taxe désormais exclue de total — est une nouvelle version du sens, et cela demande un nouveau type d'événement, pas un nouveau champ. Un consommateur ne peut pas détecter un changement sémantique en inspectant un message : c'est exactement pour ça qu'il doit être visible dans le nom.

Les équipes qui restent rapides ne sont pas celles qui ont le moins de contrats. Ce sont celles dont les contrats en disent assez pour que personne n'ait besoin de lire le code du producteur pour s'en servir.