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

closed as too broad by gnat, durron597, Ixrec, Eric King, user22815 Aug 29 '15 at 22:18

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Why be database independent? You have chosen the OS/Language. If you are database independent you cannot use the goodies that a particular database offers and have to implement them yourself. – Ed Heal Aug 29 '15 at 11:04
  • 3
    If you are going to create a database independent system, or if you decide to use a specific database as a strategic platform is a major architectural decision, comparable to which programming language you use or if you develop for one operating system vs. cross-platform. Both approaches have their cons and their pros, and just because you found a book where Uncle Bob embraces the first approach does not mean its "better". – Doc Brown Aug 29 '15 at 11:05
  • @DocBrown thanks for the feedback. Im just exploring my options there are so many different design patterns in use it can be quite tricky choosing the "best" one since many will still do the job. Im trying to look at the project from all angles before I jump in. Its pretty big so I want to try my best to implement a stable backbone so in 5 years we dont have to repeat the process but rather tweak and polish the interfaces to suit what ever we need then – kurt Aug 29 '15 at 11:18
  • @kurt - To be truthful you will have to repeat the process in about five years time - technology moves on as well as requirements. – Ed Heal Aug 29 '15 at 11:21
  • 1
    please don't cross-post: stackoverflow.com/questions/32284551/… – gnat Aug 29 '15 at 11:22

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.

  • Thank you. The entire system is web based, if you dont have access to internet you cant access the system, all our customers use the same codebase. It never has and never will be released as a standalone application for resale. The entire company works off monthly subscriptions. I already use mvc architecture religiously but as stated in my question isn't this more of an abstraction than a "database independant" approach.Or can simply having a database abstraction layer which could be edited to support different DB's be considered database independant?It may just be a matter of terminology – kurt Aug 29 '15 at 11:09
  • The important thing is that the core application should not know any details of either the database or the user interface. This is why I suggest starting with simplified versions of both: knowing that you need to be able to support an implementation that is substantially divergent from the one you originally planned forces you to incorporate the levels of abstraction needed. As long as you make sure all your dependencies point towards the core application rather than away from it, you'll get to the right place. – Jules Aug 29 '15 at 11:25
  • Of course, dependency inversion and dependency injection are the key techniques for achieving that. – Jules Aug 29 '15 at 11:27
  • Thanks for the advice. I think I will try this, it cant hurt to write my core models initially without knowing every othe detail afterall i am going to need them in the end regardless of the abstraction layer. So basically any method goes as long as its implemented neat and tidy and does nt have direct communication with the DB – kurt Aug 29 '15 at 11:35
  • Basically, yes. It's all about the direction of dependencies. – Jules Aug 29 '15 at 11:38

Not the answer you're looking for? Browse other questions tagged or ask your own question.