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.
Top comments (9)
I've also made it halfway through that book. In my opinion the book would be better if it was 50% thinner, it is way too verbose for me.
What I disagree about are the percentages of 10% and 90%, this might be true for systems (apps) which are heavy on business logic and light on technical complexity, but on many of the systems that I worked on the domain was pretty simple (or someone else called an "analyst" already did the work for me) and the challenge was in finding the optimal technical solutions. DDD may help there too but the useful tools are more the repositories and the aggregates than the deep linguistic stuff.
Or do I see that wrong?
(by the way, I agree with you, or at least I think I do, in many cases - way too many projects, including a few I've worked on yself, suffer or fail from a lack of domain understanding)
"It depends". Sometimes things we see as technical challenges, are in reality consequences of lacking domain knowledge. For example - when I was working on a holiday property rental system, it was easy to make a list of reservations, but hard to keep the list of things that happen today (arrivals, departures, stay-overs) and calculate availability per day. Then, I discovered the domain concept of "day" and everything became much easier to implement. Evans gives similar example about the "share pie" when technical challenges about keeping financial figures free from rounding errors were critical and risked the delivery of the whole system. When new domain concept was introduced - these challenges just vanished.
This is one of my important points. Sometimes, and I think - too often, we take things that, like you wrote, already delivered to us by business analysts in a form of requirements, and start seeking technical implementations for them. Often we get stuck or our solutions become very complex. I believe, when one sees such thing, she needs to stop and think - am I doing the right thing, why everything is so complex, what is the real problem I am trying to solve?
Absolutely true!
There's no doubt that many projects running into "technical obstacles" suffer from inadequate understanding and analysis of the domain. I've seen this more than once, e.g. in administrative/financial systems that did not have a concept of "account" or "journal" and instead kept track of changes or statuses through numerous "flags" on a database table.
Once you "discover" the right concepts (in this case, journals or accounts), then you can take apart the big ball of mud and the whole thing suddenly becomes simple (not only conceptually but also technically - the code, no more spaghetti and workarounds).
However I still maintain that the "blue book" could be half as thick as it is and would be better for it.
About the book. Yes, this is true. Many people argue that bringing a lot of technical patterns actually ruined it. Some say this brings unnecessary rigidity to the community as such since people think that you must have aggregate roots and value objects, otherwise you are not doing DDD. Or if you have repositories - you are doing DDD. Where, apparently, both are wrong. The insight to it is that without this the book most probably would not have been taken by publishers since they were telling Eric that without code there cannot be a technical book.
Today, we at least have the "Domain-Driven Design Distilled" book by Vaughn Vernon, which is quite good to start with DDD.
I do like the repositories and the aggregates, but the writing is just a tad too verbose for my taste, I see certain concepts being rephrased again and again ... getting one's point across succinctly and briefly is also an art. The concepts are good but the author should have been a little bit more self-critical about reviewing the text and stripping it down.
Well at least that's my opinion.
Maybe I'll check out the "distilled" text, I do have an interest in the concepts.
I am right there with you. I think people focus too much on the technical patterns from "DDD" like Aggregate, Entity vs Value, Repository, etc. The primary value of DDD is in modeling the software using the business's own terminology and boundaries. (You could look at it as a corollary of Conway's Law.) Implementing the technical patterns by themselves is complexity for no reason, but is the most common take-away from DDD. (I did this too for a time.) There is no specific set of technical patterns that will solve every business problem without actually learning about the business. "no silver bullet"
DDD explains why the hardest task in software engineering is naming things!
Speaking in a common language is chapter 2 if the book. The article is click bait
I clearly see a linguistic problem here :)
The Ubiquitous Language is mentioned nearly on every second page in the book. That was not the point of my article.