4

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

Improve this question
2
  • 3
    "Basic Validation would be done by the ViewModel definition attributes and jQuery validation." what if your data is coming from a file instead? what if you decide to expose your application as a service? Commented May 28, 2013 at 11:47
  • Good point. Another thing to consider. Commented May 29, 2013 at 13:10

2 Answers 2

Reset to default
3

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.

Improve this answer
5
  • 1
    They are discussing the merits of the Anemic Domain Model (I've read the question earlier), but I'm trying to specifically find what logic would be inside a DomainModel (Entity) vs. Service if you actually follow DDD (strictly). Commented May 29, 2013 at 11:38
  • "find what logic would be inside a DomainModel (Entity) vs. Service if you actually follow DDD". Well, if you 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. Commented May 29, 2013 at 12:20
  • Thank you, that looks to be precisely what I am looking for. Can you add it to your answer? Commented May 29, 2013 at 13:03
  • I just edited my answer! ;-) Commented May 29, 2013 at 13:08
  • Btw, that google link to the exact page is great, but you could change the url to google.com vs. .fr so it's in English. (For future readers) Commented May 29, 2013 at 13:14
1

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.

Improve this answer
1
  • Valid points about the general coding style and principles (which are being followed too). However I'm looking for some clear distinction about logic that "could" be in either of the two mentioned places (inside a Service or an Entity). Commented May 29, 2013 at 11:31

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.