In one of last week’s architecture workshops (see databases as life-support for domain objects) our group briefly considered how the new product line might emerge gradually from a series of user stories. The Product Owner agreed that stories about persistence would probably be placed relatively far down the backlog, behind the stories that deliver the first several tranches of usable business value. The Product Owner wants to see and understand the business logic first, and only later will he care about “non-functionals” such as persistence and levels of service.
So if we truly design and build our application story by story, without being tempted to predict what the Product Owner will want in the future, then the database will not exist until after many of the domain objects. This is business-level support for @jbrains‘s assertion that the database should be developed last. And it knocks sideways the idea that the ‘architecture’ should be designed at the start of a project.
Update, 9 Nov 2016
I’d like to thank Joe Rainsberger for taking the time and trouble to resurrect his article, which had disappeared from the interwebs sometime during the 11 years since I originally wrote this post.
In his article Domain-Centric Programming J.B.Rainsberger tells a very nice story about how a project was improved by leaving the database development to the very last.
“The last thing I did was to build a simple, four-table database schema and a small component that read from and wrote to the live database. Since I had practiced test-driven development … I had high confidence that I had implemented everything correctly. Since I had focused on the domain, rather than the database, I was even more confident that I had gotten the database right the first time.”
(Thanks to Brian Marick for bringing the article to light, via the agile-testing group on Yahoo.)
By pure coincidence I’ve been telling very similar stories on a project I’m coaching at the moment. We’re currently investigating approaches for the architecture of a new product line, and the group thinks that we might gain a lot by thinking in terms of a hexagonal architecture. During the last couple of weeks I’ve been thinking a bit more about such models, and I’ve come to a rather remarkable conclusion: the database is not on the outside. I now believe that the database is merely one of the technologies that together create the nutrient environment supporting the objects in the middle hexagon.