This doesn't exactly answer your question, but I see the opposite of domain-driven design as database-driven design. In database-driven design, the database schema is created first, and then you create your classes with full knowledge of what the schema looks like. The advantage is that you have a better understanding of what's going on 'under the hood', and minimize the effects of impedance mismatch. However, the downside is that the database schema, because it's relational rather than object-oriented, doesn't translate very to objects (for example, there's no concept of a collection in relational databases).
In domain-driven design, in theory you create your data objects just like you would any other class, and treat the database as simply a persistence layer. In Layman's terms, the database is only a storage container and you don't care HOW the objects are stored, only that they are stored somehow. This eliminates the impedance mismatch and you have one less thing to worry about. In practice, however, you still have to be aware of how the objects are stored, and there can be performance issues when the ORM you're using is trying to spit out a complex SQL query.
Edit:
Here's an example of what domain-driven design should be like, in principle. Let's say you have a Person class, like so (in C#):
public class Person
{
public int Id { get; set; }
public string Name { get; set; }
public Address Address { get; set; }
public ICollection<Person> Relatives { get; set; }
public Company Employer { get; set; }
}
Now, in a relational database, this will probably translate to 3 tables, a Person table, Address table, and Company table, with a bunch of relationships between them. However, this is vastly different than how the programmer sees this object. The programmer sees it as an instance of a Person object with 4 parameters, one of which is a ICollection. This doesn't match up very well with the database table structure, hence the 'impedance mismatch', or in Laymen's terms, a difference in layout between the relational model and object model.
In domain-driven design, I should be able to do this:
Person person = new Person();
// set each property to something
Database.Save(person);
Now, the person object is saved. I can retrieve it like so:
Person databasePerson = Database.Get<Person>(idOfPerson);
And it'll return my Person object, just like how it was before I saved it. This way, I'm not concerned at all with how the databse is saving it, or worry about the impedance mismatch. I simply save it and retrieve it as needed.
This is all in theory though. In practice, you'll probably have to manually specify the 'mapping', or how the classes know which table/column in the database to get data from. It can get pretty complex when you're trying to map to more complex types such as dictionaries and other ADTs, and also when you're trying to pull data from multiple tables into one class.
