Une architecture événementielle sépare la production d’un fait métier et les traitements qui réagissent à ce fait, avec une règle claire pour les erreurs et les reprises.
Après la validation d’une commande, le logiciel peut réserver un stock, envoyer une notification et alimenter un rapport. Appeler ces fonctions dans une seule méthode crée des dépendances. Publier un événement rend les réactions séparables, mais ajoute une livraison différée et des problèmes d’ordre.
Définir un fait métier
Un événement décrit quelque chose qui s’est produit, comme « commande validée ». Il contient une référence, une version et les informations minimales nécessaires au consommateur. Il ne doit pas devenir une commande déguisée qui impose une suite d’actions à chaque lecteur.
Documentez qui produit l’événement, qui le consomme et combien de temps il est disponible. Les données sensibles doivent être limitées et protégées. Un consommateur peut relire l’état courant si l’événement ne contient pas le détail complet.
Garantir la livraison
Enregistrez l’événement avec la transaction qui modifie l’état métier lorsque la cohérence l’exige. Une publication après la transaction peut perdre le message si le processus s’arrête entre les deux. Une table de sortie ou un mécanisme équivalent permet de reprendre l’envoi.
Le consommateur doit accepter les doublons et les retards. Les webhooks fiables appliquent la même logique aux échanges externes. Une file d’exception reçoit les messages qui dépassent les tentatives prévues.
Gérer l’ordre
Deux événements d’une même ressource peuvent arriver dans un ordre différent. Ajoutez une version ou une séquence, puis refusez ou ignorez un état ancien selon la règle. Les données agrégées doivent indiquer leur date de calcul.
Observer les réactions
Mesurez l’âge de la file, le délai de traitement, les répétitions et les erreurs par consommateur. Un événement publié avec succès ne prouve pas que la facture ou la notification est terminée. Les indicateurs doivent suivre chaque étape.
Tester les pannes
Arrêtez un consommateur, rejouez un message, envoyez un format inconnu et modifiez la donnée source entre deux événements. Vérifiez que le parcours principal reste cohérent et que le support peut relancer un message sans action manuelle dangereuse.
Sources : Microsoft, architecture orientée événements, AWS, outbox transactionnelle.