Blogged Services

It was therefore unfortunate that Eric Evans introduced yet another concept of Service in DDD, one which has since been referred to by some as a Domain Service. However, people often use the term Service in isolation, as Eric did in his book – so if it is in relation to the Domain, it is probably what I prefer to call a Domain Service – otherwise it is likely to be one of those “other” services.

So … Domain Services Are … What?

Well, if Entities and Value Objects are the “things” in our Domain, the Services are a way of dealing with actions, operations and activities.

Shouldn’t Logic Be on the Entities Directly?

Yes, it really should. We should be modelling our Entities with the logic that relates to them and their children. But sometimes that logic either doesn’t fit on the Entity, or it would make the Entity bloated and unwieldy.

That is when Services come into the picture. They help us split logic that deals with multiple Entities, or that deals with complex operations or external responsibilities, into a separate structure more suited to the task.

So What Are the Characteristics of a Good Domain Service?

Oddly, they are much the same as the properties of any other good services… but to reiterate Eric Evans directly, they are:

• The operation should be something that relates to a concept that does not naturally fit on an Entity or Value Object
• The interface is defined in terms of the elements of the Domain Model
• The operation is stateless

The first two of those are pretty obvious and easy to apply, the last is in general a good definition of a Service, and although some would argue there is no such thing as stateless, don’t express state explicitly, and presume instance of your Services should not affect each other.

Some Examples of Services

So far we have been using an ecommerce system as a basis for the examples, so I’ll continue here.

When a customer adds items to their shopping basket, they will expect to see the items totalled, and things like shipping costs calculated.

These things might conceivably sit on the Shopping Basket Entity – but a bit of deeper thought shows that this is probably not a perfect fit. For a simple system the basket might be able to contain all the logic required, but expanding our system and moving it to a DDD focus would probably extrapolate Services to deal with these issues – PricingService and ShippingCostingService could well be two of the players in this game.

After all, apart from needing to deal with the items in the Shopping Basket, these operations may well require communication with other services, calculation and pricing engines, external suppliers … in other words, they have a lot of responsibilities that we do not want to bring into our Entity.

Now instead of our ShoppingBasket having .GetTotalPrice and .GetShippingCost methods, we can use a Domain Service to get this information, and keep our Entity focused on the real tasks, managing the items in the ShoppingBasket

Services in the Ubiquitous Language

Entities and Value Objects live comfortably in the Ubiquitous Language, they are the “things” that our Domain Experts and Users talk about.

Services also live in the Ubiquitous Language, they are the actions that our  Domain Experts and Users talk about… where you see a noun in the conversation, it is likely to be an Entity or Value Object. When you see a verb, it may well be a Domain Service

In Conclusion

Domain Services provide a way of expressing actions and operations within our Domain. Where as Entities and Value Objects, the “things”, provide the building blocks, Domain Services provide the plumbing between them and allow us to express more abstract concepts.

Just beware of creating an anaemic domain model, Services are there to support Entities and VOs, not to strip their logic from them.