Anemic vs. Rich Domain Models: Core Concepts of Domain‑Driven Design

Introduction

To deeply master Domain‑Driven Design (DDD), one cannot avoid two abstract concepts: the “Anemic Model” and the “Rich Model”.

Anemic Model corresponds to the Transaction Script pattern.

Rich Model corresponds to the Domain Model pattern.

What is the Anemic Model?

The Anemic Model originated from EJB 2 and reached its peak with Spring, which separated behavior (logic, processes) from state (data, i.e., object fields). Objects that contain only state are called “anemic objects” (often referred to as Value Objects). Objects that contain only behavior are the typical Logic/Service/Manager layers (stateless session beans in EJB 2).

Even Spring’s creator Rod Johnson admitted that Spring inherited the transaction‑script style of EJB 2, i.e., procedural programming.

Critics such as Martin Fowler and Eric Evans consider the anemic domain model a long‑standing anti‑pattern because it separates data from behavior, contradicting object‑oriented design.

The main drawbacks are the extra cost of object‑relational mapping without any benefit, and the loss of encapsulating business rules within the model.

Advantages of the Anemic Model

Simple and natural for applications with little business logic.

Fast development and easy to understand.

Can be useful in certain scenarios, but should not be universally adopted.

Disadvantages of the Anemic Model

It struggles to handle complex business rules, such as varying contract‑validation logic based on dates or regions.

What is the Rich (Charged) Model?

Object‑oriented design asserts that an object should own both state and behavior. For example, a person’s eyes and nose represent state, while the ability to play games or write code represents behavior.

In a traditional design you might have User and UserManager classes, with the manager handling persistence via userManager.save(User user) . In a rich model, the User class itself would contain a save() method, encapsulating its own persistence logic.

The author prefers the rich model because it aligns with OOP’s richer semantics, better organization, and maintainability, despite being harder to master.

In practice, whether to use the rich model depends on the team’s understanding and the specific domain; many Java EE developers are still influenced by the anemic approach.

References

Domain‑Driven Design (Eric Evans)

Martin Fowler’s article on Anemic Domain Model

Various online discussions (Zhihu, etc.)