Il CQRS deve essere attivato e dimenticato, se è necessario leggere la garanzia dopo il comando?

Un modo per visualizzare CQRS è che si tratta di comandi (messaggi) fino in fondo.

Prendendo il tuo esempio:

1. Il livello applicazione invia il comando GiveReward per premiare la gestione con un ID di correlazione.
2. Gestione ricompense attiva un comando CreateTransaction sul contesto limitato dell'account, con l'ID di correlazione incluso.
3. CreateTransaction termina e trasmette un evento TransactionCompleted con l'ID di correlazione.
4. Il livello applicazione ascolta gli eventi TransactionCompleted e lo ricollega alla richiesta originale tramite l'ID di correlazione.

Per il tuo front-end Web puoi estendere questo approccio anche lì. Per esempio. in un approccio react / redux il comando viene inoltrato al server, che aggiorna infine l'archivio redux su un feed websocket che trasmette eventi GiveRewardCompleted.

Altri approcci restituiscono l'ID di correlazione al front-end e fanno in modo che esegua il polling del server per gli aggiornamenti o blocchi sul bordo del server finché non viene ricevuto un messaggio TransactionCompleted.

Does CQRS need to be fire and forget, If we need to read guarantee after command?

CQRS non ha bisogno di essere fuoco e dimenticare. Generalmente riconosciamo comandi che attraversano i confini del processo; è un modo per attenuare i meccanismi di consegna almeno una volta su una rete affidabile.

Here how can I guarantee account management has finish creating read model, So that reward management can read it?

Di solito ci sono due parti del meccanismo: una è una sorta di identificatore di correlazione che può essere usato per abbinare i risultati con il comando, l'altro è un protocollo tentativi.

A un meta livello, si impartisce il comando (12345), e quindi si esegue il polling delle letture, cercando resultOf (12345). Il modello di lettura non è stato aggiornato in un tempo ragionevole, si rinvia il comando; alla fine se sembra che non stia succedendo nulla di buono, fai una pausa.

Vedi anche Nessuno ha bisogno di messaggi affidabili .

No. Questo è un mix di alcuni concetti. L'unico punto principale è che il modello di dati sottostante non è necessariamente esposto allo stesso modo per gli aggiornamenti delle operazioni di lettura. Non c'è niente inerentemente "fuoco e dimentica" di questo concetto. Fire & dimenticare di entrare in gioco con l'asincronicità che può essere applicato (o meno) indipendentemente da come si ritaglia l'accesso al proprio modello di dati.

Se è necessario garantire una lettura dei dati di ritorno, prende in considerazione uno o più comandi precedenti, quindi per definizione che il comando non può * essere fire & dimenticare.

Puoi ottenere un risultato puntuale e supportare F & F o essenzialmente serializzare e attendere fino al completamento dell'aggiornamento. Ovviamente questo non tiene conto della situazione extra in cui altre persone / processi stanno eseguendo aggiornamenti tra i tuoi comandi e le tue letture.

* A meno che non si presuma il risultato senza attendere conferma che potrebbe causare più problemi di quanti ne risolva.

Sì, CQRS riguarda la comunicazione unidirezionale solo , è vero. Ed è spesso usato per la comunicazione asincrona, che sembra essere il problema principale qui (ma anche quando CQRS è implementato in un sincrono , il chiamante potrebbe aver bisogno di ottenere una risposta se la transazione ha avuto successo o meno).

La soluzione semplice qui è di rendere il sistema che recupera ed esegue il comando invia un messaggio di "conferma" al chiamante, che segnala il successo o il fallimento della transazione. Il messaggio è semplicemente un comando nel sistema CQRS, simile ai comandi che avviano una transazione di scrittura.

Il chiamante deve quindi attendere quel messaggio (probabilmente anche in modo asincrono) prima di poter procedere con azioni che prevedono l'esecuzione della transazione.