I was recently reading Eric Evans' DDD book and found a really interesting point about how we structure our code.
You know how we often create a class and immediately fill it with Getters and Setters, but then leave all the actual 'logic' in separate service classes? The book calls this an Anemic Domain Model.
What caught my attention was the suggestion to flip this: instead of a class that just holds data, we should strive for a Rich Domain Model. The idea is that the entity itself (like a Document or a Customer) should have methods that execute its own rules and protect its data.
I confess that, by default, I always created 'empty' models and pushed the logic elsewhere. Itβs curious how this simple shift in mindset brings the code much closer to true Object-Oriented Programming and prevents business rules from being scattered all over the system.
Top comments (0)