Anemic Domain Model vs. DDD by definition example(s)?

Question

What is an example of "Business Logic" that should reside in the DomainModel i.e. inside an Entity instead of inside a (Domain) Service, as well as some example logic that should be in a service.

Here are what I would consider to be pretty clear cases(?):

Basic Validation would be done by the ViewModel definition attributes and jQuery validation. Therefore data correctness should be fine by the time data gets to the Service/DomainModel(Entity).

Some business logic that depends on other Entities would belong somewhere outside the Entity in a service (naturally/presumably).

Something that I could picture existing in a DomainModel (Entity) would be simple adding items to a list property (ensure no duplicates exist etc.). Perhaps some basic copy functionality.

What else do you put in the Entity/DomainModel, instead of the Service? It's hard to make a clear distinction, or at least it feels like most of the logic would end up in the Service(s).

Answer 1

There have been several discussions about all this.

Have a look at this SE question where Iulian Margarintescu said something pretty interesting:

[...] the anemic domain model is not by itself an anti-pattern, only when you try to do DDD and end up with and anemic model.

He mentioned this pretty interesting article as well.

From my own experience, when I work with generated EF POCOs (Anemic Domain Model) I tend to put my business rules into specifications. That way I’m able to write business rules for any of my domain entities and chain them while querying.

EDIT:

If you want to follow DDD strictly, please read this. Eric Evans is describing what exactly should be the role of a service and what should be put in it.

Answer 2

Domain model is usually (and I assume in your case really) normal object model. So same rules and practices apply to domain modelling as for object modelling. So I would look at SOLID, KISS, and various design patterns.