This article was originally published on Medium.

For quite a few years, with growing popularity of Domain-Driven Design (DDD), I keep hearing that:

• DDD is hard
• DDD is only for core domain

This mantra has became very popular and often is (mis)used to advocate some crazy things people do to avoid crunching the domain knowledge.

In this post, I would like to return back to the roots. In nearly every talk or lecture that somehow concerns DDD, Greg Young mentions that, in his opinion, the chapter order of the Blue Book is incorrect. The issue is that most of the strategic design is placed to the latest chapters of the book. Since the book itself is not the easiest of reads, most of the people rarely get over 50% of it, which means they manage to get through the basics of the Ubiquitous Language, learn a little bit about contexts, then spend most of their time reading about implementation patterns.

But, if you look at Twitter of Eric Evans, you will see this:

“Domain Linguist” @ domainlanguage.com

Something begins to clear up, doesn’t it? Eric is not an “king of aggregates” or “master of repositories”. He is a domain linguist.

One of the major take aways from the (highly recommended) Implementing Domain-Driven Design workshop by Vaughn Vernon for me was this:

Domain-Driven Design is developing Ubiquitous Language within Bounded Context.

How crazy is that? Not “finding the right aggregate boundaries” or “splitting layers”. This – language and context.

What does it mean in real life and how does it correspond with the post title, you might ask? Well, here is my answer:
Use domain-driven design everywhere. Start with knowledge crunching, get as much knowledge about the domain as you can. Talk to domain experts, use techniques like Event Storming, mind-mapping and observations to get knowledge. At the end of the day, we all agree that 90% of the developer’s job is finding out what to do and only 10% is coding. DDD will allow you to understand what to do, from the problem space perspective, from your user perspective.

By writing this I do not suggest using implementation patterns like aggregates, repositories and so on, everywhere. This is just plain wrong. But two things  –  language and context  –  are your main tools to create a strategic map of the future solution, will create this missing link between your users’ problems and your proposed solution.

Each context might use any implementation technique suitable for that context That could be CRUD, Active Record, Event Sourcing or anything else find applicable and what is inline with the complexity of the context itself. However, the realisation of facts that you have different contexts, that your system almost never consists of one context only, that you need to understand your user’s language, will help you building a better system.

I gave a talk at DDD Norway meetup in March 2017 about this and you can find slides on SlideShare.

The same talk was squeezed to a ten minutes lightning talk at DDD Exchange 2017 in London, which you can watch on the SkillsMatter web site.

Do you agree or disagree? Have you got your own thoughts about this? I am happy to discuss.