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...
- Choose a user case.
- 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.
- 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...
- Break the system down to its core use cases and entities. Write Independent objects for each of these.
- 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.
- Implement a web API using the core objects written in step 1.
- 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