Domain-Driven Design - A personal tale

A little bit of backstory

I’m a very pragmatic and hands-on person, for the better and for the worse. It probably originates from many different things, genetics, experiences and definitely my upbringing in a rural place with a difficult access to the internet.

Instead of Googling why our first family computer was acting up yet again, it was a long and painful troubleshooting process. Studying technical books always felt less appealing than simply hacking away on a hobby project, doing internships or quitting university and starting to work full-time.

Learning on the job

Learning on the job has been an amazing journey. Not only from a technical perspective, but I’ve also become an absolute sucker for domain knowledge.

Every time I started a new job, I found myself in a completely new domain. From smart home appliances, to waste logistics and finally the football industry. And if there is one thing that’s certain, it’s that I love sponging up all of this knowledge and putting it to good use.

Hello DDD

My first introduction to DDD was an interesting one. At the time, I was definitely one of the domain experts within the company relatively speaking, when a new colleague arrived.

Right from the beginning they had big plans. CQRS here, bounded context there… my head was spinning, but I was intrigued and asked question after question. Just to become more and more skeptical. Even the simplest things seemed to become so unnecessarily complicated.

So I blamed myself. Clearly, this person has more experience than me and is much more educated. I just don’t understand these concepts... yet.

Learning DDD

To combat my shortcomings, I decided to finally grab a book about DDD. Specifically I chose Learning Domain-Driven Design whose reviews seemed to resonate much better with me, compared to “the blue book” and others. And boy oh boy did it resonate with me.

Instead of preaching a specific solution, the book, or rather its author Vlad, does an amazing job explaining how to make good decisions for yourself. How to choose a good solution out of different potential ones, depending on various heuristics and other factors. He doesn’t just say “it depends”, which is just an empty statement. But rather he explains on what it depends.

Closing thoughts

• Having all the technical knowledge in the world, isn’t enough to make great decisions.
• Having all the domain knowledge isn’t enough to make great decisions.

A sophisticated solution for a simple problem can be just as bad as a naive solution for a complex problem. At the end of the day, what matters is having great collaboration and being open minded.

And if you’re an expert in everything, you should probably look for a new challenge ;)