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.