Gestione della concorrenza ES / CQRS

Di recente ho iniziato a immergermi in CQRS / ES perché potrebbe essere necessario applicarlo sul posto di lavoro. Sembra molto promettente nel nostro caso, poiché risolverebbe molti problemi.

Ho delineato la mia comprensione approssimativa di come un'app ES / CQRS dovrebbe apparire contestualizzata a un caso d'uso bancario semplificato (prelievo di denaro).

Riassumendo, se la persona A ritira del denaro:

• viene emesso un comando
• il comando viene consegnato per la convalida / verifica
• un evento viene inviato a un archivio eventi se la convalida ha esito positivo
• un aggregatore dequeues l'evento per applicare modifiche sull'aggregato

Da quello che ho capito, il registro degli eventi è la fonte della verità, in quanto è il registro di FATTI, possiamo quindi ricavarne qualsiasi proiezione.

Ora, ciò che non capisco, in questo grande schema di cose, è ciò che accade in questo caso:

• regola: un saldo non può essere negativo
• la persona A ha un saldo di 100e
• la persona A emette un comando di prelievo di 100e
• la convalida passa e viene emesso l'evento MoneyWithdrewEvent of 100e
• nel frattempo, la persona A emette un altro comando Prelievo di 100e
• il primo MoneyWithdrewEvent non è stato aggregato, quindi passa la convalida, poiché il controllo di convalida rispetto all'aggregato (che non è stato ancora aggiornato)
• MoneyWithdrewEvent of 100e viene emesso un'altra volta

==> Siamo in uno stato incoerente di un saldo a -100e e il registro contiene 2 MoneyWithdrewEvent

A quanto ho capito, ci sono diverse strategie per affrontare questo problema:

• a) inserire l'ID della versione aggregata insieme all'evento nell'archivio eventi, quindi se si verifica una mancata corrispondenza della versione in caso di modifica, non accade nulla
• b) utilizzare alcune strategie di blocco, il che implica che il livello di verifica deve in qualche modo crearne uno

Domande relative alle strategie:

• a) In questo caso, il registro eventi non è più la fonte della verità, come gestirla? Inoltre, siamo tornati al client OK mentre era totalmente sbagliato consentire il prelievo, è meglio in questo caso utilizzare i blocchi?
• b) Locks == deadlocks, hai qualche idea sulle migliori pratiche?

Nel complesso, la mia comprensione è corretta su come gestire la concorrenza?

Nota: capisco che la stessa persona che preleva due volte i soldi in così poco tempo è impossibile, ma ho preso un semplice esempio, per non perdersi nei dettagli

Ho delineato la mia comprensione approssimativa di come un'app ES / CQRS dovrebbe apparire contestualizzata a un caso d'uso bancario semplificato (prelievo di denaro).

Questo è l'esempio perfetto di un'applicazione proveniente da eventi. Iniziamo.

Ogni volta che un comando viene elaborato o riprovato (capirai, sii paziente) vengono eseguiti i seguenti passaggi:

1. il comando raggiunge un gestore comandi, ovvero un servizio in Application layer.
2. il gestore comandi identifica Aggregatee carica dal repository (in questo caso il caricamento viene eseguito new-ing Aggregateun'istanza, recuperando tutti gli eventi precedentemente emessi di questo aggregato e riapplicandoli all'aggregato stesso; la versione aggregata viene archiviata per uso successivo; dopo l'applicazione degli eventi, l'aggregato si trova nello stato finale, ovvero il saldo del conto corrente viene calcolato come un numero)
3. il gestore dei comandi chiama il metodo appropriato su Aggregate, like Account::withdrawMoney(100)e raccoglie gli eventi prodotti, ovvero MoneyWithdrewEvent(AccountId, 100); se non ci sono abbastanza soldi nel conto (saldo <100), viene sollevata un'eccezione e tutto viene interrotto; in caso contrario, viene eseguito il passaggio successivo.
4. il gestore comandi tenta di persistere nel Aggregaterepository (in questo caso il repository è il Event Store); lo fa aggiungendo i nuovi eventi al Event streamse e solo se il versiondel Aggregateè ancora quello che era quando è Aggregatestato caricato. Se la versione non è la stessa, viene ripetuto il comando - andare al passaggio 1 . Se lo versionstesso è uguale, gli eventi vengono aggiunti a Event streame al client viene fornito lo Successstato.

Questo controllo della versione si chiama blocco ottimistico ed è un meccanismo di blocco generale. Un altro meccanismo è il blocco pessimistico quando altri scritti sono bloccati (come in non avviati) fino al completamento di quello corrente.

Il termine Event streamè un'astrazione attorno a tutti gli eventi che sono stati emessi dallo stesso aggregato.

Dovresti capire che Event storeè solo un altro tipo di persistenza in cui sono archiviate tutte le modifiche a un aggregato, non solo lo stato finale.

a) In questo caso, il registro eventi non è più la fonte della verità, come gestirla? Inoltre, siamo tornati al client OK mentre era totalmente sbagliato consentire il prelievo, è meglio in questo caso utilizzare i blocchi?

Il negozio di eventi è sempre la fonte della verità.

b) Locks == deadlocks, hai qualche idea sulle migliori pratiche?

Usando il blocco ottimistico non hai blocchi, basta solo riprovare.

Comunque, Locks! = Deadlock

Ho delineato la mia comprensione approssimativa di come un'app ES / CQRS dovrebbe apparire contestualizzata a un caso d'uso bancario semplificato (prelievo di denaro).

Vicino. Il problema è che la logica per aggiornare il tuo "aggregato" è in una posizione strana.

L'implementazione più comune è che il modello di dati che il gestore dei comandi mantiene in memoria e il flusso di eventi nell'archivio eventi vengono mantenuti sincronizzati.

Un semplice esempio da descrivere è il caso in cui il gestore comandi esegue scritture sincrone nell'archivio eventi e aggiorna la sua copia locale del modello se la connessione all'archivio eventi indica che la scrittura è riuscita.

Se il gestore comandi deve risincronizzare con l'archivio eventi (perché il suo modello interno non corrisponde a quello dell'archivio), lo fa caricando la cronologia dall'archivio e ricostruendo il proprio stato interno.

In altre parole, le frecce 2 e 3 (se presenti) sarebbero normalmente collegate al negozio di eventi, non a un negozio aggregato.

inserisci l'ID della versione aggregata insieme all'evento nell'archivio eventi, quindi in caso di mancata corrispondenza della versione in caso di modifica, non accade nulla

Le variazioni di questo sono il solito caso - piuttosto che aggiungere al flusso nel flusso di eventi, in genere METTIAMO in una posizione specifica nel flusso; se tale operazione non è compatibile con lo stato dell'archivio, la scrittura ha esito negativo e il servizio può scegliere la modalità di errore appropriata (errore nel client, riprovare, unire ....). L'uso delle scritture idempotenti risolve una serie di problemi nella messaggistica distribuita, ma ovviamente richiede un negozio che supporti una scrittura idempotente.