I am having a hard time understanding where the Application Services fit in with DDD and Onion architecture. Up until a few days ago I thought of them as part of domain model, but I began to question that.
I know what Application Services are for.
- Orchestrating use cases.
- Fetching Aggregate Roots via repositories (repo abstractions).
- Sending emails, handling sessions of sorts...
However, I have seen authors frequently not implementing Application Services at all, but rather dumping these responsibilities on the MVC Controller and this confuses me.
My line of thinking goes:
- Are Application Services part of a Bounded Context? Does not feel like it, since Bounded Context consists of Aggregates. I have never seen an Application Service being declared part of an aggregate.
- Are Application Services part of the outermost layer in Onion? No, UI/API/Infrastructure related elements live there.
- So where do does an Application Service fit? If we were to move each Bounded Context into a standalone namespace/assembly/library, Application Service would not be able to follow.
What am I missing? Perhaps one Application Service is allowed to work with domain models strictly from a single Bounded Context (plus Shared Kernel)? That might allow grouping Application Service with respective Bounded Context.