Service de messagerie orientée messages

Statut documentaire : architecture — voir Maturité et preuves.

Rôle

La famille de services de messaging fournit une communication asynchrone entre producteurs, consommateurs, processus Runtime et infrastructures externes. Elle est adaptée lorsque le travail doit franchir une frontière d'exécution sans coupler le producteur à un appel synchrone.

Positionnement

producteur
   -> message / événement
   -> frontière queue ou broker
   -> consommateur
   -> opération applicative ou Runtime

Le messaging est différent d'un channel .NET en mémoire : utiliser les channels de l'hôte pour les pipelines locaux producteur/consommateur, les channels Runtime entre éléments d'exécution Runtime, et un middleware orienté messages lorsque le travail doit survivre ou franchir une frontière de processus, de nœud ou d'infrastructure.

Règles de conception publiques

• définir le contrat de message indépendamment de l'API d'un broker particulier ;
• expliciter les hypothèses de livraison ;
• gérer les doublons lorsque des retries sont possibles ;
• borner ou superviser la croissance des queues ;
• propager le contexte de corrélation et de trace ;
• définir la gestion des rejets ou dead letters lorsqu'elle est supportée ;
• drainer ou abandonner le travail selon une politique d'arrêt explicite.

Adaptateurs de broker

Un déploiement peut utiliser un adaptateur spécifique à un broker. Le produit, le protocole, les noms de queues, les credentials et la topologie de connexion relèvent du déploiement et ne doivent pas contaminer la sémantique métier.

Statut de configuration

Les anciennes classes internes de queues et noms de modules ne sont pas une API publique. Toute configuration concrète de broker doit être validée contre la version du Runtime/module installée.