Rich Domain Model and ORM
Martin Fowler considers Anemic Domain Model as an anti-pattern.
Rolling the Persistence Model as the Domain Model seems severely off too due to Object Relational Impedence Missmatch. For persistence and normalization sakes, we tend to break down classes to very small tiny pieces, slapping methods on top of these classes is silly. Plus persistence rarely changes, but business logic changes a fair bit.
So we need a DomainModel that builds on the persistence model (instead of being one and the same). This Domain Model will then contains business logic properties and method.
But now these Domain Models are still behind the service, and in order to expose them out to the outside world we need to convert them over to DTOs.
We are doing so manny mappings here.
- Persistence to Domain Model
- To convert Domain Model into DTOs to pass along between services
It doesn't end there, since the DTO may need to be mapped into the ViewModel.
All that and the problem of duplicating validation logic still doesn't go away, because the client wants real time validation. ViewModel knows nothing about validation, so in an SPA for example, you're forced to rewrite the validation logic again, on the client side (usually in javascript).
Also services are by nature stateless (message or RPC oriented), so we're doing all these mapping, between Persistence, to OO then back to Procedural, to what benefit? How would you justify the cost in practical terms of most IT budget?
I get how having full DDD, with Aggregate Roots, Domain Models etc. would be "cool" but how can you justify the cost and the hit on dev productivity?
anti-pattern (or antipattern) is a pattern used in social or business operations or software engineering that may be commonly used but is ineffective and/or counterproductive in practice
And if so, wouldn't DDD and Rich Domain Model fit into the anti-pattern definition above than the "Lean" Domain Model. Sorry, I despise the loaded word, "Anemic".
By keeping the Domain Model, "Lean" you actually allow it to be shared without violating the "Abstract Dependency Principle", "Don't Repeat Yourself" and the time consuming, tedious and error prone process of mapping one data carrier to another, and whatever associated Unit Test that goes on top of that (unless you're thinking of doing mapping w/o unit testing and hope for the best).
Answer
It seems you're mixing up a lot of concepts, blaming the rich domain model approach for things it isn't directly responsible for.
Rich domain model is orthogonal to layered architecture, especially having a rich domain model doesn't dictate the number of layers you have, what data structures should be exchanged between these layers and how they should be mapped.
Rich domain model is orthogonal to validation and says nothing about the need for client-side checking in addition to back-end validation.
In other words, making your domain model anemic with all business logic in services won't necessarily save you from writing a lot of boilerplate DTO mapping code, nor will it remove the need for client-side "double checking" (which is by the way a commonly accepted best practice).
This doesn't mean your point about the cost and weight of a full-fledged multi-layered architecture isn't valid. You might find interest in this post by Mark Seemann discussing similar concerns : http://blog.ploeh.dk/2012/02/09/IsLayeringWorthTheMapping.aspx