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).
2
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.
5
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.
1