So I got this question from one of the developers in my team: What is domain driven design? I could of course point to the book from Evans but is that actually an answer?
How would you explain DDD in a few sentences to junior software engineers in your team?
I would say this practice promotes concentrating your efforts on the 'problem space' rather than the 'solution space'. Driving an emergent solution (the design) by studying and really getting to know and understand the domain. One of the practices (taken from XP) would be the writing of stories that occur in the problem domain. From these you can identify your use cases and objects for your design. They 'emerge' and tell you what needs to be in the solution, and how they will need to interact with each other.
In the process of discovering the "domain" you form a common language, that both the developers and all the other stakeholders in the project understand.
The domain model and its "lingo" is quite observable in the source code for the finished product. That is at least my experience
An important part of DDD is the so called ubiquitous language; i.e. speak the same language as the business experts. And make your code / architecture so that it reflects this language to avoid impedance problems.
Trying to understand what the software you're writing is about and reflecting that understanding in the model.
Domain Driven Design is about managing the complexity of an application in the domain model where it can most easily be distilled.
It's very difficult to describe in a few sentence, but I would recommend the InfoQ book as a good introduction. I have also heard of a lot of people doing a book club with Evans' DDD book which has helped a lot in understanding it.
DDD == rich domain model doesn't hold true. I appreciate that this answer itself was written 5 years ago.To me is the next level of OOD/OOP where the encapsulation is all about the problem space, as described and understood by users, and not so much about the technical implementation.
