In un sistema CQRS Domain Driven Design, le FAQ indicano che una saga non deve interrogare il lato di lettura (http://cqrs.nu). Tuttavia, una saga ascolta gli eventi per eseguire comandi, e poiché esegue comandi, è essenzialmente un "client", quindi perché una saga non può interrogare i modelli letti?Perché i saghe non possono interrogare il lato letto?
Sagas utilizza il modello di comando per aggiornare lo stato del sistema. Il modello di comando contiene regole aziendali ed è in grado di garantire che le modifiche siano valide all'interno di un determinato dominio. Per fare ciò, il modello di comando ha tutte le informazioni disponibili di cui ha bisogno.
Il modello di lettura, al contrario, ha uno scopo completamente diverso: struttura i dati in modo che sia adatto a fornire informazioni, ad es. da visualizzare su una pagina Web.
Poiché la saga ha tutte le informazioni necessarie attraverso il modello di comando, quindi non ha bisogno del modello di lettura. Ancora peggio, l'uso del modello di lettura di una saga introdurrebbe un accoppiamento aggiuntivo e aumenterebbe considerevolmente la complessità complessiva del sistema.
Ciò non significa che non è assolutamente possibile utilizzare il modello di lettura. Ma se lo fai, assicurati di capirne le conseguenze. Per me, quella barra è piuttosto alta e ho sempre trovato una soluzione diversa.
Sagas non deve interrogare il lato di lettura (proiezioni) per le informazioni di cui ha bisogno per svolgere il proprio compito. Il motivo è che non puoi essere sicuro che il lato di lettura sia aggiornato. In un sistema coerente finale, non si sa quando la proiezione verrà aggiornata in modo da non poter fare affidamento sul suo stato.
Ciò non significa che le saghe non debbano contenere lo stato. In molti casi le saghe hanno bisogno di tenere traccia dello stato, ma poi la saga dovrebbe essere responsabile della creazione di quello stato. Per come la vedo io, questo può essere fatto in due modi.
Può accumularne lo stato leggendo gli eventi dall'archivio eventi. Quando riceve un evento che deve attivarsi, legge tutti gli eventi di cui ha bisogno dal punto vendita e crea il suo stato in un modo simile a quello che fanno gli aggregati. Questo può essere reso performante in Event Store creando nuovi flussi.
L'altro modo è che esso continua ad ascoltare gli eventi dall'archivio eventi e lo stato di creazione e lo memorizza su alcuni archivi di dati come fanno le proiezioni. Basta fare attenzione con questo approccio. Non è possibile rispondere alle saghe nello stesso modo delle proiezioni. Se è necessario modificare il modo in cui si memorizza lo stato e si desidera ricostruirlo, assicurarsi di non eseguire i comandi che sono già stati eseguiti.
Ma cosa succede se non ci interessa che i dati siano solo alla fine coerenti, cioè se il valore è un po 'vecchio? Tutti i comandi provenienti dall'interfaccia utente sono basati su dati vecchi (dati proiettati che non sono stati aggiornati dalla query). Non abbiamo problemi con questo. Personalmente, penso che le saghe potrebbero forse essere considerate un po 'come un cliente. PS Riesco a capire che potrebbero esserci degli scenari quando sono necessari dati transazionali consistenti, quindi sostengo pienamente l'utilizzo dell'evento in più per mantenere aggiornati i dati in saga. –
Si tratta principalmente di separazione delle preoccupazioni. I responsabili di processo (saghe) sono macchine statali responsabili del coordinamento delle attività. Se il gestore di processo desidera modificare il cambiamento, invia comandi (asincroni).
Inoltre: qual è il modello letto? È una proiezione di un gruppo di eventi che sono già accaduti. Quindi, se il processore si preoccupasse di quegli eventi ... non avrebbe dovuto sottoscriverli da sempre? Quindi c'è un odore da modella qui.
Possibili problemi:
Il process manager avrebbero dovuto essere l'ascolto dei messaggi precedenti nel flusso, in modo che sarebbe stato nel giusto stato quando questo messaggio è arrivato.
L'evento corrente deve essere più ricco (in modo che i dati che il responsabile processi "ha bisogno" siano già presenti).
... variazione: il gestore comandi deve invece ascoltare un evento diverso e QUELLO dovrebbe essere più ricco.
La query che si vuole in realtà dovrebbe essere un comando per un aggregato che conosce già la risposta
e in mancanza di tutto il resto
inviare un comando a un servizio che esegue la query e invia gli eventi in risposta . Sembra strano, ma è già prassi comune che un manager di processi invii un messaggio a un servizio di pianificazione, per essere "riattivato" quando passa una certa quantità di tempo.
OK, ma per quanto riguarda questo scenario (http://stackoverflow.com/questions/34257897/how-are-consistency-violations-handled-in-event-ourcing)? Raccomanderesti che l'event store fosse reso più smart (complicato), consentendo di essere interrogato da coppie chiave/valore aggregate arbitrarie? – magnus
È necessario essere in grado di ricostituire un aggregato dall'archivio eventi per poter verificare le regole aziendali: questo è il modello del comando. Ovviamente, questo è un po 'più complicato di quando si usa un ORM: questo è il compromesso che hai fatto quando hai scelto ES. – theDmi
Non hai risposto alla domanda nel mio commento. Con la domanda SO referenziata, c'è un AR 'Ordine' e un AR 'Cliente'. Quando il 'indirizzo postale' del' Cliente' viene aggiornato, la saga deve recuperare tutti gli 'Ordine' non ordinati appartenenti al cliente per aggiornare' deliveryAddress' (si tratta di una relazione 1-a-molti in termini SQL, anche se sono entrambi AR in termini DDD). Come faresti a fare la saga senza accedere al modello letto? – magnus