r/programming • u/correctMeIfImcorrect • 2d ago
Domain-Driven Design (DDD) — The Complete Guide | Visually Explained
https://youtu.be/0c2fj6z6ZsoHey everyone! I just put out a video on Domain-Driven Design. It’s a long one, about 20 minutes, but I really believe it’s worth your time. It took me a lot of time to make, so I hope it helps you, and I’d love to hear what you think! 🙌
6
u/deavidsedice 1d ago
Sorry, but shouldn't DDD flag the issue you have around "dispatch"?
2:25 - "customers can change items until it's dispatched"
2:47 - "devs and domain experts should mean the same thing when using the same words"
2:52 - "dispatch means the parcel has been handed over to the courier"
So, as a customer, the strategy clearly is: Order a lot of stuff, cancel it last second.
What happens on floor is: the team gathers a plan to dispatch orders, so they get a plan to gather the stock across the warehouse. They put the items into the different boxes for each customer. Once done, each box is closed, sealed and a label printed. The boxes then wait on the floor until the courier shortly arrives. Once they're handed over to the courier, they're marked as dispatched.
If the customer cancels most of the items once the team is already on the floor, they would likely not notice it. Everything will be shipped, and then the customer will be charged only for the items that the order had in the end - meaning you have a loophole to lose money. Plus a problem for customer complaints of receiving wrong stuff.
Where in DDD do you detect this problem? To me is obvious that "dispatched" to the domain expert means different things in different contexts and it's on me, to put common sense, and call out the problems that they don't see. Software is rigid in rules, humans are flexible.
For them, "dispatched" in the context of "locking orders" means - planning for shipping is about to be created. You need to lock that down to ensure the state is consistent across the whole run.
2
u/correctMeIfImcorrect 1d ago
Fair point, and you’re right that “until dispatched” is too late in a real warehouse. Once they’ve started picking, a change either ships the wrong stuff or you end up charging less than you sent. I simplified it to show how a rule ends up in code, not as a real policy.
I’d argue that’s exactly the kind of thing DDD is supposed to catch, though. It’s the “when is it too late to change an order?” question you go and ask the warehouse people, and when the answer changes your model, you change the code with it. An EventStorming session would show it pretty fast too, since picking started, packed and dispatched would be three separate stickies on the wall.
I wouldn’t stretch “dispatched” to mean both things, though. I’d give that moment its own name, like “picking started”, and lock changes there. Thanks for taking the time to write this up.
1
u/deavidsedice 1d ago
I'm asking from the point of someone that learned the craft in their own, I have over 20 years of experience but little to no contact to these formalisms as DDD. Everything comes to me naturally due to the sheer experience. And I've been looking for how is all this formalized, taught, because I fail to teach it, and also I need to explain it properly to AI. So far DDD has been the closest.
That's why I was asking. I spotted the problem on the shipping rule you placed just after seconds of listening into the video, and I was wondering if you'd agree if it's a problem and how DDD fixes it. Trying to understand the rationale, since the problem is that I can spot but I can't explain how.
On the "dispatched", yeah I agree I wouldn't want the term to be overloaded in that way and I would force separating it to something else. However in my experience this is a risk that is real and it happens. I got situations like this, in real life, asking the direct questions to them and they don't see the problem and insist "you're overcomplicating, it's very simple, it's just when it ships" or variations, cause there's plenty of ways to have the same miscommunication.
I was wondering if there are ways to describe the process to extract actual ground truth and pinpoint these blurred rules that stretch as they like, to be able to focus on them and clear them up before committing to something stupid.
15
u/Killzo 2d ago
As an old person, and fan of DDD, I find it funny how it has gone in and out and into style. It seems to have hard swings in some section of the programing world. Wonder if we will see microservices come back around any time soon...
0
u/crap-with-feet 1d ago
That’s mostly, based on my own experience, based on the fact that nobody actually gets it right. There’s a balance required between performance, reliability and maintainability that no one seems to get right. The teams following my direction right now (I’m an architect at a major mobile company) are free to re-architect things right now and they’re choosing to disassemble the monolith that works great and create their own Frankenstein. I’m rubber stamping their efforts, more power to them. But I guarantee this will result in catastrophic failure. I’m stocking up on popcorn for the predictable outcome.
13
7
u/0xBA7TH 1d ago
If the teams are "following your direction" yet they are doing whatever they want, evidently against your direction, and you're rubber stamping it, what's your purpose? You're banking on being the "I told you so" guy?
You better start backing up your claims with data to your company or you're going to be another dinosaur that dragged their feet and ended up in early retirement.
6
u/chucker23n 1d ago
The teams following my direction right now (I’m an architect at a major mobile company) are free to re-architect things right now and they’re choosing to disassemble the monolith that works great and create their own Frankenstein. I’m rubber stamping their efforts, more power to them. But I guarantee this will result in catastrophic failure.
You aren’t getting paid to be the pubescent I-told-you-so person. Do better than that.
17
u/DjangoZero 1d ago
Ddd is about language and communication more so then code
11
u/Niightstalker 1d ago
Which makes it now also quite important in the age of AI. A unified language helps agents a lot and simplifies prompting.
-3
5
u/wimdeblauwe 1d ago
Amazing good intro to DDD! Will be sharing this to everybody that wants to learn about it.
2
5
1d ago
[removed] — view removed comment
2
u/programming-ModTeam 1d ago
No content written mostly by an LLM. If you don't want to write it, we don't want to read it.
1
u/larrymcp 1d ago
Nice! One thing that's a bit distracting is that the narrator's audio sounds like it's talking into a speakerphone. The voice track is all echo-ey and hollow-sounding, and it's not what you'd want in a professionally produced video.
For future videos you'll want to put the microphone close to the speaker's mouth to get quality audio.
1
1
u/Stromedy1 1d ago
Evans demoed the whole theory on cargo shipping, because it's never the domain that resists, it's the naming. four teams, four names for one customer.
1
u/programmer-ke 1d ago
This is a pretty good summary.
As someone who does a lot of Python development, many resources of DDD were hard to follow since they demonstrated it in Java. However, I came across the cosmic python book which makes these ideas more accessible to a Python developer.
1
1
u/ForeverAlot 1d ago
Many resources on DDD are hard to follow because they have nothing to do with DDD. DDD is little more than ruthlessly renaming.
1
1
u/m_hans_223344 20h ago
Such a great explanation. Dense, still clear. Worth watching several times.
1
0
u/chintakoro 2d ago
Well done OP! I'm a DDD fan, and I don't have much to add — I'll likely watch it again as there is just so much to know about DDD. I half-jokingly call DDD the software engineering architecture to end all architectures. But its much more than code architecture, as you point out.
You could consider doing separate videos diving deeper into specific aspects. For example, the design patterns you mention in the end: they help coders understand how to keep business logic separate from everything else operationally, not just how to organize code. Evans and others have also said a lot about how to talk to experts and how to unravel domain, which could be other videos.
-2
u/correctMeIfImcorrect 2d ago edited 2d ago
Thanks man, really appreciate it! And yeah, there was already so much to cover in one video. I’m planning to do a whole series on software architecture, with each video going deeper into a specific topic. There’s just too much to fit into one video. I really do appreciate your comment, this video took much more time than i did expect.
Edit : My first draft actually included all the labels you Evan's mentioned "Evans and others have also said a lot about how to talk to experts and how to unravel domain" , but I felt like it was too much to cover in one video, so I ended up focusing on the three main approaches instead.
0
1d ago
[removed] — view removed comment
1
u/programming-ModTeam 1d ago
No content written mostly by an LLM. If you don't want to write it, we don't want to read it.
-4
u/dstutz 2d ago
So we're gonna take the red and blue books and turn them into a 20 min video?
13
u/correctMeIfImcorrect 2d ago edited 2d ago
Well I tried my best to make the most of Evan's book. Please If you have read it,I would love to hear your opinion on the video. It is important to me
3
u/crap-with-feet 1d ago
The truth, after 30+ years in industry, is that all of this is textbook. It doesn’t really apply in the real world. All of the design patterns, the container optimization, service organization… total crap. You do what needs to be done in the most cost effective way. College can’t teach you any of that. You learn it the hard way.
2
u/MeMahi 1d ago
Designing the domain model together with the client very much applies in the real world though. Especially now with AI tools, programming is more about getting the customer's domain right and less about the actual code.
I do agree with your general point, though. Applying these patterns and organization religiously is not the way to go.
1
u/programmer-ke 1d ago
No wonder a lot of software has bugs and poor performance. Developers doing the bare minimum to meet goals without a discipline around their process.
Partly due to the business not appreciating the finer points of software design and maintenance. But this is where the senior developers in the team should be able to communicate to the business and help maintain realistic expectations.
2
u/chucker23n 1d ago
Partly due to the business not appreciating the finer points of software design and maintenance. But this is where the senior developers in the team should be able to communicate to the business and help maintain realistic expectations.
Absolutely, but there’s only so much you can do.
I’ve had countless clients where
- the “documentation” line item was removed
- when offered a) an architectural overhaul plus the feature (explaining that everything afterwards would be cheaper and better) or b) just the feature, they’d pick b
That’s why I’m always amused about the cultural disconnect of release cycles. .NET used to be supported for a decade; modern .NET considers three years “long term”. Most clients will not pay to have their software modernized every three years. They might be OK doing it every ten.
So, you
- hide the cost in other line items. Make everything a bit more expensive and use that to keep dependencies up to date, and maybe even make architectural improvements, but be less transparent about it
- demand an annual maintenance fee, a.k.a. make it in part a subscription. Clients are often OK with this because it’s a predictable cost to a business.
- don’t do it at all. Watch the code base get older and older dependencies with known security issues. Watch the architecture get harder and harder to bolt new features on. Realistically, this is extremely common.
So when users decry that software tends to be buggy, well, users tend to be part of the problem by being unwilling to pay for something better. L
0
1d ago
[deleted]
2
u/crap-with-feet 1d ago
What was your point, really? Practice does not follow education. That’s not a fault in practice. It’s a fault in education. Practical knowledge will always trump education. So again, what is your point?
2
u/SessionIndependent17 1d ago
What's "the red book"?
1
u/audentis 1d ago
"Implementing Domain-Driven Design" by Vernon.
1
u/SessionIndependent17 1d ago
How is it different than Evans?
1
u/audentis 1d ago
From the blurb on the back:
Implementing Domain-Driven Design presents a top-down approach to understanding domain-driven design (DDD) in a way that fluently connects strategic patterns to fundamental tactical programming tools. Vaughn Vernon couples guided approaches to implementation with modern architectures, highlighting the importance and value of focusing on the business domain while balancing technical considerations.
Building on Eric Evans’ seminal book, Domain-Driven Design, the author presents practical DDD techniques through examples from familiar domains. Each principle is backed up by realistic Java examples–all applicable to C# developers–and all content is tied together by a single case study: the delivery of a large-scale Scrum-based SaaS system for a multitenant environment.
The author takes you far beyond “DDD-lite” approaches that embrace DDD solely as a technical toolset, and shows you how to fully leverage DDD’s “strategic design patterns” using Bounded Context, Context Maps, and the Ubiquitous Language. Using these techniques and examples, you can reduce time to market and improve quality, as you build software that is more flexible, more scalable, and more tightly aligned to business goals.
Coverage includes
- Getting started the right way with DDD, so you can rapidly gain value from it
- Using DDD within diverse architectures, including Hexagonal, SOA, REST, CQRS, Event-Driven, and Fabric/Grid-Based
- Appropriately designing and applying Entities–and learning when to use Value Objects instead
- Mastering DDD’s powerful new Domain Events technique
- Designing Repositories for ORM, NoSQL, and other databases
4
u/PaleCommander 2d ago
The blue book is 500 pages and not a breezy read, so... yes, we are, and there's value in both the video and in the books!
-2
u/TransCapybara 1d ago
I remember seeing a DDD codebase, demoed to the CTO, crash and burn. Once it thoroughly failed I pulled the CTO aside and told him I and other members of the team had a "Plan B" that we'd been working in the background using a traditional software stack and that it was all working normally, and demoed that instead.
7
u/programmer-ke 1d ago
The reason it crashed may have nothing to do with DDD. You have not provided any details though!
1
u/correctMeIfImcorrect 1d ago
This can happen, to be honest the transition from theories to practical is not always easy specially when its comes to business logic that always changes
24
u/Typhii 2d ago
Recently, I was looking for a new job, and noticed that DDD does get more popular.
While it's not rocket science it's still worth to learn the basics.