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).