Abbiamo bisogno di un mix di gestori di comandi sincroni e asincroni in CQRS?

Question

1. Un utente si registra sul nostro sito e si connette. Un RegsiterUserCommand viene inviato a un gestore di comandi asincrono.
2. L'utente desidera modificare il proprio indirizzo ma RegisterUserCommand non è ancora stato elaborato. Non vi è alcun record utente nel sistema.

Si tratta di un caso per gestori di comandi sincroni? Verrà creato un record utente prima di autenticare l'utente. O dovrei rivedere il requisito per gli utenti autentici dopo la registrazione? Gli utenti non potranno accedere al sito fino a quando il loro account non sarà stato creato. Se gli utenti non riescono ad accedere al sistema immediatamente potrebbero esserci dei ritardi nell'utilizzo.

È comune vedere una combinazione di gestori di comandi sincroni e asincroni in un sistema CQRS?

Answer 1

Ho tutto in esecuzione in asincrono. Per mantenere tutto semplice, le code sono FIFO; inoltre c'è un thread di elaborazione per partizione. In questo modo i comandi vengono sempre elaborati nell'ordine di invio. Inoltre abbiamo ancora la scalabilità, dal thread per partizione può essere semplicemente convertito in macchina per partizione senza la necessità di ripartizionare l'intera soluzione.

Ci sono alcuni casi, in cui potremmo volere l'elaborazione sincrona (nel mio esempio sarebbe la registrazione iniziale dell'utente, dal momento che abbiamo bisogno di convalidare alcune cose sul server prima di lasciarlo andare avanti). In questo caso dopo che il comando è stato inviato, all'utente viene visualizzato il messaggio "Attendere qualche secondo, mentre la registrazione è stata elaborata". Non appena la registrazione è confermata (o fallita), l'utente viene automaticamente portato alla schermata successiva. Questo è banale da fare con AJAX nell'interfaccia utente web. Le interfacce utente desktop sono ancora più semplici.