anemic-domain-model

I apologize if this is a duplicate, but I couldn't find any concrete examples on the topic in related questions. After reading Martin Fowler's article on the 'Anemic Domain Model' , I'm left wandering as to why is this considered an anti-pattern. Even does the majority of enterprise developers consider it an anti-pattern, since AFAIK probably 90% of the j2ee applications are designed in an 'anemic' way ? Can someone recommend further reading on the topic (other than the 'Domain Driven Design' book), or even better, give a concrete examples on how this anti-pattern is affecting application

Our current O/RM tool does not really allow for rich domain models, so we are forced to utilize anemic (DTO) entities everywhere. This has worked fine, but I continue to struggle with where to put basic object-based business logic and calculated fields. Current layers: Presentation Service Repository Data/Entity Our repository layer has most of the basic fetch/validate/save logic, although the service layer does a lot of the more complex validation & saving (since save operations also do logging, checking of permissions, etc). The problem is where to put code like this: Decimal CalculateTotal

I am deciding if I should use a Rich Domain Model over an Anemic Domain Model, and looking for good examples of the two. I have been building web applications using an Anemic Domain Model, backed by a Service --> Repository --> Storage layer system, using FluentValidation for BL validation, and putting all of my BL in the Service layer. I have read Eric Evan's DDD book, and he (along with Fowler and others) seem to think Anemic Domain Models are an anti-pattern. So I was just really wanting to get some insight into this problem. Also I am really looking for some good (basic) examples of a Rich