DEV Community

Discussion on: DDD All-The-Things

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.