Consistenza costante e approvvigionamento degli eventi

0

Come gestire un prossimo tipo di situazione in generale:

Ho definito due tipi di radice aggregati AR1 e AR2. L'AR2 detiene l'identità basata sul valore dell'AR1. Devo mantenere la coerenza finale tra questi aggregati, quindi se qualche comando modifica lo stato di AR1, devo cambiare gli stati di ogni oggetto AR2, che contengono l'identità specifica dell'istanza AR1. Senza il sourcing di eventi posso interrogare quegli oggetti AR2 dal repository usando findByAR1Id () - metodo, ma come posso ottenere lo stesso risultato usando l'event sourcing?

    
posta Toni 30.12.2016 - 15:17
fonte

1 risposta

1

Without event sourcing I can query those AR2 objects from repository using findByAR1Id()-method but how can I achieve the same result using event sourcing?

Puoi fare la stessa cosa, è solo più brutto da implementare.

Che cosa dice veramente la query nel caso "senza event sourcing"? Trova tutti gli oggetti AR2 in cui lo stato corrente di alcuni campi è AR1.Id. Quindi la tua implementazione di base di findByAR1Id ha un aspetto simile: analizza la cronologia degli eventi per calcolare lo stato corrente di ogni AR2, controlla se i campi corrispondono, ecc.

Ugly.

Con alcuni negozi di eventi, puoi provare a imbrogliare: ottenere tutti gli eventi che impostano la proprietà AR2 sull'ID AR1 che stai cercando, quindi ricaricare solo gli oggetti AR2 a cui fa riferimento quegli eventi e controllare il loro attuale come prima.

possono essere di grande aiuto qui - se questo tipo di cosa succede spesso, quindi usa gli eventi memorizzati come fonte di un modello di lettura che tiene traccia di quale riferimento AR2 ogni AR1. In altre parole, utilizzare gli eventi per creare una replica dell'archivio dati che avresti richiesto in origine e (in modo asincrono) aggiornare l'archivio dati quando vengono pubblicati nuovi eventi. Quando hai bisogno di una risposta a questa query, la esegui sulla vista corrente di quel database.

L'archivio degli eventi è ancora il libro dei record, che è la fonte della "verità"; il modello letto è solo un'immagine di come appariva ad un certo punto nel passato - ci sarà un po 'di latenza tra quando si salva un evento e quando la query mostra la modifica. Se i tuoi aggregati sono ben progettati, di solito è OK - tutti i tuoi aggregati saranno coerenti internamente, ma non sono d'accordo tra loro di volta in volta.

    
risposta data 30.12.2016 - 17:28
fonte

Leggi altre domande sui tag