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 

Anemic model 

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 systemsIt’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:

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: 

Additional resources: 

 

Written by José Manuel Nieto

Twitter: https://twitter.com/SuperJMN
LinkedIn: https://www.linkedin.com/in/superjmn/

Stay up to date!



Leave a comment