Domain-Driven Design: the elephant in the room
Over the years, I’ve been shocked to see that almost nobody applies Domain-Driven Design (DDD) in their projects. It’s worrying that most developers haven’t heard about it, others actively reject it, while there’s another group that just go with the flow of the shortest (and painful) path of the anemic model because, “hey, it’s what everyone has been doing and we aren’t gonna change it now”
As professionals, we shouldn’t try to adhere to how things are done, but how things should be done and, as always, with a good amount of common sense and hearing what others with more experience and knowledge than us do to face similar problems.
Complex domains ask for DDD
Domains with lots of business rules are too often a nightmare and the resulting code is a mess of entangled classes that make us struggle and spend countless hours of analysis and writing code that will ultimately be a roadblock against ourselves in the long run. And no, your ORM won’t protect you from chaos.
This path has been explored many years ago and there’s a way to handle complex domains, like there’s a way to deal with 2nd grade equations.
DDD is here to help.
Can DDD help me save my soul?
Yes, it can. It for sure will lower the complexity of the final application. It does by putting the focus in the domain model and using a set of patterns and practices and recommendations to keep the complexity bar low.
The anemic model is the enemy. It can be identified so easily that even a blind monkey could spot it from a distance. In them, models (classes in C#) they don’t expose any methods. In other words, they don’t expose behavior. Thus, anemic models are a set of interrelated classes that act as mere data containers. Nothing more, nothing less.
What’s wrong with anemic models?
Let’s hear the masters:
“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 short, they seem to be a real problem: An anti-pattern against the essence of OOP that causes undersirable side effects and riddle our industry.
But what makes them so harmful?
Mainly, due to these reasons:
- Business logic is out of the model.
- Instead of being a responsibility of the model, where they have their full meaning and are aligned with the domain. Hence the use of “services”, that are like puppeteers moving dumb entities around the stage. Orchestration comes at a cost: Complexity grows exponetially. Wreck ahoy!
- Consistency relies entirely on intermediaries. This alone should scare us.
- Anemic models are normally mutable. This is a big problem because it allows models to be inconsistent. Even the slightest modification of an instance can unroll the red carpet to the drama.
What should I do?
Domain-Driven Design is a huge topic. Hopefully, there are a lot of books, courses and interesting reads to get you started into this subject.
I really encourage you to follow the courses by Vladimir Khorikov on PluralSight:
- Domain-Driven Design in Practice
- Refactoring from Anemic Domain Model Towards a Rich One
- Domain-Driven Design: Working with Legacy Projects
- DDD and EF Core: Preserving Encapsulation
- Vaughn Vernon: Implementing Domain-Driven Design
- The classic blue book of DDD by Eric Evans: Domain-Driven Design: Tackling Complexity in the Heart of Software
- Courses by Steve Smith and Julie Lerman: You could start with Domain-Driven Design Fundamentals
Written by José Manuel Nieto