

A Peep inside a C# Application Service  - darindlaw
http://themvcblog.typepad.com/programming/2012/10/a-peep-inside-a-c-application-service.html

======
skrebbel
> _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.

~~~
emp_
Its part of DDD (Domain Driven Design) universe, an attempt to have standard
patterns for large enterprisy software.

~~~
facorreia
That's correct, those terms come from Domain Driven Design terminology and are
not related to C#.

You can learn more about it from this book:

Domain-Driven Design: Tackling Complexity in the Heart of Software

[http://www.amazon.com/Domain-Driven-Design-Tackling-
Complexi...](http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-
Software/dp/0321125215)

------
darrenkopp
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.

~~~
rcknight
I was hoping someone would come in and spend the time to explain this, the
comments were getting pretty depressing!

Event sourcing CQRS are very interesting once you get your head around the use
cases.

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

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

~~~
cpher
Glad I'm not the only one who wondered. I was beginning to think I missed the
"latest thing."

------
untog
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/>

~~~
shaydoc
Asp.net webapi is quite good, I have to say!

~~~
untog
I haven't had a chance to look at it, but have heard good things.

The sad thing is that even ASP.NET MVC- which is 100x better than WebForms- is
used 0.001 as much. The same fate may apply to the Web API. It just doesn't
seem like there is much interest.

~~~
glhaynes
Interesting — I've gotten the opposite sense anecdotally: that MVC has become
basically "the way" to do ASP.NET these days.

~~~
untog
I think the reality is as jinushaun has said it- there's a ton of legacy apps,
and new development is in technologies other than ASP.NET.

------
hhudolet
Think its related to this: [http://prezi.com/v9lvosve93i3/changing-the-
mindset-more-obje...](http://prezi.com/v9lvosve93i3/changing-the-mindset-more-
object-oriented-view-at-the-business-domain-modeling/) 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.

------
tarr11
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.

------
Locke1689
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.

~~~
hhudolet
Nope, its not related to any presentation technology or framework.

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

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

