DDD - Modelling the Domain - Services

When designing a Domain Model the prominent modelling paradigm is objects and as a result we are mapping concepts i.e. nouns to DDD building blocks such as Entities and Value Objects. The behaviour associated to those concepts is mapped to methods using verbs. However, there are domain specific functions that we would like to define in the model but cannot be attached into an existing Entity or Value Object (Evans, 2003). Instead of forcing foreign operations into domain objects, Evans (2003) introduced the concept of Domain Services.

The concept of Domain Service is used here to describe an interface defined within the domain model and named in terms of the Ubiquitous Language using a verb instead of a noun (Evans, 2003). Services may be implemented in the infrastructure layer (Vernon, 2013) but method arguments and returned results should be objects of the domain model (Evans, 2003). Another important characteristic is that Services defined within the domain model should be stateless i.e. the behaviour of a service instance is not affected by its internal state which is common for other domain elements such as Entities (Evans, 2003).

The word service is so often used when designing software systems which rightly causes misunderstandings. For example, in the context of Service Oriented Architectures, the provided services are coarse-grained, typically providing a remote procedure call (RPC) interface (Vernon, 2013). On the contrary, Domain Services are not meant to be distributed and accessed directly through an RPC interface. Additionally, it is important to differentiate between a Domain Service and an Application Service. The application layer has no business logic and is the client of the domain layer (Evans, 2003). It seems unfortunate that operations in the Application layer are also called Services (Evans, 2003; Vernon, 2013). My own view is that the word service is particularly popular in Java based application frameworks which influenced the naming of operations in the application layer.

As an example of a Domain Service consider the case of calculating the routes for a trip. The driver inputs the starting point, the destination and a CalculateRouteService computes the possible routes to the target city. This may require accessing a third party service to retrieve traffic related information.

Finally, bear in mind that Domain Services should not be used to strip Entities and Value Objects from business logic (Evans, 2003; Vernon, 2013), thus creating an Anemic Domain Model (Fowler, 2003).


  • Evans, E. (2003) Domain-Driven Design: Tacking Complexity In the Heart of Software. Boston: Addison-Wesley.
  • Fowler, M. (2003) Anemic Domain Model. [Online] Available at: http://www.martinfowler.com/bliki/AnemicDomainModel.html [Accessed 26th May 2013].
  • Vernon, V. (2013) Implementing Domain-Driven Design. Boston: Addison-Wesley.

This post is an excerpt of my MSc Thesis titled "Applying Domain-Driven Design in Python - designing a self-hosted Read-it-Later service" (January 2014).

This article was updated on

Related post

DDD - Modelling the Domain - Modules

Software systems could become very complex with a large domain model which makes it overwhelming to see the whole picture. The concept of a Module is a design element in many programming languages (in Java they are called Packages and in C# Namespaces) to divide code for managing complexity and assisting in code reuse. Typically, programming language textbooks promote modules mainly as a code organization tool.

DDD - Modelling the Domain - Value Objects

There are elements of the Domain Model without any conceptual identity which are typically used to characterise Entities (Evans, 2003). Those elements are called Value Objects and their significance is often neglected (Vernon, 2013). Examples of Value Objects are: Zip Code, Order Number, Phone Number, Money, Currency, Date, Date Range, E-mail Address, URL etc. Value Objects express domain concepts and are part of the Ubiquitous Language (Evans 2003; Vernon, 2013).