Anemic Domain Model
JaninaVoigt (Talk | contribs) m (→Liabilities and Violations) |
m (Reverted edits by Ebybymic (Talk); changed back to last version by Bertrand Roussel) |
||
| (4 intermediate revisions by 3 users not shown) | |||
| Line 2: | Line 2: | ||
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. | 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== | ==Liabilitiess== | ||
| Line 16: | Line 21: | ||
*[[Don't repeat yourself]] | *[[Don't repeat yourself]] | ||
*[[Information hiding]] | *[[Information hiding]] | ||
| + | |||
| + | {{Design Anti-patterns}} | ||
| + | [[Category: Anti-Patterns]] | ||
Latest revision as of 03:22, 25 November 2010
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.
Related design maxims
- Keep related data and behavior in one place
- Behavioral completeness
- Coupling and cohesion
- Don't repeat yourself
- Information hiding
| Design anti-patterns | |
|---|---|
|
Anemic Domain Model | BaseBean | Call super | Circle-ellipse problem | Circular dependency | |
