Don’t disagree with most of the above although it’s perhaps worth expanding a little.
The single most important concept in DDD is to focus on the problem domain. To put technology obsession to the side and concentrate primarily on modelling the problem you’re trying to solve. So put ajax, ORMs, databases, frameworks etc. into the background and instead make sure you have a complete, accurate model of the problem first and foremost. (Of course you still need the architectural components – but they’re explicitly subservient to the model). DDD calls this “Ubiquitous Language” – a model expressed in terms domain experts and developers alike use and understand. A model where the names of classes, methods etc. are taken from the problem domain.
DDD doesn’t mandate /how/ you capture that model, although the book implies using an OO language to do so.
MDA shares that same notion of modelling the problem domain first and foremost (the PIM, Platform-Independent Model). As opposed to DDD, it recommends creating that model with UML. But the intent is the same: understand the problem domain without tainting it with (software) architectural concerns.
MDA’s PSM (Platform-Specific Model) is somewhat analogous to applying the architectural patterns in DDD (e.g. aggregate, repository, etc.). Again – while different in specifics – both aim to solve the problem of converting a ‘pure’ problem domain model into a full software system.
So summing up, I’d say they are similar in two ways:
- The centrality of the Model (as @Rui says) – specifically the /Domain/ model.
- Applying architectural patterns to the model in order to realise the target system.
hth.