I would advise to not to take this article as a solid source of truth for what DDD means and implies. There are several inexact claims and a few of them plainly wrong. It may be slightly useful to start to get familiar with some of the DDD jargon but that's it.
Thanks for doing the "good work" and promoting DDD. While I definitely see the positive side of promoting a difficult topic in an accessible way, I also share the opinion of some of the other commenters, that there is plenty of room for improvement. I'll try to be constructive, with some examples:
Grammar needs work. Even in the first paragraph we have this "[...], after what they are joint in a complex application." Should this be "[...], after that they are joined in a complex application."?
The article uses terms inaccurately or in a confusing way. "Microservices is an architecture design model" - I do not get the need for so many words mashed together - words that are partial synonyms. Why not "Microservices are an architectural style", or shorter "Microservices is an architecture"? How does it help if you use "design" and "model" additionally?
Some sentences are self-evident, or are simply not true. For example "Domain-driven design is the idea of solving problems of the organization through code." That is actually not true. Software in general is the idea of solving problems of the organization through code. DDD is something a bit more specific.
I actually thought about sharing this in my company, because there are so few accessible resources explaining DDD. But in its current form, I do not think it is usable in a professional environment. I'm confident that with a bit of rewriting it could be much more useful.
"Complexity is a relative term. What’s complex for one person is simple for another."
No. Difficulty -- easy or hard, familiar or unfamiliar -- is relative. Complexity -- whether things are intertwined such that they can't be reasoned about separately -- is objective.
Mobile Developer currently specializing in Android development and Kotlin, but also interested in and occasionally playing around with iOS and Flutter.
I would advise to not to take this article as a solid source of truth for what DDD means and implies. There are several inexact claims and a few of them plainly wrong. It may be slightly useful to start to get familiar with some of the DDD jargon but that's it.
Thanks for doing the "good work" and promoting DDD. While I definitely see the positive side of promoting a difficult topic in an accessible way, I also share the opinion of some of the other commenters, that there is plenty of room for improvement. I'll try to be constructive, with some examples:
I actually thought about sharing this in my company, because there are so few accessible resources explaining DDD. But in its current form, I do not think it is usable in a professional environment. I'm confident that with a bit of rewriting it could be much more useful.
Great article, definitely helped to clear up a few things for me 👍
Thank you, very glad to hear that :)
This article really encouraged me to learn more about DDD. Thanks.
Happy to hear that!
This is probably one of the best posts about DDD. Short, clear, and concise. 👏
Thanks Federico :)
"Complexity is a relative term. What’s complex for one person is simple for another."
No. Difficulty -- easy or hard, familiar or unfamiliar -- is relative. Complexity -- whether things are intertwined such that they can't be reasoned about separately -- is objective.
One of the simplest explanation of DDD, I've found so far.
Thanks Sara.
Sharing this with my whole development team now
Thanks Faizan!
This article helped me a lot, thanks
Glad to hear that :)
I have not signed into my dev.to account for almost year but this post deserved a comment.
Good job Sara!!
Thank you!
Entered the mailing mail, congrats. Great post! 🔥
Thanks David!
Very well and precisely written article about DDD. It helped me clarify few things I was always confused about.
Thanks and good job
Thanks!
Untold teams have assumed deep domain knowledge and struggled without the aid of emergent design.
Thanks for the great article.