views:

106

answers:

1

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.

+3  A: 

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