It seems like this article could use explanation as it seems that many of the comments here either are incorrect or are asking for explanation. I am not the author, but I do have a fairly good understanding of what is going on here.

First off, this has nothing to do with asp.net, wcf, etc. This is really JUST about event sourcing, with a tiny bit of "application service" at the start. The application service bit is actually what you would call from asp.net, wcf, nservicebus, some message queue handler, etc.

So I think first we should define a couple of terms used in this that are "Domain Driven Design" terms that I'll flesh out a bit.

* Application Service - This is a significant process whose responsibility does not fit well onto an object. Simplistically, think about this as a cohesive business process that orchestrates various objects.

* Aggregate Root - This is an entity (something with identity, such as a key) that is the logical root of an object graph (though the graph may only be the object itself, as is the case with customer).

Most of what you are seeing in this article is known as "Event Sourcing", which is to say that the current state of an object is built up by the history of events (changes) to the object. Since this is DDD, don't think of changes as in "field a changed value from b to c", but more of logical "business relevant" events like "customer address changed".

So what's happening in this article is this:

The `CustomerApplicationService.LockForAccountOverdraft` method requests the full history of events for the customer and creates the customer instance using those events. We now have a valid customer instance.

Next, we call the `Lock` method on customer, and give it the reason supplied to the `LockCustomer` method. Here, we create a new instance of CustomerLocked, which is an event signalling that a customer was locked. This event instance is pushed into the `Changes` collection and then executed against the customer instance, which sets the `ConsumptionLocked` property to true.

So in event sourcing the objects state is derived by it's previous events, so the `When(CustomerLocked e)` method is called when the matching event is passed to the mutate method. This happens in 2 places: when initializing from previous events, and when we are pushing the new event. The CustomerLocked event is pushed to the Changes collection because the event store will append that event to the stream on commit (transaction completion).

Now, someone stated that this looks like service bus, which is correct, but slightly different. Once the changes have been committed, the event store then publishes those events, typically onto something like a service bus, message queue, etc, and that event can then be consumed by other processes interested in that event.

So, where does this get us? Is this some over-architected ivory tower software? Well, the answer depends on what is important to you. In some scenarios, this is; in other scenarios this is ideal. The answer is basically defined by what matters to the business, which will define if keeping track of the state transitions is useful to you or not.

So, what are the benefits of event sourcing? Basically, the core benefits are the following 2 things:

1. Guaranteed correct state. Since our state is built up by what has happened, which cannot change since it happened, we are guaranteed to be in the correct state. This also protects state from external changes, like integration through a the database that could put things into an invalid state, etc.

2. By virtue of building up ourselves from our events, other things (external processes, etc) can also consume those events in various ways. This is where CQRS comes into play, or rather, why CQRS usually involves an event store for the writeable side.

So, that's a high-level overview of what's happening in the article and on event sourcing, but very simplistic overview, glossing over a lot of other core concepts.