Application service - part of Bounded Context?

Question

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.

Answer 1

Are Services part of the Bounded Context? Yes. Contexts separate areas of potentially different meanings, and they cover the whole application completely, there is nothing "outside".

What might be confusing is, that Services are actually not part of the Domain. You might think, that Domain-Driven Design is all about the Domain, but for some reason Eric Evans decided to include technical stuff, that really isn't actually about the Domain. Just look at the names of Services, do they come from the Ubiquitous Language? Certainly not if they end with "Service".

Here is one of my presentations, a part of which questions the idea of Services and specifically looks at some of Vaughn Vernon's Services and shows how to easily change them to "real" Domain Objects:

https://speakerdeck.com/robertbraeutigam/object-oriented-domain-driven-design

Answer 2

I don't know if I understand correctly your doubt, but if what you want to know is whether include or not an application service for each bound context, the answer is yes. You can create and include both an application service and all the structure of DDD architecture if it makes some sense to your solution.

Each Bounded Context, can have a N-Layered architecture. You can visit the sample project of DDD by Vaughn Vernon on github, it should be enough to you fix it.

IDDD_Sample

On the IDDD_Sample by Vaughn Vernon, he has 3 bounded contexts like the agilepm context and the collaboration context including the application, infrastructure, domain model inside it. Also, he has one shared kernel named Common.