db4o

I was exposed to Domain-Driven Design not that much time ago. Prior to that, I was struggling with the object-relational impedance mismatch while developing objects based applications. First attempt to get relational database close to the applications I was writing was an uneducated experiment to "wrap" the data into objects. The reason I think of this now as "uneducated" decision, is because I knew nothing about proper object relational mappers, neither had sufficient knowledge about patterns such as Identity, Unit of Work, Repository, etc.

The first wave ended up being a "home-grown" database access layer, trying to be an ORM. Quickly I felt the pain of that solution. Some good books helped to get the answer, such as Patterns of Enterprise Application Architecture.

The 2nd wave was the discovery of NHibernate. It was exciting and frustrating at the same time. Exciting, because it actually could link between the object oriented solution implemented with domain-first. Frustrating, since acceptance of an ORM such as NHibernate in a company that is a hardcore DB driven solutions is hard. To sell something that is new and "possibly is unreliable" is not a simple task, and it took time.

The 3rd wave was adopting FluentNHibernate as a development standard across the development team. Not only this has allowed us a better domain-driven development process, it actually has contributed to a fundamental change in development team - no more dumb developers coding down instructions, but developers that speak ubiquitous language with the business folks, developers that build applications based on the current domain understanding, changing and updating it to what business represents today.

Now I am moving towards the 4th wave - object oriented database. The idea is not original, but the thought is striking when you think - why should I have relational database for a domain/objects structured application? I have raised the question in my previous blog.

Today I have finished to read the book "The Definite Guide to db4o". Good reading. I recommend to look into it. I still cannot see how mainstream would accept it, since RDBMS are so much rooted in the minds of majority of developers and business people. There are some outstanding opportunities for OODMS, but those are not exposed widely.

db4o is mostly free, and available for both .NET and Java platforms. To sum this up I will bring an excerpt from the book to think about:

The key advantages are that developers can work with object structures as if they were in-memory structures, while there is no performance loss associated with processing taking place behind the scenes to fit those objects into a relational database. Little additional coding is required to manage object persistence. New application features can be added to products much more quickly to gain competitive advantages. Models can be updated more easily for debugging or refactoring, or in order to apply change requirements.