Riscrivi eventi in EventStore

4

Sto pensando a quale sia il modello corretto per gestire questo caso in CQRS / Event Sourcing:

Ho creato eventi per calcolare un equilibrio e il sistema entra in produzione.
Per sbaglio, questa implementazione ha un bug e il calcolo del saldo è sbagliato.

Devo correggere l'implementazione e riscrivere gli eventi nell'archivio degli eventi così come le istantanee?
Le implementazioni dell'archivio degli eventi forniscono ciò immediatamente o devo risolverlo a livello di DB sottostante?

In un ambito più ampio: cosa succede se la firma dell'evento cambia (ad esempio più campi aggiunti o campi rinominati)?

Ho trovato queste diapositive che dicono che la riscrittura è la strada da percorrere: link

    
posta Alexander Zeitler 26.06.2016 - 16:57
fonte

2 risposte

2

OK sto per aggiungere una risposta rapida, davvero bisogno di più dettagli sul tuo caso particolare per spiegare penso.

Non dovresti mai riscrivere eventi negli archivi di eventi.

Gli eventi nel negozio dovrebbero essere immutabili e non cambiare mai.

Se si verifica un evento che non è corretto, è necessario creare un evento di correzione che si applica all'oggetto.

vale a dire:

  1. account create
  2. ritiro modifica saldo a - £ 100
  3. correzione dell'errore saldo corretto a - £ 90

Leggendo tra le righe della tua domanda, penso che tu stia confondendo gli eventi tenuti nello store, con le azioni che si verificano in risposta a quegli eventi.

In questo caso probabilmente abbiamo un evento di ritiro e un servizio di calcolo del saldo che risolve il problema. diciamo che il servizio di calcolo del saldo ha un errore in cui non si aggiunge un supplemento di £ 10 a tutti i prelievi e si desidera modificare la logica per risolvere il problema.

Tuttavia, il tuo problema è che tu costruisci lo stato dell'oggetto dagli eventi nello store, quindi se l'applicazione di tale evento di ritiro include la chiamata al servizio per elaborare il nuovo saldo, cambiare l'implementazione di quel servizio cambierà la cronologia di tutti i tuoi oggetti.

quindi il tuo evento di ritiro v1 si presenta come

withdraw(amount = £90)

ma viene salvato come

withdrawal
 amount = £90
 new balance = -£100

il tuo ritiro v2 viene sostituito da

withdraw(amount = £90, applyCharges = false)

ma viene salvato come

withdrawal
 amount = £90
 applyCharges = false
 new balance = -£90

durante la costruzione dell'oggetto dall'archivio eventi viene utilizzato il nuovo valore di bilanciamento anziché chiamare il servizio per calcolare il nuovo saldo

    
risposta data 27.06.2016 - 11:46
fonte
0

La saggezza comune è considerare immutabili gli eventi in un negozio di eventi, dal momento che l'Event Store funge anche da fonte di verità dal punto di vista dell'audit e se gli eventi sono stati modificati, significa che è impossibile determinare retrospettivamente l'effettiva foglia 'stato del dominio in un dato momento nel replay degli eventi.

Nel tuo esempio con il buggy balance in produzione, non sarai in grado di nascondere l'errore da parte degli auditor - è probabile che sia un'idea migliore per compensare il saldo errato, aggiungendo una successiva, contraria transazione che corregge il saldo.

Tuttavia, abbiamo occasionalmente ritenuto opportuno modificare l'event store: il nostro dominio non è così sensibile dal punto di vista finanziario.

Resequencing of events

  • Occasionalmente, riceviamo eventi che arrivano in ordine cronologico (questo può essere comune quando gli eventi vengono inviati con tecnologie non FIFO come REST e HTTP o se ci sono più fonti di eventi con latenza diversa). Anziché riordinare cronologicamente gli eventi ogni volta che leggiamo l'archivio eventi, si è ritenuto che fosse più performante correggere la sequenza nell'archivio eventi stesso, in modo che l'archivio eventi possa essere letto di nuovo in un ordine naturale di streaming.

Cancellazione di eventi

  • Gli eventi che riceviamo sono generati da esseri umani e, abbastanza frequentemente, vengono commessi degli errori e gli eventi precedenti sono "annullati". Ancora una volta, per motivi di prestazioni, piuttosto che applicare eventi ridondanti solo per avere "annullato", è stato ritenuto più veloce (e più facile) taggare (logicamente) sia l'evento originale, annullato, sia l'evento di cancellazione come "cancellato", e questi sarebbe ignorato in tutte le pieghe future. Se non lo facessimo, dovremmo scrivere esplicitamente la logica 'annulla' per ogni diverso tipo di evento ricevuto.

Ri: Che dire del cambiamento dello schema dell'archivio degli eventi nelle versioni più recenti - questo è un problema difficile da risolvere. Idealmente, tutte le nuove versioni dovrebbero essere compatibili all'indietro con versioni precedenti (e se vengono introdotti nuovi campi, questi dovrebbero avere i valori predefiniti appropriati). Altrimenti, apparentemente dovrai scrivere script di migrazione degli store degli eventi per tradurre versioni precedenti di eventi in nuovi.

    
risposta data 01.11.2017 - 07:12
fonte

Leggi altre domande sui tag