DEV Community

loading...

Discussion on: The Concept of Domain-Driven Design Explained

Collapse
mesmerizero profile image
Alin Purcaru • Edited

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.