Why the Anemic Domain Model Is a Hidden Anti‑Pattern and How Rich Models Save You

Anemic Model

The anemic model, also known as the transaction‑script pattern, originated with EJB2 and was popularized by Spring, which inherited the procedural‑style approach.

Behavior (logic, process)

State (data, object fields)

These concerns are split into different objects: objects that contain only state are called “anemic objects” (often referred to as Value Objects), while objects that contain only behavior correspond to the Logic/Service/Manager layer (stateless session beans).

The anemic domain model is a long‑standing anti‑pattern. Even Martin Fowler and Eric Evans have noted its growing popularity, which they consider undesirable.

Its main characteristics are many domain‑named objects linked together, but their methods are essentially just getters/setters; all business logic resides in a set of Service objects that use these data‑only models.

This contradicts object‑oriented design, which binds data and behavior, leading developers to misunderstand the essence of OOP.

The model introduces the full cost of an object‑relational mapping layer without any benefit; only when rich behavior is placed in the domain can this cost be justified.

Placing behavior in the domain does not conflict with layered architecture. The domain layer should contain validation, calculation, and business rules, while the application (service) layer merely coordinates and dispatches tasks.

According to Evans, the application layer has no business state, only task state, and dispatches work to the domain layer.

The domain layer is the core software, holding business logic and state.

Over‑reliance on the service layer causes loss of the advantages offered by a rich domain model.

Advantages

Simple and natural for applications with little business logic

Fast development and easy to understand

Not to be completely dismissed

Disadvantages

Struggles with complex logic, e.g., changing revenue‑recognition rules

Different rules for contracts in different regions

Rich (Active) Model

Object‑oriented design means an object has both state and behavior; for example, a person’s eyes and nose are state, while playing games or writing code are behavior.

Instead of a separate UserManager handling persistence, a rich model puts a save() method on the User entity itself, allowing the object to manage its own persistence.

Rich models provide richer semantics, better organization, and stronger maintainability, though they are harder to master. Designing rich models requires extracting appropriate behavior from complex business logic into domain objects.

When an object contains other objects, delegate responsibilities to those objects, applying patterns like Strategy instead of large if‑else blocks.