Why Developers are Still Using Anemic Domain
IT Tips & Insights: A Softensity Software Engineer weighs in on anemic domain, its shortcomings, and why it’s used so often.
By Wesley Baldan, Software Engineer
The terminology: invoke “objects” and “oriented” was described for the first time in the 50s and early 60s at MIT. Allan Kay coined the term “object oriented programming” at grad school in 1966 or 1967. Yet today, there are many developers that don’t understand the basic principles of OOP.
Let’s look at the reasons why anemic domain is used by so many companies, causing chaos to software maintenance.
What is an anemic domain?
Anemic domain is a class design that contains only data, without behavior. We can’t confuse anemic class and anemic domain, as there is a big difference between them. An anemic domain is done by an anemic class.
Let’s first understand what a domain is:
Domain is where the business rules are. According to Eric Evans’ book, DDD: Tackling Complexity in the Heart of Software, domain is the heart of your software. It’s in the domain that you need to take great care to keep your class in a valid state. For example, to have a balanced account with the right value.
An anemic class is very useful with DTOs (data transfer objects), Views. It’s a class that has one goal: transport data between layers. For example, when a user fills in a form, the frontend will send the data to the API throughout a JSON. You’ll have an endpoint with a class to get this data. This class will just have properties without behavior. This is a good example to use anemic class.
Donkey domain
Photo by Florian GIORGIO on Unsplash
Example of anemic domain:
Example of rich domain:
Look at the anemic domain, where all setters are public and without behavior. There is also an empty constructor and you’ll be able to create an account without an “Account Number”.
Benefits of anemic domain
- Many developers are used to this approach, and it’s chosen because it’s easier.
I suggest that developers should try to develop their skills and knowledge in software design and practice the implementation of rich domains. - In rare cases, the project doesn’t need to use a rich domain, in which case an anemic domain could be a reasonable choice. I suggest only temporary projects. Example, an application that will be used for an event and after the event the application will be thrown into the garbage. And the application must be without complexity.
Drawback of anemic domain
- OOP principles violation
- It’s hard to perform maintenance
- Business rules duplication
- It’s hard to keep the domain in a valid state. Because the properties are public, there is no guarantee that some service will break your class. Not even tests keep your domain in a valid state in this case. I repeat, not even tests keep your domain in a valid state.
- Service class proliferation. Because the business rules are in the service classes and not in the domain class.
- It’s hard to do unit tests.
- Coupling between system components.
- It’s difficult to enforce business rules and constraints, as the logic for enforcing these rules is often spread out across multiple service classes. This can lead to inconsistencies and bugs, as developers may not be aware of all the rules that need to be enforced.
Conclusion
It’s my impression that developers use anemic domains because:
- There are many articles on the internet that use anemic class in their examples. This could lead the developer to “understand” that this is the right way to build software.
Example, when you study Entity Framework and search for articles, most of them will use an anemic class to show EF’s use. For learning practice examples, I think this is valid because the focus is to learn a new technology and not to understand or discuss business modeling. - Old developers from DAL (Data Access Layer) architecture and used DAO (Data Access Object). DAO is an anemic class, so I think old developers confuse DAO and domain.
- Lack of knowledge of how ORM works. Currently, Entity Framework can work with domain classes smoothly. It’s possible to work with Value Objects and easily set up the map classes between domain and data infrastructure (databases).
- Lack of knowledge in business modeling.
- Lack of knowledge in Object Oriented Programming.
- Pressure to deliver the software fast, which can burden the quality of the code.
Source of image is: pluralsight.com Vladimir Khorikov course — Refactoring from Anemic Domain Model Towards a Rich One.
In the graphic above we can note that the anemic domain implementation is faster, but the code will charge on maintenance. I have always suffered with this in almost all my developer years. A chaos to do maintenance.
A Word From the MASTER
The fundamental horror of this anti-pattern (anemic domain) is that it’s so contrary to the basic idea of object-oriented design; which is to combine data and process together. The anemic domain model is really just a procedural style design, exactly the kind of thing that object bigots like me (and Eric) have been fighting since our early days in Smalltalk. What’s worse, many people think that anemic objects are real objects, and thus completely miss the point of what object-oriented design is all about.
Suggested Resources:
Domain-Driven Design in Practice
Refactoring from Anemic Domain Model Towards a Rich One
About
Hi, My name is Wesley. I’m a 39-year-old software developer with more than 12 years of coding experience. I love what I do, and I love to follow good practices in software development.
A computer black screen, a cup of coffee and one keyboard and the magic is done.