Je comprends que les commandes ne doivent rien renvoyer.
C'est une vue, mais elle n'est pas entièrement gravée dans la pierre. Considérez les écritures (PUT, POST, DELETE) dans HTTP - tous ces messages sont des commandes, dans le sens où ce sont des messages avec demande que l'état de la ressource change, et pourtant ils renvoient tous des réponses.
Alors, comment gérez-vous une erreur au-delà du bus de commande? (Par exemple, un utilisateur s'est enregistré 1 seconde avant avec le même nom d'utilisateur / e-mail).
Comment savez-vous que cette commande a échoué et comment connaissez-vous l'erreur?
Ainsi, dans le cas où vous communiquez directement avec le gestionnaire de commandes, un message renvoyé est un moyen parfaitement raisonnable de reconnaître que la commande a été reçue et traitée.
Si vous utilisez un middleware, comme un bus, qui vous empêche de communiquer directement avec la cible, je vous suggère de rechercher des modèles de messagerie asynchrones - comment obtenir le gestionnaire de commandes pour renvoyer un message au votre interlocuteur?
Une idée est de souscrire au résultat de la commande; cela emprunte à certaines des idées des modèles d'intégration d'entreprise de Hohpe. L'idée de base est que, étant donné que le client connaît le message de commande qui a été envoyé, il est bien placé pour s'abonner à tout nouveau message publié à la suite du message de commande. Le gestionnaire de commandes, après avoir enregistré les données dans le livre d'enregistrement, publie les événements annonçant que le changement a réussi, et le client s'abonne à ces événements - reconnaissant les événements corrects en considérant la coïncidence de divers identifiants dans le message (identifiant de causalité, identifiant de corrélation , etc.).
Les approches alternatives sont un peu plus directes. L'une consisterait à inclure dans le message un rappel, qui peut être invoqué par le gestionnaire de commandes une fois le message traité avec succès.
Une alternative très similaire consiste à réserver de l'espace dans le message de commande pour que le gestionnaire de commandes écrive l'accusé de réception - puisque le client a déjà le message de commande en question, le circuit est déjà terminé. Pensez " promesse " ou " futur complétable". Le message indique au gestionnaire de commandes où écrire l'accusé de réception; cela signale au client (verrou de compte à rebours) que l'accusé de réception est disponible.
Et bien sûr, vous avez la possibilité supplémentaire de supprimer le middleware qui semble gêner simplement la bonne chose.
Par exemple, un utilisateur s'est enregistré 1 seconde avant avec le même nom d'utilisateur / e-mail
Si vous gérez l'enregistrement des utilisateurs de manière idempotante, ce ne serait pas nécessairement une erreur - la répétition des messages jusqu'à ce qu'une réponse soit observée est un moyen courant d'assurer au moins une fois la livraison.