This debate has been around since the beginning of time. Should you start with the database design and then build your app or should you build your app first and then design a database schema for your app? Developers, of course, hate being forced to work "from the database up". The relational world, with its tables and complex normalization rules and so on, is alien to them. Being forced to start with the relational model means, in many developers' minds, being forced to "keep it as simple as possible". They then have to build their application based on a model that is "horribly compromised" right from the start.
The concept of Domain Driven Design (DDD) is gaining traction among developers because it potentially removes these "shackles". With DDD, you don't have to build your apps from the point of view of it being in harmony with the established relational data model. In fact, such thinking is decidedly obstructive. The focus must be solely on the business domain that the application represents. You must develop a "ubiquitous language" that describes this domain in a way that both the business people and the developers understand. You must then devise "entities" that directly reflect what the business sees, and embrace the fact that the meaning of these entities can and will change according to the "bounded context". In other words, a unified domain model is deemed unfeasible, and instead we use numerous models, each being valid only with a certain context, and reflecting the view of the business within that particular "silo".
I can understand why this feels like a very pure and liberating way of thinking. After all, the goal of getting as close as possible to "implementing the business", rather than some compromised interpretation of the business, is noble and valid.
Except of course, the point inevitably comes when we do have to consider how this pure and lovingly-crafted object model translates into the world of the relational database. This is a real pain point, and ushers in the inevitable arguments concerning object relational mappers, versus the need to write SQL by hand (heaven forbid), in order to get the whole thing to scale.
It's clear that some developers would just like to see this obstacle removed completely. Many believe that object databases have now reached a stage where they are perfectly adequate for serving the data needed to drive customers smoothly through the application. Sure, they may need to store the odd bit of data in a relational database, for reporting purposes but, essentially, concerns about the object-relational impedance mismatch will just become irrelevant.
I don't doubt that object databases have improved substantially, and I admire the drive to produce an application whereby no business requirement gets "lost in translation". And yet this whole way of thinking still seems very worrying to me. It is still essentially a "silo" based approach. How does one, in this situation, get a unified view of the business, and perform integrated management-level reporting or auditing? How does one reflect in the business model a changing understanding of the business, if there are so many different models scattered everywhere?
It is true that the business model should reflect the business. But not a narrow view of the business, from the perspective of a single application, but a strategic, shared, enterprise-wide understanding of the business, and what each entity within it (such as a customer) really means. The "traditionalists" will tell you that the only way to build applications within an enterprise, and maintain any degree of sanity, is to develop this shared understanding, build it into the data model and then create your applications off of it, with DBAs and developers working as closely as possible to make the whole thing work.
You'll just have to keep calling me a young fogey, for the time being.
Cheers,
Tony Davis.