Domain Driven Design question about Services

Question

I'm reading Domain Driven Design Quickly and I'm having trouble understanding something.

When the author speaks of Entities, Value Objects and Services, is he speaking of the Domain Model (I mean, the concepts), or already about the implementation?

What is a Service? A Controller? A static class?

On p38 one can read:

When a significant process or transformation in the domain is not a natural responsability of an Entity or Value Object, add an operation to the model as a standalone interface declared as a Service. Define the interface in terms of the language of the model and make sure the operation name is part of the Ubiquitous Language. Make the Service stateless.

From this text, I can conclude:

a) If the Service is stateless, it can't be a Controller. Is it a static class / Singleton?

b) What does he mean with an Interface? I know what an interface is when coding, but if he is talking about interfaces he must be talking already about class diagrams and such and not so much about the Domain Model?

I'm getting confused, could anyone clear this out?

Thanks

Answer 1

DDD's core focus is around understanding and clarity - implementation details come afterwards.

A Domain Service is basically a class that contains business logic.. It doesn't have to be a static or a Singleton (here's a chance to read up on Dependency Injection and Service Locators). The term stateless is also overloaded: in this context, it means that the Service shouldn't act like an Entity.

The Interface describes the methods of the Domain Service. Specifically, 'give the methods meaningful names - names that make sense to a business person'.

Unfortunately, the term Service is also overloaded. See my answer here for a description.