Anemic domain model

[Vojtech Szocs]

Hi everyone,

recently we had a spoken discussion about so called "anemic" domain
models so I decided to start a topic here as well.

Some useful links to introduce this (anti)pattern:
http://martinfowler.com/bliki/AnemicDomainModel.html
http://en.wikipedia.org/wiki/Anemic_Domain_Model

Anemic domain models are simply domain models with business logic
implemented outside domain objects (entities). The business logic is
moved to a separate service layer above domain model with
responsibilities such as:
- reflection of business rules onto the state of entities (entity
state transformations)
- entity validation logic (business validation rules)

As a result:
- entities have rich relationships but no behavior
- entities do not manage their state on their own
- entities cannot give any guarantee of their correctness or validity
- related code (data and logic) is scattered accross layers

Simply put, from OO point of view, business logic associated with
entities should be placed in entities to ensure things such as high
cohesion, low coupling and the overall code maintainability. The
"Information expert" OO pattern describes these things in a more
general way:
http://en.wikipedia.org/wiki/GRASP_%28Object_Oriented_Design%29#Information_Expert

Standard persistence operations (CRUD, entity lookup, etc.) and
business logic are two completely orthogonal concepts. There can be a
generic DAO layer which operates with rich domain model (rich in terms
of business logic, not persistence logic) and the service acts as the
controller between these two; there's no business logic in the service
itself. This is something GRASP refers to as the "Indirection"
pattern:
http://en.wikipedia.org/wiki/GRASP_%28Object_Oriented_Design%29#Indirection

Essentially, such service tells entities to do business things.
Service doesn't do business things on its own. "Tell, don't ask" is
also a good example of how to achieve high cohesion and loose coupling
between your objects:
http://www.pragprog.com/articles/tell-dont-ask

So, what's the recipe for converting typical anemic domain model
project into rich domain model project? I think it's like this:
- put business logic away from the service layer into corresponding
entities
- refactor services so that they delegate business operations to
entities
- entities can be passed to the DAO layer as usual

A variation of rich domain model is "ultra rich domain model" which
mixes entities (and associated business logic) with DAO persistence
operations. For example:

Course c = new Course("spanish", 100); // business validation enforced
by constructor
c.enrollStudent("chuck norris"); // business operation

c.saveOrUpdate(); // DAO operation implemented by entity itself
OR
courseDao.saveOrUpdate(c) // the classic way (DAO handles entity
persistence)

and what about this:

Customer c = Customer.get(id);


I've never encountered a truly rich domain model. Nearly all domain
models I've seen are completely anemic. Does this mean these domain
models are implemented incorrectly? What's your opinion on ultra rich
domain models?