I haven't really delved into the formal theories around domain driven design, but I'd have to say I use this same approach. In my experience, the best approach is really going to depend on the experience of you and your team. Most people seem to start in the database, but I personally think that can cause problems. In the same breath, I have to say I don't think this is a steadfast rule, tho; it really depends on skills and experience. With all that said, my approach tends to start by forming a domain model based on use cases. This domain model represents the data your system will manage. Next, I like to identify the business services that correspond to the domain model; the data access layer, which essentially mimics the business logic layer; and, finally, I wrap it all up by formulating the data model, which is loosely based on the domain model.
The only thing I like to stress here is that the application's domain model should be designed independently of the data model. The reasoning behind this primarily lies within the fact that you don't want your application domain model held to restrictions of the data store, which could possibly change over time. As far as I'm concerned, the data store is merely an end-point -- an end-point that can (or, perhaps should support the ability to) be replaced with no change to the application, outside of the data access layer.