In this recent post to his site Sam Greenwood gives a high level overview of functionality that's becoming more popular and widely used - event sourcing. His post is a guide to event sourcing "for the rest of us" that aren't familiar with it but want to get an understanding of what it's all about.

Event sourcing can be described as storing the events that happened in your system in the order they happened, in some kind of store. These events are then replayed to recreate state in your system, rather than just having a single row in a table, using event sourcing, you have a full history of actions that happened in your system, and how your state got to the given point that it is in.

He uses a single entity in his illustration, showing how the changes would be put into an EventStore repository (possibly stored in something like this). He then sets up his event system for "members" and shows how to apply the different associated events. This is then sent to the repository for handling and saving to whatever data source you have defined.