r/programming • u/correctMeIfImcorrect • 14h 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! 🙌
5
u/DjangoZero 2h ago
Ddd is about language and communication more so then code
5
u/Niightstalker 1h ago
Which makes it now also quite important in the age of AI. A unified language helps agents a lot and simplifies prompting.
1
8
u/Killzo 9h 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...
5
u/crap-with-feet 5h 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.
3
u/wimdeblauwe 2h ago
Amazing good intro to DDD! Will be sharing this to everybody that wants to learn about it.
1
3
u/StudentOfAyEye 48m ago
Totally agree, and honestly the timing is great because more and more job postings are mentioning it, even for roles that aren't strictly "DDD positions." A lot of teams use parts of it without realizing it has a name. The bounded context concept alone can change how you think about talking to other services or modules, even if you never go full tactical patterns. If you're just starting out, I'd suggest focusing on strategic design first (the context maps, ubiquitous language stuff) before diving into aggregates and domain events. It makes the tactical stuff click way faster.
2
u/StudentOfAyEye 39m ago
Honestly, that took me the longest to appreciate too. Once the team shares a real ubiquitous language, the code kind of falls into place, but getting there means genuinely listening to the domain experts instead of projecting our own assumptions onto the problem. It's one of those things that sounds simple but is surprisingly hard in practice, especially when developers outnumber the domain people in the room.
1
u/larrymcp 29m 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/deavidsedice 7m 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.
-1
u/chintakoro 11h 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 11h ago edited 11h 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.
-4
u/dstutz 12h ago
So we're gonna take the red and blue books and turn them into a 20 min video?
8
u/correctMeIfImcorrect 12h ago edited 12h 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
1
u/crap-with-feet 5h 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 2h 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.
0
3h ago
[deleted]
1
u/crap-with-feet 3h 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?
3
u/PaleCommander 6h 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!
1
19
u/Typhii 12h 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.