Are domain services part of domain model?

Question

Are services part of domain model according to DDD? If we google for "ddd onion architecture", we can mostly see that the most inner layer is called something like "Domain Model Layer" and the second is "Domain Services", for example, [dead link, NSFW anymore] . But in https://en.wikipedia.org/wiki/Domain-driven_design and DDD book we see that that entities, value objects and services all express the model and are model elements. If entities, value objects and services are all part of domain model, how should we call those two layers of onion: model (entities + value objects) and services (as I sometimes do)? But if all are part of domain model, this naming does not seem accurate.

Answer 1

Are domain services part of domain model?

Yes, but also no.

In the blue book, domain services are described in chapter five; immediately after entities and value types. Evans writes

In some cases, the clearest and most pragmatic design includes operations that do not conceptually belong to any object. Rather than force the issue, we can follow the natural contours of the problem space and include SERVICES explicitly in the model....

A service is an operation offered as an interface that stands alone in the model, without encapsulating any state....

The interface is defined in terms of other elements of the domain model.

But it will not always be the case that the implementation of the domain service lives within the domain model itself.

In some cases, the domain service is really acting as a service provider, which needs to be wired to the infrastructure to perform its role (for example, sending messages to another process). So the domain model defines the provider interface, an implementation of that interface is passed to it (for example, as an argument to a method on an aggregate root), and then the model decides if/when to invoke the methods on that interface.

can entities and value objects have a compile time dependency on interfaces of domain services? Are they (entities, value objects and interfaces of the domain service) in the same layer of the domain model?

Yes, and yes. For example, here's an online sample of the shipping application from chapter 7.

public interface RoutingService {
    List<Itinerary> fetchRoutesForSpecification(RouteSpecification routeSpecification);
}

Now, this particular demonstration happens to keep the domain services in a different namespace than the model, and uses an application service to bridge the two.

return routingService.fetchRoutesForSpecification(cargo.routeSpecification());

But it would be equally correct to make this part of the responsibility of the model

return cargo.fetchRoutes(routingService);

Queries give you a bit of room to play, because you don't have to worry about allowing the model to protect its own invariant. With commands, the latter approach provides better encapsulation

order.updateSalesTax(taxCalculatorService);

Answer 2

Are services part of domain model according to DDD?

It is part of the domain layer. Domain services encapsulates domain logic that cannot be naturally modeled as value objects or entities.

In the onion architecture, all dependencies face inward. Value object and entities should not have any dependencies on domain services. Domain services depends on entities and value object. At the heart of the architecture is the domain layer (value+entities+services). This is DDD which is an abstract view of the business/problem domain. This layer does not depend on anything like database, web services calls, smtp and other infrastructure related services.

One layer above is the application layer which depends on the domain layer. Application layer consists of application services that contain application logic to orchestrate business use cases.

Next layer is the infrastructural layer which can responsible for technical implementation of storing information, logging,security, notification and integration with other bounded contexts. This layer also enables the application layer to be consumed via web services or message endpoints.

To avoid tight coupling between these layers, the higher layer must adapt to the message types of the lower layer. Between these layers, you may use data transfer objects(DTO) so you don't pass domain objects(entities) across boundaries. Also to avoid tight coupling to specific technology(eg. database), layers communicate via interfaces.