how to avoid anemic domain model?

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 ?

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 :)