Mostrando cambiamenti in vista quando si utilizza CQRS & DDD con il dominio Eventi & ServiceBus

Question

Sono un po 'confuso circa il flusso in un sistema che utilizza gli eventi di dominio per costruire il modello di lettura. In particolare, come possiamo fare con il fatto che l'utente si aspetta di dati (e la sua vista) per cambiare quando si completa un comando, ma a causa della nostra architettura di sistema (non-blocking chiamate a pubblicare gli eventi) il database effettivo non potrebbe cambiare prima della pagina viene ricaricata?

spero di spostare il disegno di uno dei nostri sistemi più in linea con CQRS con eventi e un bus di servizio.

Diciamo che il mio flusso va come ad esempio:

1. User pulsante scatta in Vista per eseguire compito di rimuovere Metodo di pagamento dal loro account.

2. Regolatore chiama PaymentMethodRemovalService, passando accountid & paymentMethodId.

3. Controller utilizza AccountRepository per recuperare account e chiama account.RemovePaymentMethod (id)

4. Convalida conto che il funzionamento possono verificarsi e pubblica evento PaymentMethodRemovedMessage (accountid, paymentMethodId)

5. A causa pubblicazione eventi è asincrona, ora dobbiamo tornare dal servizio e il ritorno vista dal controller! - , ma il nostro dati effettivi non è ancora aggiornato

6. Un gestore, IHandle , sente l'evento e rimuove la riga reale dal DB

Quindi, qual è un ragazzo di fare?

I poteva semplicemente, dire, rimuovere il div che è stato visualizzato il metodo di pagamento. Questo può funzionare in uno scenario di AJAX, ma cosa succede se sto usando Post-Redirect-Get per supportare i client non-JavaScript. Poi mi si vuole possano mia Get e la lettura dei dati dal lato Query delle cose, potenzialmente prima che sia aggiornato.

faccio a mostrare solo una notifica dicendo che la loro richiesta di rimuovere il metodo di pagamento è stata presentata? (Che non sembra amichevole, ha un senso per la presentazione di un ordine, ma non per, diciamo, modifica di un indirizzo).

C'è un modo per riconciliare l'introduzione delle modifiche come eventi asincroni disaccoppiati e che mostra i dati degli utenti che riflette la loro attuale cambiamento?

EDIT: La mia domanda è molto simile a , DDD sincronizzazione database di report I hanno da dire, la risposta data lì e anche accennato qui, ha un po 'di odore ad esso - litigare l'interfaccia utente per mostrare un aggiornamento che è fuori della band con la lettura DB, per così dire. Speravo in qualcosa di un po 'più pulito.

Answer 1

Se si sono bloccati nel modello di richiesta / risposta si potrebbe adottare un modello di richiesta / risposta correlata. Per ulteriori dettagli, controllare il campione pagine asincrone nel download NSB. Questo dimostra di richiesta / risposta in un ambiente ASP.NET. Ci sono alcuni esempi ASP.NET MVC là fuori se questo è più la vostra passione.

Quando si introduce l'elaborazione asincrona si accettano che i dati saranno stantio. Si può sostenere che il momento in cui si esegue una query al DB i dati sono già vecchio (latenza di rete, tempo ecc di rendering). Dal momento che i dati sono già vecchio, dobbiamo chiederci quanti anni è abbastanza buono?

Una cosa da considerare è che il trattamento è un po 'fuori uso. Fase 3 dovrebbe essere convalidare il comando prima di inviarlo al server e poi i passi 3, 4 sarebbe venuto dopo 6. Il database deve essere aggiornato solo se il comando è valido e l'evento dovrebbe essere pubblicato solo se il database viene aggiornato con successo.

Answer 2

Questo problema viene definito come 'Coerenza Eventuale'. Ci sono chiari modi di avvicinarsi. Il primo punto da fare è che ogni sistema ha eventuale consistenza sia che utilizzino eventi asincrone o meno. E 'solo che hai scelto di rendere esplicito, mentre la maggior parte degli altri sistemi solo rendere l'utente di attesa fino a quando l'aggiornamento è completo. Entrambi gli approcci sono validi finché sono scelti in modo esplicito.

Qualche tempo fa ho scritto un post sul blog su questo tema, che si possono trovare utili. Lo si può trovare qui: 4 modi per gestire Eventuale coerenza sulla UI

Ecco una versione corta:

Opzione 1 - Utilizzare una schermata di conferma. Se si utilizza un'applicazione bancaria sul telefono probabilmente avete visto questo in azione. Trasferimento dei soldi e alla fine del processo, si sono prese per una schermata di conferma prima di essere portato di nuovo al tuo account. Questo dà il tempo di sistema per tornare al passo.

Opzione 2 - fingere. Se l'operazione l'utente sta tentando è altamente probabile che avere successo, allora fingendo può essere un approccio legittimo. Questo è spesso utilizzato per l'acquisto di biglietti che sono in forte domanda. La transazione può passare attraverso, ma in seguito le scopre società il biglietto era già stata venduta millisecondi prima. Il beneficio per l'azienda è che hanno la vendita piuttosto che rischiare di perdere i clienti. Fino a quando il sistema è costruito con attenzione questa situazione dovrebbe verificarsi raramente e quindi non essere un problema complesso.

È anche possibile utilizzare la correlazione di id per consentire di sottoscrivere successo o il fallimento delle operazioni.

In ogni caso, la speranza che fornisce alcuni spunti di riflessione.