Why Domain Driven Design?
Domain Driven Design is a poison. The book is one of the most poorly written technical books out there. There are a handful of good ideas buried in the 1,000 page unedited verbose rambling slog. The whole book should only have been 10 pages.<p>Besides Eric Evan’s inability to write, the poison of DDD comes from locking in businesses&#x2F;domain concepts into your core technology, making them inflexible and making it difficult for the business to iterate on new ideas. This is a very good article on why you don’t need it (and the author’s example is healthcare, which has complex business domains). <a href="https:&#x2F;&#x2F;dev.to&#x2F;cheetah100&#x2F;domain-driven-disaster-147i" rel="nofollow">https:&#x2F;&#x2F;dev.to&#x2F;cheetah100&#x2F;domain-driven-disaster-147i</a><p>Something snapped in Evans’s mind around his over focus of Java and UML that made him try to force every idea into a class hierarchy, and force that model onto software development as a whole in the form of DDD.