Clean Architecture - How to go from "Database Driven" to "Independent of Database"

Question

I am looking for some clarity and hopefully some advice on writing clean architecture for a large system. My Companies "Web Solution" is +-10 years old, my job is to rewrite it. It is written across a few thousand asp classic pages all with their own sql queries with absolutely zero consistency (I spend the vast amount of my maintenance/debugging time fixing these since products may appear in one search and not another etc.). To put it bluntly its tangled knot of code straight out of my worst nightmares to deal with.

Up until yesterday I had a pretty straight forward plan for the re-development and to solve my inconsistency issues...

1. Choose a user case.
2. Write one or two stored procs/sql functions to control the dataflow for the selected case i.e. save user, add user, edit user etc.
3. Update the relevant asp pages on the current system to use the above procs/functions.

End goal - end up with an entirely database driven application, while achieving much needed stability & integrity during development. Once this is achieved I was planning to write a web API (using the same database procedures) and then implement a web UI,Mobile App and anything else needed on top of this API. While daunting this seemed like a pretty decent solution to me, even with its flaws it’s exponentially better than what we currently have to work with.

Then I came across Uncle Bobs Guide to Clean Architecture.

I understand the concept and it seems awesome, all most too good to be true from my current position but the deeper I delved into it the trickier it became in terms of "This is great! Now how would I implement it?” One of the rules the guide calls for is that the application be completely database independent. Meaning what I had planned would never make the cut. I had to admit the cold hard fact that this is a completely foreign concept to me, right from the first day I started learning to program the heart and soul of the application was the DB so it’s very hard for me to adjust my thought process and not treat it as such.

I have done some further reading and was hoping for some feedback to whether or not I’m on the right track, or if there is a cleaner cut, cleaner approach.

PHP is my primary go to language for most web applications so this is the language my theory would most likely be implemented in...

1. Break the system down to its core use cases and entities. Write Independent objects for each of these.
2. Write a data interface model, which abstracts from the database (since the database currently is primary source for use cases and entity logic the above objects would likely based of their current table). This would allow me to keep anything DB related in one location and provide the same result of integrity and consistency that implementing stored procs/sql functions would, although this would still not make the application "database independent" since I would have to modify the abstraction layer if I changed providers i.e. from SQL Server to Oracle. This is where my uncertainty comes in, is this a good approach? It’s highly unlikely I would change data sources but who knows? Also If I am going to follow the guide’s architecture I want to do it as closely as possible and I know that if this step is not implemented correctly it would defeat the purpose since the database layer would slowly start seeping back into the primary application model.
3. Implement a web API using the core objects written in step 1.
4. Implement API driven UI's for whatever platforms necessary.

I apologise for the essay but I wanted to be as clear as possible in the hopes that this will help get me the best guidance. I would really love to learn and one day be highly proficient in this type of architecture and while there is a ton of online information about its structure and concept there is extremely little on how to implement it, or more on how to change your mind set when developing an application when you are used to the database being the absolute core of the application.

Any kind of feedback will be highly valued and appreciated. Thanks

Answer 1

First of all, I wouldn't approach a clean architecture in PHP. One of the main goals of clean architecture is to allow the user interface to be considered as essentially a plugin to the application, allowing you to change between types of UI easily. By going with PHP you are restricting yourself essentially to web-based interfaces. If you are familiar with a more architecture-independent language, I would pick that instead.

After that, I would start by developing a simple implementation of one or two use cases with a text user interface and no database - just use a collection to store your business objects. Once you're happy with how that works, you can experiment with how to attach your user interface and database layers in such a way that your original version still works - once you have that working, the rest should be fairly simple.

A few useful things to look up:

• MVC frameworks for the language you end up using. MVC (or MVP) works nicely as the UI layer for clean applications

• The Repository pattern for data access - this is probably the best way of separating your data access layer from your application layer

• Hexagonal Architecture - this is an alternative name for the same concepts Uncle Bob calls Clean architecture, and you can find more useful resources searching for this.