how to avoid anemic domain model?

Question

I'm trying to learn Domain Driven Design by example and I need your advice. Let's say I have an entity called Tender. I receive a Soap Message from outer service; the message has all the information about tender(tenderId, tenderSum, ...)

What I have to do:

1. Receive a message with Soap Web Service and put the message to the message queue - done by Service
2. Retreive the message from the queue - done by Service
3. Go to the Database , retrieve a Tender object by tenderId or create a new Tender - done by Repository
4. Fill the fields of the Tender object with the values from the Message - done by Domain Object Tender
5. Save the tender to the Database - done by Repository

I tried to do it the correct way, but finally I find, that most of the code lives in Services, Repositories, etc. I'm really confused. What did I do wrong? Should I do all this stuff inside domain object ?

Answer 1

It's not uncommon for some entities/value objects in DDD to have very little behavior. I'm almost certain that in any project you will have at least a few entities/VOs that only have some construction logic and will be immutable. These are not the main concern of DDD.

You should be focusing instead on identifying and (re-)defining your Bounded Contexts and Aggregates. You will find a lot of information on the web about this ( dddcommunity is a good place to start but i strongly recommend watching at least a few times all the videos you can find from Eric Evans, Udi Dahan and Greg Young).

And don't worry to much - no matter how good you are it takes a few failures to get it right :)

Answer 2

I have found that often what begins as everything living in the services will change over time as the model evolves. In your example, one option might be to have a method member of your entity named Tender.LoadValuesFrom[ServiceName](val1, val1, etc) (provided service name has meaning in the domain).

This way at least you are making the entity responsible for loading its own values. Sometimes the odd services will appear anaemic. If its happening everywhere or it feels really awkward then it is probably trying to tell you something. Otherwise I wouldn't stress about it too much.

Answer 3

Guess you're not alone with this kind of thoughts. What usually ends up in my model is validation, aggregate management, and I also try to focus a lot on Value Objects. Try to minimize auto properties, the invite you to rapid development without thinking... I wrote an article on my blog about this some time ago... http://magnusbackeus.wordpress.com/2011/05/31/preventing-anemic-domain-model-where-is-my-model-behaviour/

But it's a iterative work, finding the right model. Be prepare to do A LOT of refactoring...