Anemic Domain Model
JaninaVoigt (Talk | contribs) (Added example) |
|||
| Line 21: | Line 21: | ||
*[[Don't repeat yourself]] | *[[Don't repeat yourself]] | ||
*[[Information hiding]] | *[[Information hiding]] | ||
| + | |||
| + | [[Category: Anti-Patterns]] | ||
Revision as of 02:17, 22 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.
Example
Imagine we are creating a banking system. We want to store information about customers' accounts and also provide operations to transfer money between accounts, close accounts and check balances.
We create a data class that holds all the information about accounts that we want to store. Rather than adding the behavior that we want accounts to have straight to the Account class, we separate it into a different class called AccountManager. This class does not contain any of the data about the account but has all the relevant account behavior.
Liabilitiess
- 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.
