Domain Driven Design: where does the workflow logic lie?

Question

In my project,i have workflow which operates on multiple entities to accomplish a business transaction. What is the best place to represent the workflow logic? currently i just create a "XXXManager" which is responsible for collaborating with entity objects to conclude a business transaction. Are there other options?

Answer 1

I'd say you're doing the right thing having something collaborate with multiple entities to get something done. The important thing is that each entity (and indeed each service) should have a single responsibility.

The overarching workflow you're talking about is something that you can consider as a part of your Application Layer.

According to Paul Gielens (paraphrased) The Application Layer’s responsibility is to digest the course-grained requests (messages/commands) to acheive a certain overarching goal. It does this by sending a message to Domain Services for fulfillment. It then also (optionally) decides to send notifications to the Infrastructure Service.

But then what is a 'Service'?! It's an overloaded term but one that's described well (again, by Paul Gielens)

You might also want to read about Onion Architecture for more ideas...