Anemic Domain Models (ADM) can be used when the application is too simple. But they don’t scale.
Rich Domain Models (RDM) are powerful, but also undeniably of higher cost in comparison to ADMs.
Domain-Driven Design (DDD) tells you to use Rich Domain Models, right?
If anything, DDD asks you to identify the more critial subdomains of your domain (the core domains) and spend time (aka use RDM) on those.
On the less important subdomains, going the extra mile to apply RDMs frequently doesn’t pay off.
Anemic Domain Models
- Usually implemented as data-only entities (devoid of logic) + service classes which contain the business rules (see Transaction Script pattern).
- Allows you to (too) easily put the entities in an inconsistent state
- Requires you to remember every detail of every operation – and tests don’t help here: if you don’t know you have to do it (if you don’t know you have to implement a given detail), you don’t write tests for it (because you didn’t know you had to handle it in the first place).
- Higher cognitive load (you have, at any given time, to worry about more in order to make less mistakes)
Rich Domain Models
- Require more communication (people/documentation kind of communication) over the abstractions and responsibilities of the entities involved.
- Demand a somewhat higher level of technical expertise/experience from the programmers involved (you can’t just follow the simplest path, abstractions must make sense; modularity and boundaries must be well thought out).
- Scales much better than the ADM (because objects tend to be self-validating, methods that would put them in inconsistent states won’t even exist).
Still, even a RDM can help you so much. The most important lesson is to keep your models boundaries at check. With good boundaries, you can focus on a (hopefully smaller) core part of your domain and use ADM, CRUD (or whatever suits the situation) in the supporting parts/modules.