Throughout conversations with Domain Experts, you'll come across concepts in the Ubiquitous Language that can't be neatly represented as either an Entity or a Value Object, such as:

• Users being able to sign into systems by themselves
• A shopping cart being able to become an order by itself

The preceding example are two concrete concepts, neither of which can naturally be bound to either an Entity or a Value Object. Further highlighting this oddity, we can attempt to model the behavior as follows:

class User
{
    public function signUp($aUsername, $aPassword)
    {
        // ...
    }
}

class Cart
{
    public function createOrder()
    {
        // ...
    }
}

In the case of the first implementation, we're not able to know that the given username and password relate to the invoked-upon user instance. Clearly, this operation doesn't suit this Entity; instead, it should be extracted out into a separate class, making its intention explicit.

With this in mind, we could create a Domain Service with the sole responsibility of authenticating users:

class SignUp
{
    public function execute($aUsername, $aPassword)
    {
        // ...
    }
}

Similarly, as in the case of the second example, we could create a Domain Service specialized in creating orders from a supplied cart:

class CreateOrderFromCart
{
    public function execute(Cart $aCart)
    {
        // ...
    }
}

A Domain Service can be defined as an operation that fulfills a Domain task and naturally doesn't fit into either an Entity or a Value Object. As concepts that represent operations in the Domain, Domain Services should be used by clients regardless of their run history. Domain Services don't hold any kind of state by themselves, so Domain Services are stateless operations.