Frans Bouma has posted an essay entitled The Database Model is the Domain Model on his blog. I haven't read it completely, but it looks to be similar to what Frans had written in Appendix A, entitled Other Domain Model Styles, in Jimmy Nilsson's book Applying Domain-Driven Designs and Patterns. You can read my review here:
As you can tell by the title, The Database Model is the Domain Model, Frans is suggesting that the domain model and the database model in your applications are the same. This is certainly the approach he uses in his O/R Mapper, LLBLGen Pro, where entities and their relationships are based on the database model.
In more cases than not, I find this to be true and desirable for a few reasons:
- It is really easy to go back and forth between the domain model and the database model, because the entities and relationships are identical.
- The queries and code responsible for object relational mapping is straight forward and easy to understand.
- Domain-model concepts like ActiveRecord and Data Access Objects play well in this model and are very easy to understand and maintain.
- Code generation and RAD tools can be applied in most cases with great efficiency.
When your domain model starts to move away from your database model you start to reduce the benefits above. This isn't to say that doing so is a bad thing as in theory object-oriented programming and the database have different goals. With a database you try to normalize data, and with OOP you try to normalize behavior.
The nice thing about ADO.NET vNext, is that the ADO.NET Entity Framework has the concept of the Entity Data Model, which can vary from the Database Model and allow you to break away from the database model when necessary. I still like to keep the models as close as possible because I believe it makes the applications easier to maintain and understand, but it doesn't always work out so cut-and-dry.
Source: David Hayden ( ASP.NET Web Developer )
Filed: ADO.NET vNEXT, O/R Mapping, Code Generation