Anemic Domain Model
From CSSEMediaWiki
(Difference between revisions)
JaninaVoigt (Talk | contribs) (Added page about anemic domain model anti pattern) |
JaninaVoigt (Talk | contribs) m (→Related design maxims) |
||
| Line 11: | Line 11: | ||
==Related design maxims== | ==Related design maxims== | ||
| − | *[[Keep related data and behavior | + | *[[Keep related data and behavior in one place]] |
*[[Behavioral completeness]] | *[[Behavioral completeness]] | ||
*[[Coupling and cohesion]] | *[[Coupling and cohesion]] | ||
*[[Don't repeat yourself]] | *[[Don't repeat yourself]] | ||
*[[Information hiding]] | *[[Information hiding]] | ||
Revision as of 03:57, 18 July 2009
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.
