ddd - is my Service a Domain one or an Application one?

Question

I have trouble identifying if a Service I am creating is a Domain one or an Application one. From the book I read "Domain Driven Design in PHP", it is said that an Application service would be like a "User SignUp Request", accessing a Repository and verifying if a user exists or not. However they take the same example to implement it as a Domain Service, so I cannot differentiate both.

My situation is the following: I am creating a dynamic page builder. A Page as many Blocks, that are all a subclass of a Base Block. Each subclass of Base Block has its own business rules to allow the user to customize its design (basically it should return a form, different for each Block).

I am starting with the use case "A user wants to add a [Specific Block] to a Page".

I wonder if this is a Domain Service, or an Application Service. Any help is greatly appreciated

What do you mean exactly by *"take the same example to implement it as a Domain Service"* ? I'm not sure how a self-respecting DDD book could fail to explain such a fundamental difference. Are you sure you read correctly ? A good article about services in DDD : http://gorodinski.com/blog/2012/04/14/services-in-domain-driven-design-ddd/ — guillaume31, Jul 27 '16 at 08:37
The book takes the exact same example: "A user wants to sign up" and implements it first as an Application Service, then as a Domain Service. However it seems like I was misunderstanding it. Your article was a great help, thanks ! — Lucio, Jul 27 '16 at 11:51
Maybe the application service was calling the domain service in the book ? — guillaume31, Jul 27 '16 at 12:02
Actually no, it was doing the exact same thing, but in a different manner. The Application one was using a DTO, while the Domain one was using the raw data, and checking some other things aswell (password validity) — Lucio, Jul 27 '16 at 12:21

score 3 · Answer 1 · edited May 23 '17 at 11:58

Your application services would typically be responsible for orchestrating a use case, and do something like loading / saving an aggregate from persistence.

i.e. something like:

public void SomeUseCase()
{
     var aggregate = _repository.Load(someId);
     aggregate.ApplySomeBehaviour(someDomainService);
     _repository.Save(aggregate);
}

whereas a Domain Service would be more domain behaviour specific, for example a RateCalculator - some object that doesn't fit into the Aggregate concept but contains behaviour you need to capture in your domain.

Possible duplicate of Domain Driven Design: Domain Service, Application Service

That makes it even clearer, thank you ! – Lucio Jul 27 '16 at 12:28 — Lucio, Jul 27 '16 at 12:28

ddd - is my Service a Domain one or an Application one?

1 Answers1