Arjen wrote up what I’ve been repeatedly saying to the teams I work with.
The database outlives the applications build around them.
I’ve discussed this a bit with Arjen on the phone the other day and we’re definitely on the same level on this. Then why write up a response? As always, the little things matter! Arjen’s conclusion comes down to:
Now, I’m not saying that a rich domain model is not important. I’m just saying that — as with any solution — it is not a silver bullet. Use it when it gives an advantage, but don’t swear by it. In the grand scheme of things, your precious OO model is not as important as you think it is.
I swear by a domain model!
There, I’ve said it. All the people that I have worked with for the past couple of years can confirm that these words are true to fact. This week, during dinner with Alex we’ve discussed the applicability of ADO.NET vNext and the potential it has to transform the way we build applications with the .NET platform. In this discussion, we've also talked about the current set of available tools and our own experiences with them. I got reminded of my planned travel undertaking coming January together with Frans author of "The Database Model Is the Domain Model". I will sit at point blank range, behind the steering wheel for Frans in the passenger’s seat. For roughly 8 hours straight! Fear is distracting me...
Arjen's post made me rethink the phrase "the database outlives the applications build around them". For one, there is the schema-ownership conflict and the dual-schema problem (see Ted Neward's excellent essay titled The Vietnam of Computer Science). Over a year ago I wrote about the radical thought "The database should keep his mouth shut" which clearly leaves the ownership in the hands of developers. The harsh reality is that the developer's ownership of the schema is temporary at best, and it is probably better this way! Alex reckoned that developers would be very pleased with the upcoming LINQ to SQL (DLinq). I tried to explain (horribly) that due to the schema-ownership conflict and the fact that LINQ to SQL tightly couples the application and the logical schema of the database, LINQ to SQL is only feasible in cases where the logical schema matches the problem domain your applications targets. You don't require mapping between these two models. Unfortunately this is hardly ever the case. I've experienced this myself over the years for evaluating the applicability of Neo.
A related issue to the question of the schema-ownership problem is the dual-schema problem. The metadata of an application is in two different places: logical schema of the database, and in the conceptual schema of the application. Refactorings in one will often require refactorings to the other. My experience with such refactorings lead to my preference for "starting with the domain model" and to practice DDD. Scott W. Ambler and Pramodkumar J. Sadalage did a great job describing refactoring techniques for databases in Refactoring Databases. Unfortunately large organizations and their database administration group are often trying to catch up or have been caught in political issues.
I gave up. Since my technical review work on ADDDP I was finally able to let go of all the infrastructure related problems and to really focus on the domain model. Thanks Jimmy! I wrote up my thoughts and experience in the article "Organizing Domain Logic". My money is on Microsoft's ADO.NET team and their powerful mapping engine that transforms between the different schema's and the integration of relational concepts into the languages. For now I prefer manual mapping using iBATIS.NET combined with Spring.NET and the patterns found in DDD and ADDDP.
This post will haunt me forever.
Also see the first, second, third, fourth and fifth part of this series of posts on the next generation data access for the .NET platform.
Metadata infrastructure which will enable you to add custom attributes at runtime or design-time (discussion).
Serialization to be able to integrate with WCF. Currently the base members of the entity types are not annotated with data-contract serialization attributes. The team is currently looking at ways of enabeling this scenario (discussion).