Dans ce chapitre
9.1 Commande et fait
Une commande demande à une autorité de décider. Un événement décrit un fait validé sous une autorité nommée. Un broker ne rend pas un fait valide. ApproveRequest vise le domaine demandes. RequestApproved n’est émis qu’après une transition valide. Le service de notification ne peut pas modifier la décision.
9.2 Contrat explicite
| Élément | Définition nécessaire |
|---|---|
| Acteur et périmètre | Vérification par le service faisant autorité |
| Demande et version | Objet effectivement examiné |
| Identité de commande | Périmètre, contenu comparé et conservation |
| Événement | Identifiant stable et version de sens |
| Erreur | Refus, conflit, reprise possible ou résultat inconnu |
9.3 Validation et livraison
Enregistrer état et intention d’envoi dans une transaction. Le worker traite le travail validé et conserve sa progression. Une livraison peut réussir alors que son accusé de réception se perd : des répétitions restent possibles. Prévoir dédoublonnage ou effets idempotents. Définir l’ordre nécessaire par objet métier et le traitement d’un prédécesseur manquant. Une exigence d’ordre global peut créer une coordination inutile.
9.4 Compatibilité
Changer le sens d’un montant approuvé peut casser un consommateur même sans changer la structure du message. Documenter propriétaire, version, exemples, erreurs et retrait des anciennes versions. L’intégration vérifie identité, données permises, limites, délais, reprises et support. Une clé API ne remplace pas un accord de responsabilité.
9.5 Vérification
- Répéter une commande après délai dépassé.
- Refuser une même clé avec contenu différent.
- Tolérer la livraison répétée d’un événement.
- Définir le traitement des versions incompatibles.
- Récupérer le travail après arrêt du worker.
Le livrable est un catalogue de contrats vérifiables, avant le choix éventuel d’un gateway ou broker.