DEV Community

DDD All-The-Things

Alexey Zimarev on August 03, 2017

This article was originally published on Medium. For quite a few years, with growing popularity of Domain-Driven Design (DDD), I keep hearing ...
Collapse
 
leob profile image
leob

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)

Collapse
 
alexeyzimarev profile image
Alexey Zimarev

"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?

Collapse
 
leob profile image
leob • Edited

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.

Thread Thread
 
alexeyzimarev profile image
Alexey Zimarev

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.

Thread Thread
 
leob profile image
leob

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.

Collapse
 
kspeakman profile image
Kasey Speakman • Edited

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"

Collapse
 
kodikos profile image
Jodi Winters

DDD explains why the hardest task in software engineering is naming things!

Collapse
 
aronysidoro profile image
Aaron Lelevier

Speaking in a common language is chapter 2 if the book. The article is click bait

Collapse
 
alexeyzimarev profile image
Alexey Zimarev • Edited

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.