Devo memorizzare un flusso di eventi o semplicemente lo stato di un'entità che cambia frequentemente?

Question

Devo memorizzare un flusso di eventi o semplicemente lo stato di un'entità che cambia frequentemente?

#1 da (2 voti)

2

Sto costruendo un'applicazione basata su CQRS con Kafka Streams. Per la maggior parte delle entità nella mia applicazione ciò implica il sourcing di eventi: catturare mutazioni di stato come eventi e trasformarli in uno stato che può essere interrogato. Gli eventi sono archiviati per sempre in modo che possano essere rielaborati nello stato.

Tuttavia, una delle mie entità cambia frequentemente. È un tipo di "Messaggio". L'utente finale apporta modifiche alla bozza del messaggio nell'interfaccia utente e queste modifiche vengono trasmesse al back-end come patch. L'interfaccia utente esegue automaticamente il salvataggio dopo alcuni secondi di inattività dell'utente. Così come l'utente modifica un messaggio, vengono generati molti eventi di patch. Immagino che un messaggio possa coinvolgere centinaia o migliaia di mutazioni.

Mi chiedo, dovrei memorizzare tutti questi eventi? Posso altrettanto facilmente memorizzare solo lo stato mutato per questa entità e risparmiare spazio. In alternativa, posso memorizzare tutti gli eventi di patch, ma poi devo memorizzare tutti questi eventi che probabilmente non saranno utili per la mia ripetizione. Almeno, non riesco a pensare a nessuna ragione per cui dovrei rivederli. Ma ... chi lo sa? Non riesco a immaginare di preoccuparmi di ogni messaggio mentre si evolve, ma allo stesso tempo mi chiedo, rimpiangerò di non aver memorizzato queste mutazioni come eventi?

Che cosa dovrei fare? Memorizza tutti gli eventi o solo lo stato?

domain-driven-design cqrs event-sourcing

posta Dmitry Minkovsky 17.10.2018 - 21:11

fonte

1 risposta

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

MVP Passive View - Dipendenza iniezione - Modello di fabbrica - Sta testando il comportamento mentre ignora lo stato sufficiente? Best practice per la sincronizzazione dell'app-cloud della rappresentazione del database

score 2 · Answer 1

Come spesso accade quando si parla di architettura e design, la risposta è "dipende".

Non penso che l'event-sourcing della tua entità Message dai tuoi eventi patch sia intrinsecamente una cattiva idea. Ma sembra che introdurrebbe un po 'di complessità nella tua applicazione e dovresti evitare di introdurre complessità laddove non ne hai bisogno. Assicurati che questa complessità extra risolva effettivamente un problema.

Quindi, ad esempio, se la tua app ha l'obbligo di mantenere una cronologia dettagliata delle revisioni di questi messaggi o di consentire a più persone di modificare un messaggio nello stesso momento mentre le modifiche vengono trasmesse a tutti i collaboratori tramite una connessione socket web, ecc., quindi l'event sourcing della persistenza ha molto senso perché rende questi problemi più facili da gestire e ragionare.

Ma se puoi aspettarti che un solo utente alla volta stia modificando un messaggio, e stai semplicemente implementando una semplice funzione di bozza - quindi memorizzare il tuo stato in un singolo record che aggiorni quando viene apportata una modifica, sembra più cosa ragionevole da fare

Eviterei di prendere decisioni di progettazione solo perché potresti averne bisogno in futuro - nella mia esperienza questa è una delle cause più comuni di software troppo ingegnerizzato. Ogni tipo di complessità introdotta in un sistema comporta un onere di manutenzione (manutenzione del codice, infrastruttura, tempo dedicato alla formazione di nuovi assunti, ecc.). Err dal lato della semplicità a meno che i requisiti non garantiscano una soluzione più complicata.

In sintesi: a meno che non sia necessario mantenere questi eventi per risolvere un problema specifico (ad esempio mantenendo una cronologia di revisione di un messaggio), utilizzerei solo un singolo record mutabile per messaggio.