Anemic Domain Model

From CSSEMediaWiki
Revision as of 03:56, 18 July 2009 by JaninaVoigt (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Anemic Domain Model is an anti pattern that was first suggested by Martin Fowler. It occurs when a domain model in software does not include business logic which acts on the data. This business logic is usually separated into separate classes. This essentially means that related data and behavior have been separated and fits more with a procedural programming approach than with an object oriented approach.

While clearly conflicting with several commonly known design maxims, this practice is relatively common in enterprise applications where the data is often separated into business entities.

Liabilities and Violations

  • Tight coupling between the data classes and the business logic classes.
  • Breach of encapsulation and information hiding since the data in the data classes needs to be exposed to the business logic classes, thus further exposing the data to other parts of the system.
  • Data objects cannot guarantee the correctness of their data because the validation and mutation logic is placed elsewhere.
  • Makes a model less expressive and harder to understand.
  • Can lead to code duplication where multiple use cases (implemented in different business logic classes) have similar code.

Related design maxims

Personal tools