What is domain driven design? [closed]

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?

Solution 1:

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.

Solution 2:

InfoQ have a free eBook:

Domain Driven Design Quickly

It is a good read with plenty of examples.

Solution 3:

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

Solution 4:

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.

Solution 5:

Trying to understand what the software you're writing is about and reflecting that understanding in the model.