Anemic domain model

This article may be confusing or unclear to readers. Please help clarify the article. There might be a discussion about this on the talk page. (March 2007) (Learn how and when to remove this template message)

Anemic domain model is the use of a software domain model where the domain objects contain little or no business logic (validations, calculations, business rules etc.).

Overview[]

This pattern was first described^[1] by Martin Fowler, who considers the practice an anti-pattern. He says:

The fundamental horror of this anti-pattern is that it's so contrary to the basic idea of object-oriented designing; which is to combine data and process them together. The anemic domain model is just a procedural style design, exactly the kind of thing that object bigots like me ... have been fighting since our early days in Smalltalk. What's worse, many people think that anemic objects are real objects, and thus completely miss the point of what object-oriented design is all about.

In an anemic domain design, business 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 Java applications, possibly encouraged by technologies such as early versions of EJB's Entity Beans,^[1] 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).^[2]

This section does not cite any sources. Please help by adding citations to reliable sources. Unsourced material may be challenged and removed. (June 2015) (Learn how and when to remove this template message)

Fowler describes the transaction script pattern thus:

Most business applications can be thought of as a series of transactions. A transaction may view some information as organized in a particular way, another will make changes to it. Each interaction between a client system and a server system contains a certain amount of logic. In some cases this can be as simple as displaying information in the database. In others it may involve many steps of validations and calculations. A Transaction Script organizes all this logic primarily as a single procedure, making calls directly to the database or through a thin database wrapper. Each transaction will have its own Transaction Script, although common subtasks can be broken into subprocedures.^[3]

In his book "Patterns of Enterprise Application Architecture", Fowler noted that the transaction script pattern is OK for many simple business applications, and obviates a complex OO-database mapping layer.

Reasons why this may occur

AnemicDomainModel may occur in systems that are influenced from Service-Oriented Architectures, where behaviour does not or tends to not travel.

• Messaging/Pipeline architectures
• APIs such as SOAP/REST

Architectures like COM+ and Remoting allow behaviour, but increasingly the web has favoured disconnected and stateless architectures.

Criticism[]

This section needs additional citations for verification. Please help by adding citations to reliable sources. Unsourced material may be challenged and removed. (September 2017) (Learn how and when to remove this template message)

There is some criticism as to whether this software design pattern should be considered an anti-pattern, since many see also benefits in it, for example:

• Clear separation between logic and data.^[4]
• Works well for simple applications.
• Results in stateless logic, which facilitates scaling out.
• Avoids the need for a complex OO-Database mapping layer.
• More compatibility with mapping and injection frameworks expecting dumb properties rather than a specific constructor or property population order. ^[4]

Liabilities[]

This section does not cite any sources. Please help by adding citations to reliable sources. Unsourced material may be challenged and removed. (November 2013) (Learn how and when to remove this template message)

• Logic cannot be implemented in a truly object-oriented way.
• Violation of the encapsulation and information hiding principles.
• Needs 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).
• Needs a service layer when sharing domain logic across differing consumers of an object model.
• Makes a model less expressive.

Example[]

Anemic

class Box
{
    public int Height { get; set; }
    public int Width { get; set; }
}

Non-anemic

class Box
{
    public int Height { get; }
    public int Width { get; }

    public Box(int height, int width)
    {
        if (height <= 0) {
            throw new ArgumentOutOfRangeException(nameof(height));
        }
        if (width <= 0) {
            throw new ArgumentOutOfRangeException(nameof(width));
        }
        Height = height;
        Width = width;
    }

    public int Area()
    {
        return Height * Width;
    }
}

See also[]

• Plain old Java object
• Domain-driven design
• 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

References[]

External links[]

• Anemic Domain Model by Martin Fowler
• Three-Layered Services Application
• Application Architecture for .NET: Designing Applications and Services
• Article on why anemic model may be considered good design
• Writing Clean Code in ASP.NET
• How to Avoid Anemic Domain Model