Quale dovrebbe essere il carico utile di un "evento di dominio" generato tramite "modifica acquisizione dati"?

Question

Quale dovrebbe essere il carico utile di un "evento di dominio" generato tramite "modifica acquisizione dati"?

#1 da (0 voti)

1

Utilizzo del design basato sul dominio e creazione di eventi ...

Dato che ho una tabella di 3 colonne: (A, B, C) con una riga di dati esistente: (1, 2, 3), quando aggiorno la riga per contenere i valori (1000, 2, 3) e Eseguo uno strumento progettato per acquisire le modifiche ai dati ed emettere eventi associati, quale di questi dovrei aspettarmi dal payload dell'evento emesso?

{date: 1234, newState: (1000, 2, 3)}
{date: 1234, prevState: (1, 2, 3), newState: (1000, 2, 3)}
{date: 1234, prevState: (1, 2, 3), newState: (1000, 2, 3)}, changed: (1,0,0)}
{date: 1234, newState: (1000, 2, 3), changed: (1,0,0)}
{date: 1234, changedData: (A: 1000)}
{date: 1234, changedData: (A: 1000), previousData: (A: 1)}

"Idealmente" vorrebbe che il design degli eventi supportasse un'ampia varietà di usi attuali e futuri, tra cui:

replica dei dati
registrazione di controllo
attività attivate da eventi
inserimento di eventi retroattivi (eventualmente)

I miei pensieri:

La risposta 1. sopra è la più semplice, ma i clienti che non si preoccupano della colonna "A" finiscono comunque per dover reagire a questo evento, poiché non possono sapere dall'evento stesso cosa è cambiato.
Risposta 5. sopra è il più pulito - cattura solo la "differenza". Lo svantaggio è che costringe il cliente a caricare le modifiche per visualizzare un registro di controllo dello stato completo su ogni modifica. Anche le attività attivate da eventi potrebbero richiedere la conoscenza dello stato completo per funzionare.
La risposta 4. sopra è forse più generalmente utile? Trasporta ciò che è cambiato, ma alcune informazioni contestuali a fianco.
Risposta 2. sopra cade in una trappola di affermare ciò che era lo stato precedente. Cosa succede se questo non è lo stato precedente nel tuo datastore, forse in un ambiente di test? Respingi l'evento come non valido? Inserire in modo retroattivo un evento significa cambiare tutti i campi "previousState" degli eventi successivi?

domain-driven-design database event-sourcing

posta user1305156 09.10.2014 - 15:29

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design database event-sourcing

Autenticazione reciproca solo in JSON o AJAX? Perché JSF non tende a rendere il valore specifico costante su alcuni tag

score 0 · Accepted Answer

Hai due richieste in competizione e penso che tu debba scegliere quale delle due vuoi vincere. Richiesta 1, per avere un record fisso dello stato in ciascun evento. Utile per un controllo rapido mediante la scansione dei messaggi non elaborati

Richiesta 2, per registrare le modifiche applicate in ciascun evento, per facilitare l'individuazione degli eventi.

Queste due richieste sembrano solo leggermente diverse, perché non fare entrambe le cose? All'interno di quella sottigliezza, tuttavia, scoprirai che sono completamente in conflitto. La domanda 1 specifica che la conoscenza di, e quindi il controllo della mutazione di stato avviene con il mittente, in quanto ha una conoscenza assoluta dello stato (prima o dopo il cambiamento). La domanda 2 specifica che la conoscenza e il controllo della mutazione di stato si verificano nel ricevitore.

La domanda 2 è adatta per il sourcing di eventi (registrando che è richiesta una modifica), la domanda 2 non lo è, è, come dici tu, più di un log di audit (registrando che si è verificata una modifica)

Quindi, per questo motivo, dal momento che si desidera eseguire il sourcing di eventi, l'unico formato possibile utilizzabile è 5.

Una parte di questo è probabilmente causata dal fatto che stai ricevendo il sourcing di eventi ascoltando la mutazione che si verifica in un database, mentre dovrebbe essere il contrario, gli eventi che causano la mutazione.

Questo non vuol dire che non puoi far funzionare il tuo schema e soddisfare i tuoi requisiti, ma non pensare a questo come ad un evento, poiché non è ciò che desideri realmente.

L'adozione di un'installazione dati basata su eventi potrebbe supportare le tue esigenze in modo un po 'più semplice, ma l'adattamento dei sistemi esistenti a questo può essere molto impegnativo.