Anemic Domain Model
From Wikipedia, the free encyclopedia
 |
All or part of this article may be confusing or unclear. Please help clarify the article. Suggestions may be on the talk page. (March 2007) |
The Anemic Domain Model is a pejorative term used to describe the use of a domain model where the business logic is implemented outside the domain objects. 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 J2EE's Entity Beans,[1] as well as in .NET applications where such objects fall into the category of "Business Entities" (though Business Entities may also contain behavior).[2]
[edit] Benefits
- Encourages and enforces a clear separation of concerns between presentation layers, business layers, and resource access layers of an application.
- Allows for the development of a common object model which can be applied across an Enterprise while at the same time allowing for flexibility in the domain logic implementation used by differing applications.
- Enables auto-generation through modeling tools which may render a common object model in various languages used across an Enterprise.
[edit] Liabilities
- Necessitates a separate business layer to contain the logic otherwise located in a domain model.
- Necessitates a service layer when sharing domain logic across differing consumers of an object model.
