» Glossary » Anemic domain
This anti-pattern coined by Martin Fowler & Eric Evans as AnemicDomainModel reflects the situation where domain objects exist, but they only contain data. Business logic and the interaction between objects -its behavior- are commonly found in services on top of the domain objects.
There are 2 main critics to this approach:
- data and behavior separation is against the core idea of encapsulation in Object Orientation Programming.
- it causes the database access logic to use the TransactionScript pattern most of the times, which is only one of the options to map Objects and Relations.
In essence, this anti-pattern encourages structured programming at the service level, which devours domain responsibilities and prevents taking advantage of the full power of Object Orientation.
In my own experience in the real world, this approach tends to:
- scatter domain/business logic in several layers and components: commonly the services and view controllers, which makes domain understanding more complex.
- make system components more coupled, preventing or making difficult the creation of tests. In order to test the domain logic, it is necessary having both the services and the view controllers set-up, which is not necessarily easy in some contexts, so people tends not to do it.
More info:
- AnemicDomainModel @ Martin Fowler
- Understanding Spring Web Application Architecture: the classic way, a typical example of an architecture with anemic domain models.