Anemic domain model

From Wikipedia, the free encyclopedia
  (Redirected from Anemic Domain Model)
Jump to: navigation, search

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[edit]

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]

Benefits[edit]

  • Clear separation between logic and data (Procedural programming).
  • Results in stateless logic which is inherently simpler.

Liabilities[edit]

  • 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 and harder to understand.

See also[edit]

References[edit]

External links[edit]