Glos event sourcing
Event sourcing is an approach to thinking about persistent data where the primary record is a log of all events that make updates. A traditional representation of database state can be entirely recreated by reprocessing this event log. Event sourcing's benefits include strong auditing, creation of historic state, and replaying of events for debugging and analysis. Event sourcing has been around for a while, but we think it is used much less than it should be.
From http://www.thoughtworks.com/articles/technology-radar-july-2011
Maybe we can simplify this: "An event store is an approach to persistence where we persist the changes, and not the current state". Tom Janssens
I think there's plenty of good material that could be used in this definition at below-link. Since it's whole-sale cut & paste, I wanted to put it as a comment so people can pick which parts are most relevant:
In this discussion I refer to encapsulating all changes to an application state through events, I could easily state all of this using the word (and pattern) 'Command'. Events clearly share most of the properties of commands - the ability to have their own lifetime, to be queued and executed, event reversal is the same as command undo.
One reason for using event is that the term is as widely used in the field for this kind of behavior. It's common hear terms such as event driven architecture and Event Message.
In the end I went with event because I think there's a subtle, but important set of associations that come with it. People think of a command as encapsulating a request - with a command you tell a system to do X. Events, however, just communicate that something happened - with an event you let a system know that Y has happened. Another difference is that you think of broadcasting events to everyone who may be interested but sending commands only the a specific receiver. When it comes to actual behavior it doesn't really matter. The polymorphic reaction of a system to an X command need be no different to a Y event. Yet I think the naming does affect how people think about events and what kind of events they create.
Command is a classic pattern described in [Gang of Four]. You should also look at [hohpe-woolf] for the contrast between Command Message and Event Message.
From http://martinfowler.com/eaaDev/EventNarrative.html - Josh Elster
It's important to note that just persisting events is not Event Sourcing - it's an Event Log. Greg's definition explicitly includes the rebuilding of state by replaying events. I suggest to use his definition: "storing current state as a series of events and rebuilding state within the system by replaying that series of events". [source] - Martijn van den Broek