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.
As J.B. said in his article, the database exists solely to bring persistent state to the domain (and application) objects. Logically, then, it isn’t part of the “outside world”, to be connected by an adapter to the domain objects. Instead, it’s part of the memory model in which the action takes place. It’s one of the tools used to build the middle hexagon. (I feel instinctively that the adapters shouldn’t have persistent state. I’m probably wrong.)
Think of the domain objects as being “always there”. When the adapters are talking to them, they’re in primary memory. But when no-one is interested in them they may be archived out to secondary storage. If someone needs one of them again, the middle hexagon arranges to “re-inflate” any archived objects. This may show up as a slight delay – just as when you re-access an application that was paged out by your operating system. The delay in opening a connection to any particular domain object depends on “how far away” it has been archived: instantaneous when it’s active in memory, slightly longer when it has to be awakened from a database, longer still if it was archived to an old guy in a back room with a quill pen. Whatever the technology used, though, it’s still just technology. Still nothing more than the life-support environment in which the domain objects ply their business.
I discovered during our workshops last week that this is a huge topic. I’ve only scratched the surface here, and I haven’t had the time to work through all of the consequences in practice. But the ideas do seem to hang together, at least in this person’s head if nowhere else. More to come, I expect…