Anemic Model is a Domain Model where Domain Objects contain little or no business logic.
This model was first described by Martin Fowler, who considers the practice an antipattern.
The fundamental horror of this anti-pattern is that it’s so contrary to the basic idea of object-oriented design; which is to combine data and process together.
Martin Fowler, Anemic Domain Model, 2003
Anemic Domain Models appear everywhere in our industry every day.
The problem is that most developers seem to think this is completely normal and do not recognize that there is a serious side effect when employed on their systems. It’s a real problem.
Vaughn Vernon, IDDD, 2013
In Anemic Model the Client is responsible for interpreting the purpose and use of the Domain object. Usually business logic ends up being implemented in other classes, called Services, that transform the state of the Domain Objects. Of course this approach leads to many design issues and drawbacks.
Ways to avoid an anemic domain model
- Use private setters. If your properties are defined by the Client directly you will lose the chance to use Domain Events and you will have to validate your Entities by external methods.
- Always validate the status of your entities, your Entities must self validate.
- Avoid constructors without parameters. Certainly your objects will need some initialization data to maintain a valid state.
- Think long before you create a Domain Services, they are used as real Silver Bullets by the developers, but end up being the biggest causes of the Anemic Model.
- Be careful with ORM, they are responsible for creating Domain Objects automatically, producing real containers of public setters and public getters, which leads to an Anemic Model.
- Do not use Transaction Script [P of EAA page 110].
- Use OOP, of course procedural programming is easier than object-oriented programming, keep in mind that the correct use of OOP is a great remedy against the Anemic Model.
Why are Anemic Model created?
I really like the words of Vaughn Vernon [IDDD, 2013] on the reasons for the creation of Anemic Models:
Much of our industry is comprised of sample code followers, which is not bad as long as the samples are of quality.
Often, however, the sample code purposely focuses on demonstrating some concept in the simplest possible way without worrying about good design principles.
Excessively simplified sample code, which usually demonstrates several getters and setters, is copied every day without thinking into the projects.
See you soon!
