6

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.

Improve this question
1

2 Answers 2

Reset to default
8

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

Improve this answer
7
  • 1
    "Part of Bounded Context, but not part of Domain" - I learned something new today.
    – robotron
    Jul 26, 2018 at 7:35
  • If I were to fetch an entity from another bounded context, would I have to go through that bounded context's Application Service or could I simply go for the aggregates? P.s. I am aware of Anti-corruption layer, so either way I would remap foreign context's entities into host context's entities.
    – robotron
    Jul 26, 2018 at 7:37
  • In general, if you have to fetch an entity from another bounded context, then your context is not bounded enough. "Bounded" means boundary, as in meanings don't leave. Everything you want to do with an entity in a specific context have to be in that context.
    – Robert Bräutigam
    Jul 26, 2018 at 7:52
  • A quick example might help here: I have a CustomerContext.Customer and this is the complete Customer model. I also have (in a different context) a ConsentContext.Person, a scaled-down, heavily transformed version of multiple instances of CustomerContext.Customer (rules guiding this transformation reside in ConsentContext.Person). In my ConsentContext.ApplicationService I fetch ConsentContext.Person through some PersonRepository. This PersonRepository has to get in touch with the CustomerContext' and retrieve the CustomerContext.Customer` and create a new Person.
    – robotron
    Jul 26, 2018 at 8:04
  • @robotron "would I have to go through that bounded context's Application Service or could I simply go for the aggregates?" - that deserves a Q of its own. Depends on which flavor of Context Mapping you choose between the two BC's and the topology of your system.
    – guillaume31
    Jul 26, 2018 at 8:23
4

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.

Improve this answer
2
  • You are correct in where my doubts are. What got me thinking about the whole thing was: if I were to fetch an entity from another bounded context, would I have to go through that bounded context's Application Service or could I simply go for the aggregates? P.s. I am aware of Anti-corruption layer, so either way I would remap foreign context's entities into host context's entities.
    – robotron
    Jul 26, 2018 at 7:31
  • You should to go through the bounded context's application service and it can return to you an aggregate. Is not usual to manage an aggregate through another bounded context, this is a the application service resposibility and it will expose this capability to the extern systems on a security way.
    – phduarte
    Jul 26, 2018 at 11:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.