A Peep inside a C# Application Service (themvcblog.typepad.com)

Ummm, what exactly is a "C# Application Service"?

This post has no introduction and dives right into the details.

> When an Application Service receives control, it loads an Aggregate and retrieves any supporting Domain Services needed by the Aggregate’s business operation. When the Application Service delegates to the Aggregate business operation, the Aggregate’s method produces Events as the outcome.

I'm genuinely curious: does anyone here understand anything about that? What do those words even mean? I mean, even if you assume that the capitalized words are what's being explained, what's a "business operation"?

It's writing like this that give C# and .NET their (mostly undeserved) image of overarchitected concept jungles.

This seems to be some kind of ASP.NET thing. It has nothing to do with the C# language, as far as I can tell.

it's domain driven design, quite some new concepts ey ?

So, I generally like Dependency Injection (except that it makes things hard to debug) The code tends to be cleaner and there's less of it. It's also easier to test.

But I really dislike reading this kind of code. It is just really hard to understand. And if it's hard to understand, it's hard to maintain.

It's stuff like this that gives C# a bad name. If you strip away the enterprise-y, ASP.NET stuff it's usually wrapped in, it's a fantastic language.

After having spent a lot of time working in Javascript (and node.js specifically), I'm diving back into C# in my spare time, but learning to forget all the nonsense- no factories, no web.config, no ASP.NET framework... it's great. One highlight is Nancy.fx[1], a very lightweight web framework. Setting up routes is as simple as:

    Get["/list"] = parameters => {
        return "The list of products";
    };

I'm also developing on a Mac with MonoDevelop- it's a poor cousin of Visual Studio, but it works just fine. I feel like there is a series of "C# without the crap" blog posts to be written- I hope to do so.

[1] http://nancyfx.org/

Think its related to this: http://prezi.com/v9lvosve93i3/changing-the-mindset-more-obje... Event sourcing (eventstore) is different way of modelling complex business logic in object oriented language. Where you think about behaviour and verbs of your business, not data, properties, tables and relations. Not for CRUD apps, web portals, simple web shops, CMSs and similar apps.

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.

This looks like CQRS. Very useful pattern where you need to playback transactions or events for any completed unit of work.