How is Domain Driven Design different from just using a specification?

Question

I read that Domain Driven Design is about concentrating on the problem domain instead of concentrating on the software. They say that it is easier to solve the complexities of the problem domain than the complexities of the software, because after you have solved the domain, you know better how to build the software, too. Also they say that actually the domain is more complex than the structures of the software or that if you don't see the forest from the woods, you are in trouble.

But how is Domain Driven Design different from just using a specification for the software? I mean, of course we should get to know the problem domain before we start coding. Is DDD reinventing the wheel?

Answer 1

Domain-driven design is more about establishing a common model of the world (and an associated common language) that both you and the domain experts can use.

In theory this means that developers can write code that reads like a description of the problem domain, and domain experts can look over developers' shoulders and see what's going on.

A specification makes no such promises about a common language or model of the world, it just says "we're going to build something specific". The highly specified class model you come up with might work, but it may not reflect 'reality' particularly well.

There's a good free book on Domain-Driven design here (login required unfortunately).