A che granularità sono gli eventi registrati in Event Sourcing?

Question

A che granularità sono gli eventi registrati in Event Sourcing?

#1 da (4 voti)
#2 da (3 voti)

7

Sto aumentando la mia comprensione del sourcing di eventi. La mia comprensione è che fornisce un mezzo per registrare gli eventi mentre accadono in modo che, dato uno stato iniziale comune e un registro di controllo degli eventi registrati, gli eventi possano essere riprodotti per ottenere lo stesso stato finale.

So che a volte gli eventi sono innescati da altri eventi. Quando considero un sistema nel suo insieme, immagino che alcuni eventi verranno attivati esternamente dagli input dell'utente o da un'altra fonte esterna e che altri eventi verranno innescati e elaborati internamente come effetti collaterali. Sto chiamando i precedenti eventi di origine e gli ultimi eventi secondari.

Gli eventi originanti attivano un effetto domino di eventi secondari. Dal momento che gli eventi secondari dipendono direttamente da qualche evento originario, gli eventi secondari dovrebbero essere registrati come parte dell'audit?

Se sei a conoscenza di qualche fonte che discute di questo argomento, per favore cita.

design-patterns event-sourcing

posta Mario T. Lanza 22.10.2014 - 03:51

fonte

2 risposte

4

Da una prospettiva puramente pratica, se includi eventi attivati da altri eventi nel tuo log, ci sono due conseguenze:

Se hai bisogno di riprodurre il log, questi eventi verranno automaticamente attivati comunque, quindi avrai bisogno di un modo per filtrarli
Se in seguito si determina che la logica che genera alcuni di questi eventi non è corretta e quindi si decide di ricostruire il sistema ripetendo tutti gli eventi per rimuovere i dati danneggiati dal bug, il registro conterrà comunque dati non corretti

Da questo punto di vista, sembra chiaro che per lo meno tali eventi dovrebbero essere registrati separatamente piuttosto che insieme con eventi di origine esterna.

risposta data 23.10.2014 - 07:17

fonte

Leggi altre domande sui tag design-patterns event-sourcing

Architettura dei microservizi e contesti limitati Passare i parametri che devono essere copiati in base al valore o al riferimento const

score 3 · Accepted Answer

Penso che tu stia confondendo il sourcing di eventi e il comando di sourcing. C'è una differenza cruciale tra loro. Con il comando di sourcing, si registrano i comandi esterni, come gli input dell'utente. In caso di sourcing eventi, registri effetti di tali comandi, ovvero ciò che hai chiamato eventi secondari.

In pratica, dovresti scegliere il comando o il sourcing di eventi e attenersi ad esso, non combinando questi due approcci. Per quanto riguarda la scelta, sembra che il consenso dell'industria stia orientando verso l'approvvigionamento di eventi. Ad esempio, in Akka, il modulo Akka Persistence è basato sul sourcing di eventi.

L'idea principale alla base della scelta dell'outsour degli eventi rispetto al comando di approvvigionamento è che il primo consente l'idempotenza. Cioè tuttavia molte volte ripetete gli effetti delle vostre operazioni, il vostro sistema finirebbe nello stesso stato, mentre con il comando di sourcing si sta tentando di fare affidamento su un fatto che lo stesso comando eseguito in tempi diversi avrebbe prodotto lo stesso effetto, che è, inutile dirlo, è incauto.