Alex Rivera | Logout

How much logic should be in your domain model objects

Asked 2009-01-23T16:47:17.243
16

Just finished read this post by Greg Young, where he is talking about Microsoft recommending patterns with dumb data transfer objects. He implied that in the Java community, things are trending the other direction.

My question is how much logic should be in your entity objects? Our philosophy where I work (C# shop) is that if you can't serialize it, don't put it in the entity.

design-patterns n-tier-architecture
Edit
Report

1 Answer

2

The main point is how one defines logic. To give some examples:

  1. I wouldn't categorize a function getFullName() in a Person entity, which just concatenates some strings, as logic.
  2. Calculating an order item value would more likely qualify for being logic.
  3. Doing some booking transactions I would definitely say is logic.

Point 1 and maybe 2 would go for me into the entity. Point 3 not. So I define logic as:

  • any operation that does any persistence related thing (read/write)
  • any operation that involves any other (not directly related, e.g. master-detail) entity

IMO, any of these operations don't belong into entities.

Now, why/when I wouldn't put also point 1 and 2 type operations into an entity? It's a rather rare situation, but I wouldn't do it, as soon as the data stored in the entity needs to be interpreted in some way before it can be used by the application (e.g. if depending on current user, content of field X has a different meaning), that means the entity's data itself yields some logic.

answered 2009-01-23T18:29:42.717

Your Answer