The fact that you are using objects in your project or product does not mean that the software development process will be any easier. Essentially, you will run into issues that you need to address. In general, some problems will come up before you start designing your solution, some challenges will come up while you are developing your solution, and others issues will need constant attention.
These issues can be summarized into three categories:
- How Object Persistence has been done in the past
- Technical Challenges
- Political / Social Hurdles
When you ask a developer about a system that he created and then drill-down into the details such as the “data”, many times you will find a “data-centric” thinking in that person even though he is knowledgeable about object-orientation. You will hear that person talk about stored procedures, SQL’s, datasets, even the term entities, etc. Unfortunately, you will discover that the data model is actually driving the entire application. There may or may not be a domain model; but, there will be a database model.
In a domain driven system, the Domain Model must always drive the Data Model. Never, must the Data Model drive the Domain Model.
The Domain Model dictates when and how the database schema needs to change. If you need to make a design change in your domain model, the database model needs to be updated accordingly so that it can support the domain model. No compromises in the Domain Model must be taking place to support the database model in any way.
The Domain Model should be designed without any regard to object persistence or user interface exposure.
Think of it like this: Design your domain model as if you have unlimited storage space available and all the horsepower in the world to support your object model. Concentrate on solving the domain problems. Concentrate on solving the use cases. Concentrate on learning the business and your users tasks. You can always re-factor your domain model later. Since you most likely will use a layered or tiered approach, the domain model should have no clue about how to save and retrieve itself from persistence.
Let me emphasize the importance of the Domain Model driving the solution including a Data Model. Consider the Domain Model or Applications in general as being Nature. Consider the Data Model as being human beings. Human beings need nature to survive and live in this world whereas nature does not need human beings to survive. Databases need applications but applications certainly do not need databases. A database without an application is rendered useless whereas an application without a database can still be extremely useful to the user. An application can use different ways to persist the object model or information in general. It does not have to be a database, necessarily.
You can also call Impedance Mismatch a desperate move of old technology trying to survive in an ever-changing world of rapid delivery and instant gratification.
Object-Relational Impedance Mismatch is the difficulty of mapping a Domain Model to a Data Model and vice versa. If you chose to use a relational database as your data storage, you will need to deal with the Impedance Mismatch.
There are several reasons why there is an Impedance Mismatch. The Domain Model is a three dimensional model that includes behavior and data, whereas a Data Model is a flat, two-dimensional model without any behavior. Relational databases do not support inheritance, a crucial feature of object orientation.
On the software development side, impedance mismatch describes the huge differences between the world of objects and the world of databases. Both worlds are also worlds apart where the database world is stuck in a world without much progress and not much innovation. For example, the SQL querying language has not seen any improvements or innovation in the last 20 years.
In the world of objects, it is a thriving world with innovations towards ease of development, productivity, creativity, and automation.
The biggest drawback of using Object Persistence is not so much technical but rather political. When you are developing a solution and you are pretty much in control of the entire design and have the freedom to explore different Object Persistence solutions, you might not be faced with the political ramifications. But, if you are in a corporate environment where most corporate environments are hindered to be productive by red tape and personal agendas, introducing an Object Persistence can be somewhat “challenging” to say the least.
Even if you have created the “perfect solution” including an Object Persistence that works, you will still have to potentially face your boss, any cross-team impact including a database team, a mindset of people doing it the “old way” or “the way things have always been done”. You will encounter all kinds of excuses from people even from your boss to convince you, and in many cases order you to do it the old way. By the old way and by the way the database team would want you to do it is that the Database Model is driving the Object Model. Remember, in a domain driven system, it must always be that the Object Model is driving the Data Model (if there is one).
There is hope, though.
Despite the grim outlook when you face the database team, there is a chance that you may be able to introduce an Object Persistence strategy that can work for both teams. Communicating the difficulty of persisting objects and the challenges faced from the software development point of view, for example, can be a pleasant surprise.
Even if some managers try to improve the software development process and the issues around object persistence in the corporate world, it comes down to the executive(s) running the IT department or the people in charge of software development. The ideal scenario is that a CIO fully supports productivity and that he concentrates his efforts in the execution and operation of the IT department and being able deliver to the stakeholders.
You may not be faced with the issues of large corporations if you are working for a smaller company or even if you are self-employed. You will most likely still have to deal with political issues no matter how big or small your company is.
Depending on your situation, you may or may not be able to introduce the perfect persistence strategy. But, in todays solutions, you have to deal with persistence one way or another. Architecture is all about compromise. Try to find a compromise that will allows developers to be productive and yet adhere to company guidelines such as a data strategy that a company might already have in place. I welcome very much your feedback and encourage you to so. I future posts I will go into examples and provide possible solutions to this core problem.