1

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

  • 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? – Songo May 28 '13 at 11:47
  • Good point. Another thing to consider. – lko May 29 '13 at 13:10
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 | |
  • 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). – lko May 29 '13 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. – MaxSC May 29 '13 at 12:20
  • Thank you, that looks to be precisely what I am looking for. Can you add it to your answer? – lko May 29 '13 at 13:03
  • I just edited my answer! ;-) – MaxSC May 29 '13 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) – lko May 29 '13 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 | |
  • 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). – lko May 29 '13 at 11:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.