CQRS e operazioni sincrone (come la registrazione dell'utente)

Question

Sono in procinto di adottare i concetti DDD per progettare i nostri prossimi progetti e in particolare CQRS.

Dopo aver letto un sacco di cose, sto cercando di implementare una semplice Prova di concetto.

Il fatto è che ho ragione bloccato dopo che ho iniziato: p

Sto cercando di applicare questo approccio ad un semplice processo di registrazione degli utenti, dove passi sono:

• utente riempie la registrazione modulo & inviare la richiesta
• l'applicazione crea l'utente
• l'applicazione autentica l'utente (automatica del registro a)
• l'applicazione invia un VERIFICA e-mail zione per l'utente
• L'applicazione reindirizzare l'utente da qualche altra parte con un messaggio di conferma

Da un punto di vista implementativo, ciò che ho finora è:

• L'azione del controller mappe del richiesta dati a un oggetto RegisterCommand
• L'azione del controllore chiede al Command Bus di gestire RegisterCommand
• Il metodo di "registrazione" del gestore di comandi (UserService) crea un nuovo oggetto Utente (di un nuovo comando o un oggetto di fabbrica)
• Il modello solleva RegisterEvent
• Il gestore di comando chiede al repository per memorizzare il nuovo oggetto utente

Questo è tutto, l'azione di controllo non conosce nessuna delle quella.

Quindi, la mia ipotesi è, dal momento che tutto in questo contesto deve essere fatto in modo sincrono (tranne per l'invio di e-mail), posso usare un bus di comando diretto/sincrono e nell'azione del controller, subito dopo l'invocazione del bus di comando , Posso interrogare per un utente di sola lettura (database di query) e se esiste suppone che tutto sia andato a buon fine, così posso dare all'utente un messaggio di conferma.

Il processo di accesso automatico gestito da un gestore eventi.

Supponendo che questo sia corretto, cosa succede se qualcosa va storto, come informare l'utente con le informazioni corrette?

Un esempio comune è spesso utilizzato negli articoli che possiamo trovare su Internet: un cliente paga il suo ordine utilizzando una carta di credito scaduta. Il sistema accetta la richiesta, informa l'utente che tutto è a posto, ma l'utente riceve un'email pochi minuti dopo comunicandogli che il suo ordine non può essere elaborato.

Bene, questo scenario è accettabile in molti casi, ma per alcuni altri non è possibile. Allora, dove sono gli esempi che trattano questi casi d'uso? : p

Grazie!

Answer 1

Il problema con esempi forzati è che è possibile cambiare idea su come funziona il "dominio", quindi è poco utile discutere in particolare di questo esempio. La premessa di base che sembri rinunciare è che dobbiamo presupporre che le cose funzioneranno. Tutto il resto riguarda il rischio e lo attenua. Prendendo questo esempio, se ti chiedo, cosa succede se ho perso 1 registrazione utente in 100000? Cosa succede se ho perso 1 su 10? Perché dovrebbe succedere? Ho problemi più grandi in quel momento? È probabile che gli utenti futuri si registrino di nuovo quando il sistema torna online e funziona come previsto? Quando sarebbe? Cosa accadrebbe se monitorassimo la qualità del servizio e impedissimo agli utenti di registrarsi perché non siamo in grado di garantire la qualità che sono venuti ad associare al nostro marchio? Cosa succederebbe se il server esplodesse o che il data center fosse sommerso? Vogliamo proteggerci da questo? Vedi, non c'è una risposta giusta. Solo varie sfumature di grigio. Quindi, come possiamo mitigare il rischio? Potremmo rendere le cose sincrone ma questa è solo una garanzia in quel momento limitato. Cosa succede se devo ripristinare un backup di 2 ore (ad esempio perché il disco è danneggiato)? Questo è 2 ore di utenti registrati persi (forse). Queste cose accadono ... Volevo solo sottolineare la relatività di ciò che considero un falso senso di sicurezza. Mitigalo, investi in ciò che non puoi permetterti di perdere, assicurati di avere una buona pista di controllo. Probabilmente non è la risposta che stavi cercando ...

Answer 2

Penso che questo caso di utilizzo della registrazione sia più vicino al pagamento per un caso d'uso di ordini di quanto tu pensi.

La maggior parte dei leader di pensiero CQRS suggerisce di convalidare sul lato di lettura prima di emettere un comando, dando così al tuo comando una maggiore probabilità di successo.

Se la convalida non riesce sul lato di lettura, sai come gestirlo - fai in modo che l'utente scelga un altro nome prima ancora di inviare il comando di registrazione. Se la convalida ha esito positivo, invia il comando - ora stai parlando probabilmente qualche centinaio di microsecondi QUASI dove potrebbe entrare un altro utente e ha preso lo stesso nome utente tra il momento in cui hai convalidato il comando e l'hai inviato. Altamente improbabile.

E nel caso molto raro in cui ciò accade, si agisce nello stesso modo dell'esempio della carta di credito scaduta - la prossima volta che l'utente effettua il login, si presenta con una spiegazione e un modulo per inviare un nuovo nome utente - o inviare loro una mail dicendo "hey - qualcun altro ha quel nome utente, per favore clicca qui per selezionarne uno nuovo". Perché funziona? Perché hai un ID univoco per quell'utente.

Guarda una pagina di registrazione utente come Twitter. Non appena inserisci un nome utente, fa una piccola chiamata Ajax e dice "no, questo è preso" o "questo è buono!" Questa è una pre-convalida.

Spero che questo aiuti!