Should I really need to implement event sourcing is this case?

Question

An example of use case when event sourcing is applicable here whose excerpt is:

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, event sourcing has a real benefit when we are asking for "why" was there this state rather than "what" was the state.

My application is designed following CQRS principle, but I don't use Event Sourcing yet.

If my application is really focus on the "what" rather than the "why" (since operations are really simple, meaning there are no different ways to end up the same result), is it similar to use the Temporal Pattern as introduced here (persisting object's versions/revisions in database) rather than implementing event sourcing?

Especially for tracking user abuses (like posting some insults) that were temporary (so hidden), a simple query asking for the version where the abuse was commit could be enough and quickly made, rather than having a "script" in staging environment replaying the events to get the right snapshot showing the abuse.

Answer 1

If you only want to be able to understand what happened in your application (i.e. what the state of your application was at a specific point in time and, potentially, who initiated a state change), an Audit Log may well be all you need. An Audit Log does not make any assumptions as to how you store the currently valid state of your application, i.e. it is fairly independent of the core of your application. It also does not make any assumptions as to how state changes are initiated and controlled, i.e. Audit Log does not require that there is any notion of an event in the system.

From my perspective, Event Sourcing pursues objectives far beyond Audit Log. For example, Audit Log by itself does not provide the event replay capabilities that Event Sourcing can provide.