What is an example of \"Business Logic\" that should reside in the DomainModel i

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

Explanation / Answer

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

Related Questions

Navigate

• Browse (All)
• Browse W
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.