!!! Overview[1]
[{$pagename}] fundamental idea is that of ensuring every change to the [state] of an [application] is captured in an [event] [object], and that these [event] [objects] are themselves stored in the __sequence__ they were applied for the same lifetime as the [application] [state] itself.


[{$pagename}] ensures that all changes to [application] [state] are stored as a sequence of [events]. 
Not just can we query these [events], we can also use the event log to reconstruct past [states], and as a foundation to automatically adjust the [state] to cope with retroactive changes.

[{$pagename}] creates a [log|Logging] or [Audit|Auditing] of all the changes. This leads to a number of facilities that can be built on top of the event log:
* Complete Rebuild: We can discard the application state completely and rebuild it by re-running the events from the event log on an empty application.
* Temporal Query: We can determine the application state at any point in time. Notionally we do this by starting with a blank [state] and rerunning the events up to a particular time or event. We can take this further by considering multiple time-lines (analogous to branching in a version control system).
* Event Replay: If we find a past event was incorrect, we can compute the consequences by reversing it and later events and then replaying the new event and later events. (Or indeed by throwing away the [application] [state] and replaying all events with the correct event in sequence.) The same technique can handle events received in the wrong sequence - a common problem with systems that communicate with [Asynchronous Operation].


!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Event Sourcing|https://martinfowler.com/eaaDev/EventSourcing.html|target='_blank'] - based on information obtained 2015-07-24