Avons-nous besoin d'un mélange de gestionnaires de commandes synchrones et asynchrones dans CQRS?

Question

1. Un utilisateur s'enregistre sur notre site et se connecte. Un RegsiterUserCommand est envoyé à un gestionnaire de commandes asynchrone.
2. L'utilisateur souhaite modifier son adresse mais la commande RegisterUserCommand n'a pas encore été traitée. Il n'y a pas d'enregistrement utilisateur dans le système.

Est-ce un cas pour les gestionnaires de commandes synchrones? Un enregistrement d'utilisateur serait créé avant l'authentification de l'utilisateur. Ou devrais-je repenser l'exigence aux utilisateurs authentiques après l'enregistrement? Les utilisateurs ne pourront pas accéder au site tant que leur compte n'aura pas été créé. Si les utilisateurs n'accèdent pas directement au système, il est possible que l'utilisation soit réduite.

Est-il courant de voir un mélange de gestionnaires de commandes synchrones et asynchrones dans un système CQRS?

Answer 1

J'ai tout fonctionnant en asynchrone. Pour garder tout simple, les files d'attente sont FIFO; plus il y a un thread de traitement par partition. De cette façon, les commandes sont toujours traitées dans l'ordre d'envoi. De plus, nous avons encore l'évolutivité, puisque thread par partition pourrait être simplement transformé en machine par partition sans avoir besoin de repartitionner la solution entière.

Dans certains cas, nous pourrions avoir besoin d'un traitement synchrone (dans mon cas, il s'agirait d'un enregistrement initial d'utilisateur, car nous devons valider quelques éléments sur le serveur avant de le laisser continuer). Dans ce cas, après l'envoi de la commande, l'utilisateur affiche le message "Veuillez attendre quelques secondes pendant que votre enregistrement est traité". Dès que l'enregistrement est confirmé (ou échoué), l'utilisateur passe automatiquement à l'écran suivant. C'est trivial à faire avec AJAX dans l'interface web. Les interfaces utilisateur de bureau sont encore plus simples.