22

Our team is fairly new to DDD, and are trying to implement some of the concepts in our current project. One question that has come up is whether to put methods into entity objects, or service objects.

Some team members feel that entities should only hold values and all functionality should be contained in services. Others feel this makes the entity objects anemic, and that they should hold functionality that relates to the entity, while service objects should be utilized for more cross-cutting functionality.

We're wondering what the formal DDD point of view is on this, as well as what has worked for people in real life.

alchemical
  • 13,559
  • 23
  • 83
  • 110

2 Answers2

14

There is no formal point of view for DDD, but the whole purpose of a rich Domaim Model is to avoid an Anemic Domain Model, so explicitly refusing to put any behavior on the Domain Objects goes against the spirit of it.

One school of thought holds that Domain Objects should be POCOs/POJOs, which means that they shouldn't contain abstract services as members. However, that doesn't mean that they can't have methods that interact with such services.

The more (relevant) behavior you can give each Domain Object, the better.

Mark Seemann
  • 225,310
  • 48
  • 427
  • 736
  • I have read [here](https://vuscode.wordpress.com/2009/10/16/inversion-of-control-single-responsibility-principle-and-nikola-s-laws-of-dependency-injection/) that entities (domain objects) should not have dependency on services (I believe that's what you are saying here as well). But then how can an entity have a method that interact with a service? If an entity has a reference to a service isn't it a dependency? – Hooman Bahreini Oct 25 '18 at 05:01
  • 6
    @Hooman One could pass services as method arguments, but in general, I wouldn't recommend that style. The DDD community, including Evans himself, if I understand him correctly, has increasingly come to the realisation that DDD and OOD doesn't mix well. FP is a much better fit. See e.g. [a talk I gave some years ago](https://vimeo.com/180287057) for a high-level overview. – Mark Seemann Oct 25 '18 at 06:05
  • 3
    The Vimeo link is dead. Here's the talk Mark is referring to on YouTube: https://www.youtube.com/watch?v=US8QG9I1XW0 – Eric Eskildsen Nov 02 '20 at 14:13
8

According to Domain Driven Design Quickly, there are three basic types of objects.

  • Entities
  • Value Objects
  • Services

Business logic of an application is implemented within all three of these objects, but we are cautioned to partition the logic judiciously.

A Service can group related functionality which serves the Entities and the Value Objects. It is much better to declare the Service explicitly, because it creates a clear distinction in the domain: it encapsulates a concept. It creates confusion to incorporate such functionality in an Entity or Value Object because it won’t be clear what those objects stand for.

On the other hand,

A Service should not replace the operation which normally belongs on domain objects. We should not create a Service for every operation needed. But when such an operation stands out as an important concept in the domain, a Service should be created for it. There are three characteristics of a Service:

  1. The operation performed by the Service refers to a domain concept which does not naturally belong to an Entity or Value Object.
  2. The operation performed refers to other objects in the domain.
  3. The operation is stateless.

So there are some clear criteria for determining where a method belongs. Unfortunately, DDD is not as simple as saying business logic belongs in entities or business logic belongs in services. Neither statement is true. The answer is a combination of both.

Finally, don't add methods to domain objects just to avoid an anemic domain model.

When we create a software application, a large part of the application is not directly related to the domain, but it is part of the infrastructure or serves the software itself. It is possible and ok for the domain part of an application to be quite small compared to the rest, since a typical application contains a lot of code related to database access, file or network access, user interfaces, etc.

jaco0646
  • 15,303
  • 7
  • 59
  • 83