Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

It's easy to accept that objects should be used in all layers except a layer nominated as a data layer. However, it's just as easy to end-up with an 'anaemic domain model' that is just an object representation of data with no real functionality ( ).

However, using objects in this fashion brings the benefit of factors such as Intellisense support, strong typing, readability, discoverability, etc.

Are these factors strong arguments for an otherwise, anaemic domain model?

share|improve this question
I don't see how you would not get exactly the same benefits with a proper domain model. – Michael Borgwardt Aug 14 '12 at 10:49

It all depends, surely, of what are your options.

You should understand that alternative to "(anemic) domain model" is not "something without strong-typing", but "data transfer objects". Both are strong-typed (with all included benefits), but there's strong semantic difference between them.

share|improve this answer
Good point, thanks. I agree that the difference between the two is only semantic. However, it may be significant in conveying the model's purpose. – David Osborne Aug 14 '12 at 10:58
@DavidOsborne of course it is. What Fowler warns of, I think, is "Domain Model" that still thinks and calls itself domain, but is, in fact, simple DTO. There're two major options we can choose from: DTO's and logic in service, and Domain Model and logic in it. In my opinion, the worst case is mix between these two options, when no one knowns where to put logic and where to look for one. – Serg Rogovtsev Aug 14 '12 at 11:03

What I understood from the article:

The programming language does not matter. So

factors such as Intellisense support, strong typing, readability, discoverability, etc.

do not matter to the authors opinion.

One problem I see is to distinct between your domain and your use-cases.

For me the domain belongs into the domain model and the use-cases into the services. But I have not much experience with large-software-developement.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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