This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Anemic domains Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general. Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Cincom Smalltalk Blog - Smalltalk with Rants

The basic symptom of an Anemic Domain Model is that at first blush it looks like the real thing. There are objects, many named after the nouns in the domain space, and these objects are connected with the rich relationships and structure that true domain models have. The catch comes when you look at the behavior, and you realize that there is very little behavior on these objects. Indeed often these models come with design rules that say that you are not to put any domain logic in the the domain objects. Instead there are a set of service objects which capture all the domain logic. These services live on top of the domain model and use the domain model for data.

Here's the 2 cent answer - most C programmers went from C to C without ever learning objects. Thus, most C objects were glorified structs. Later, most of the Java developers came from the ranks of these warmed over C developers - and again, they didn't pause to learn OO. What you have now is a bunch of Java (and C#) developers who think that anemic objects are objects. There's not a lot you can do about this; these folks don't know what they don't know...