Dovrei davvero implementare l'event sourcing è questo?

3

Un esempio di caso d'uso quando event sourcing è applicabile qui il cui estratto è:

Say, something went wrong in your app and as a result, a user gets blocked for abuse but that user claims to not have done anything to break rules. Now you can go back to your staging environment and play the events leading up to the block in that system and see what happens first hand.

What’s needed for this is a comprehensive log of events for basically any interaction that happens around your app and a staging system to replay events to. Based on the sensitivity of your data you may want to anonymize some details before hand but that’s about it.

IMO, l'event sourcing ha un vantaggio reale quando chiediamo "perché" c'era questo stato piuttosto che "quale" era lo stato.

La mia applicazione è progettata seguendo il principio CQRS, ma non utilizzo ancora l'Event Sourcing.

Se la mia applicazione è veramente focalizzata sul "cosa" piuttosto che sul "perché" (dal momento che le operazioni sono davvero semplici, il che significa che non ci sono modi diversi per ottenere lo stesso risultato), è simile usare Modello temporale come introdotto qui (versioni / revisioni persistenti dell'oggetto nel database) piuttosto che implementare il sourcing di eventi?

Soprattutto per tracciare gli abusi degli utenti (come la pubblicazione di alcuni insulti) che erano temporanei (così nascosti), una semplice query che chiedeva la versione in cui l'abuso era commesso poteva essere sufficiente e rapida, piuttosto che avere uno "script" nella messa in scena ambiente che riproduce gli eventi per ottenere la giusta istantanea che mostri l'abuso.

    
posta Mik378 09.03.2014 - 20:27
fonte

1 risposta

6

Se vuoi solo essere in grado di capire cosa è successo nella tua applicazione (cioè quale stato della tua applicazione si trovava in un momento specifico e, potenzialmente, chi ha avviato una modifica di stato), un Registro di controllo potrebbe essere tutto ciò di cui hai bisogno. Un registro di controllo non fornisce alcuna ipotesi su come si memorizza lo stato attualmente valido della propria applicazione, cioè è abbastanza indipendente dal nucleo della propria applicazione. Inoltre, non fornisce alcuna ipotesi su come le modifiche di stato sono avviate e controllate, ad esempio il Registro di controllo non richiede l'esistenza di alcuna nozione di un evento nel sistema.

Dal mio punto di vista, Event Sourcing persegue obiettivi ben al di là di Audit Log. Ad esempio, il Registro di controllo di per sé non fornisce le funzionalità di riproduzione degli eventi che possono essere fornite da Event Sourcing.

Saluti, Oliver

    
risposta data 02.05.2014 - 19:44
fonte