Domain-Driven or Database-Driven?

Rails' style of domain modeling with ActiveRecord has developers create database migrations that are used to generate database tables and domain models.

Hibernate on the other hand, which is the technology used by Grails, encourages developers to create the domain models first, and then generate a migration for the database (using SchemaUpdate.) The focus of the developer work is on pure domain modeling.

Given that the focus of the ActiveRecord approach is on the structure of the domain models as persisted in the database, I call it Database-Driven. On the other hand, since the Hibernate approach puts the focus on pure domain modeling in the programming language, I call it Domain-Driven.

Is either approach better than the other?

While, it is generally a matter of personal taste, there are potential trade-offs.

Benefits of the Database-Driven approach over the Domain-Driven approach are:

Programmers with a DBA background may be more comfortable designing the database first

If performance was a typically big concern in the environment due to server limitations or other reasons, the Database-Driven approach reminds programmers to consider performance implications of their model design early

On the other hand, benefits of the Domain-Driven approach over the Database-Driven approach are:

Since the Database-Driven approach requires programmers to think about things like foreign keys and join tables, which are not related directly to the business domain model, programmers with an OO and Domain-Driven Design background might be more comfortable with the Domain-Driven approach.

Programmers who test-drive every line of code, including creation of the domain models, through the application layer (controllers), will be more comfortable with the Domain-Driven approach since the Database-Driven approach may seem distracting with the requirement to write migration code and generate the models amidst the TDD cycle.

Which approach do you prefer and why? It would be interesting to learn about other trade-offs between the two approaches.