I’m really pleased with the points brought out in the response from yesterday’s editorial, Database Design Techniques. I started with that topic intending to expose some of the complexities of an enterprise type application. Or, even, an application with a lot of complexity, having more than simple CRUD queries.
Others brought out key issues with database design essential for success. Knowing the different roles accessing your database, the use cases they execute, the flow of data into, within, and out of your application, and the complexity for meeting all of your end users goals. Completing all of these things, from a design first process, can take years to accomplish, and still only result in the 80% low hanging fruit, some of which brings much lesser value to the business.
As we know, Micro Services have been developed as an approach to simplify this process. Taking the strategy of classic software, micro services break your behemoth enterprise application, or even large applications, into smaller services. In classic software we used modules. That’s where the similarity ends. Micros services are modules, and much more. We know that breaking complex problems into smaller problems allows us to get a better understanding of the whole.
What brought me to this topic was a discussion around using Database Projects on applications developed with Entity Framework as the data provider. Using Code First, it is easier for multiple people to collaborate on a single database project. Database projects double the work, because you still have to create mappings. Even using T4 to generate mappings from the database, you still have to do some fine tuning. Please don’t think I said it is the only way.
The conversation was based on the fact that Enterprise Applications may access multiple databases. The concern was that a code first (considered wild because all developers could do it) change could be made to a database table for one application, which another application is not prepared, or scheduled, to have that implemented. Micros Services, or separated database access libraries, can help with this problem. If the database access code is in a centralized resource library for that application, it can be modified, and impact all applications.
Wait, I just said that you modify database access code in one place, and impact all applications using it. That was what we didn’t want. Correct. Now we move on to a mature model of programming, using interfaces as contracts, and principles like Open/Closed. Open/Closed means you can extend an objects capabilities. But you can’t change the existing interface.
Using a shared library of interfaces (onion model) you would do the following to change database access. First you would create a new interface for the new behavior, perhaps inheriting from the original interface, so that the objects can be down cast. Then you implement the new functionality on the new interface. New applications use the new interface and implementations. Old applications are upgraded to the new interface on their release schedule. When the old interface is no longer utilized, it can probably be absorbed into the new interface, and dropped.
The same principle is applied regardless of using libraries for data access, or micro services. The code is centralized for accessing a specific data store.
Does this get us where we want to go? Maybe it is a start.
Cheers,
Ben