Anemic domain model

Anemic domain model is the use of a software domain model where the business logic is implemented outside the domain objects. The core business objects have been split into objects containing only data and objects containing only code.

Overview

This pattern was first described by Martin Fowler, who considers the practice an anti-pattern. With this pattern, logic is typically implemented in separate classes which transform the state of the domain objects. Fowler calls such external classes transaction scripts. This pattern is a common approach in enterprise Java applications, possibly encouraged by technologies such as early versions of EJB's Entity Beans, as well as in .NET applications following the Three-Layered Services Application architecture where such objects fall into the category of "Business Entities" (although Business Entities can also contain behavior).

Benefit

• Clear separation between logic and data (Procedural programming).
• Supports the Single responsibility principle by dividing the business data (changes very seldom) from business logic (changes often). A rich domain model needs to be changed if any of them changes. The anemic domain model may separate the changes and keep the interface between the data and the domain model containing the logic stable.
• Results in stateless logic which is inherently simpler and more scalable.

Liabilities

• Logic cannot be implemented in a truly object-oriented way unless wrappers are used, which hide the anemic data structure.
• Violation of the encapsulation and information hiding principles.
• Necessitates a separate business layer to contain the logic otherwise located in a domain model. It also means that domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
• Facilitates code duplication among transactional scripts and similar use cases, reduces code reuse.
• Necessitates a service layer when sharing domain logic across differing consumers of an object model.
• Makes a model less expressive and harder to understand.

See also

• Domain-driven design
• Plain Old Java Object
• GRASP information expert, an anemic domain model is the typical result of not applying the information expert principle, i.e. you can avoid an anemic domain model by trying to assign responsibilities to the same classes that contain the data

External links

• Anemic Domain Model by Martin Fowler
• Three-Layered Services Application
• Application Architecture for .NET: Designing Applications and Services