Hash della versione per risolvere i problemi di Sourcing degli eventi

2

Gli esempi di base che ho visto su Event Sourcing non riguardano eventi fuori servizio, compensazioni di clock in sistemi diversi e eventi tardivi da partizioni di sistema.

Mi chiedo se le implementazioni di Event Sourcing più rifinite si basano su un timbro di versione di oggetti modificati?

Ad esempio, supponendo che il sistema stia rendendo l'entità Client con id di versione ABCD1234 . Se l'utente modifica l'entità, il sistema creerà un evento con i campi modificati E il riferimento dell'ID di versione a quale versione si applica. Successivamente il risponditore dell'evento ha rilevato eventi fuori servizio e li ha uniti.

    
posta SystematicFrank 20.08.2014 - 19:48
fonte

2 risposte

2

Ho fatto qualcosa di simile a un sistema di sourcing di eventi solo di recente. Il dominio deve riprodurre gli eventi nell'ordine corretto, ma il modello di dominio non deve scrivere un evento per l'archivio se un'altra istanza del dominio lo ha appena fatto. Sono andato con un approccio di concorrenza ottimista. Quindi il dominio riproverà il suo comando e, se è ancora valido, verrà creato un nuovo evento con la versione incrementata.

Hai menzionato il risponditore dell'evento che rileva eventi fuori servizio e penso che sia perfettamente soddisfacente. Ma ai miei risponditori di eventi in realtà non importa molto per eventi fuori servizio. Cerco di mantenere i miei schemi di dati progettati per supportare l'aggiunta di dati e se due utenti "modificano" lo stesso dato, lo accetto e procedo. Se è molto importante mi allontano dal sourcing di eventi.

Sto ancora cercando di trovare il giusto equilibrio tra il sourcing di eventi e le operazioni tradizionali.

    
risposta data 20.10.2014 - 21:12
fonte
0

Later the event responder would detect out of order events and merge them.

Possibile, ma non sto vedendo molto di questo nella mia ricerca.

Gli oggetti di origine evento non si iscrivono agli eventi, per quanto osservino flussi di eventi.

Ad esempio, un tipico idioma di reidratazione è che il componente di persistenza recupererà gli eventi dall'archivio eventi e li assemblerà in un flusso, prima che un repository acquisisca il flusso, reidratizzi l'entità di origine evento e offra tale entità al componente dell'applicazione pronto per l'uso.

Dopo aver reidratato l'entità, possiamo proporvi una modifica, raccogliere gli eventi che rappresentano tale modifica e quindi proporre che l'archivio eventi aggiunga questi nuovi eventi allo stream. La garanzia fornita dall'archivio eventi è che, se gli eventi vengono accettati, sarai in grado di recuperare la nuova versione dello stream con gli eventi nell'ordine corretto.

Il solito modo di supportare questo requisito è che gli eventi siano abbinati a un numero di sequenza, che può essere usato per ordinarli all'interno del flusso.

Puoi pensare che questi numeri di sequenza siano id versione, ma probabilmente dovresti tenere presente che sono versioni dello stream, non versioni dell'entità rappresentate dallo stream - non tutti gli stream di eventi sono associati a un dominio oggetto (pensa eventi utente vs eventi dominio o proiezioni che uniscono eventi da più flussi).

Se stai cercando di accoppiare il sourcing di eventi con pub / sub, probabilmente avrai un driver responsabile della ricostruzione dei flussi. E va bene, immagino - in pratica stai creando una facciata in modo che l'abbonamento abbia l'aspetto di un negozio di eventi. Ma tieni presente che solo gli eventi passati vengono pubblicati nel negozio degli eventi; se stai caricando un'entità in modo che tu possa cambiarla, dovrai comunque aggiungere la cronologia delle versioni più recente, quindi stai davvero guadagnando molto provando a ricostruire il flusso localmente? Probabilmente è più facile chiedere all'archivio degli eventi di aggiornarti.

I progetti / query sono il caso dell'angolo dispari: ti interessa il contenuto dello stream, ma non intendi aggiungerlo allo stream. In particolare, è generalmente OK se si è "indietro" in tempo. Lì, gli stream forniti dal driver sottoscritto sono abbastanza recenti da pubblicare una nuova proiezione.

Pub / Sub può ancora essere un modo utile per consumare eventi quando non è necessario il sourcing diretto degli eventi. Un tipico caso d'uso qui potrebbe essere un gestore di processi: un evento appare nella nostra sottoscrizione e determina che vogliamo avviare una nuova istanza di gestore di processo. Quindi il gestore di eventi pianificherà un'attività per caricare una nuova istanza di quel gestore. Il process manager, essendo esso stesso di origine evento, avrà bisogno di accedere al proprio stream per recuperare il proprio stato; ma l'invio dell'evento che deve essere gestito dal gestore dei processi non ha bisogno di sorgenti di eventi e può essere eseguito direttamente dall'abbonamento, nessun driver richiesto.

    
risposta data 18.02.2016 - 06:43
fonte

Leggi altre domande sui tag