• Object-Oriented Design

A Domain Model without behavior

In a Domain Model the model classes are supposed to have behavior. All the domain logic (validations, calculations, business rules) should be implemented there. In an anemic domain model model classes are mere data containers and all the domain logic is implemented in the service layer. The service layer should normally just coordinate but when the domain model is anemic, it effectively does everything and the domain model is devoid of any behavior. In that sense it's a procedural design in an object-oriented language.

Some frameworks like the old J2EE entity beans encourage having anemic model classes which just have getters and setters. Furthermore consistency and old habits often lead to anemic models.

Anemic Domain Model

• Tell don't Ask/Information Expert (Tda/IE): Not following TdA leads to anemic domain models.
• More Is More Complex (MIMC): Anemic Domain models push logic to the service layer making it big and untidy.

• Uniformity Principle (UP), Principle of Least Surprise (PLS): If the rest of the code does not have real domain models, it's clearer and less surprising to have the model anemic everywhere.

• Move Method

Incomplete

Discuss this wiki article and the anti-pattern on the corresponding talk page.