Anemic vs Rich Domain Model: Understanding DDD Concepts

To deeply master DDD, one must understand two abstract concepts: the anemic model and the rich (or "充血") model.

The anemic model corresponds to the transaction‑script pattern, while the rich model corresponds to the domain‑model pattern.

In the anemic approach, objects contain only state (e.g., Value Objects) and all behavior is placed in separate service or manager layers, a practice inherited from EJB2 and popularized by Spring.

Rod Johnson himself admitted that Spring continued the transaction‑script style, and experts such as Martin Fowler and Eric Evans consider the anemic model an anti‑pattern because it separates data from behavior, contradicting object‑oriented design.

Advantages of the Anemic Model

Simple and natural for applications with little business logic.

Fast development and easy to understand.

Can be appropriate in limited scenarios.

Disadvantages of the Anemic Model

Struggles with complex business rules, such as varying contract‑validation logic.

Leads to procedural code that misses the benefits of a true domain model.

Object‑oriented design’s essence is that an object should encapsulate both state and behavior. A rich domain model follows this principle, placing validation, calculations, and business rules inside the domain objects themselves.

For example, a traditional design might use a User class and a UserManager service (userManager.save(user)), whereas a rich design lets the User object save itself (user.save()).

The author argues that, despite the learning curve, the rich model offers richer semantics, better organization, and stronger maintainability, and should be preferred when possible, though it requires careful design to avoid over‑complexity.