This is the first in a series of articles about architecture. One of my goals for this year is to get a better understanding and overview of architecture’s in web application using PHP. In particular I will be using the Symfony framework. But everything that I discuss could be applied to any framework. You could create your own framework with Symfony components.
Framework and architecture
A framework provides you with a set of basic features that any web application requires. A good framework is one where you have the freedom to decide which parts to use. Where you can decided the structure and architecture of your application. Symfony allows us to do that.
In the past I worked with and on projects where architecture was an after thought. I worked with different frameworks, CMS and e-commerce systems. When I bring up the notion of architecture, then some developers will answer. Well we just follow the guidelines and rules of that framework, CMS or e-commerce system.
That is not architecture. This is not how a professional should work with these systems. Yes you have rules and guidelines to follow. You should follow the coding guidelines of your framework. You should follow the architectural constraints of the framework. But a good framework will not dictate the architecture, it only provides the components you can use. A framework that dictates the architecture, is not the framework you should use.
A CMS or e-commerce system will dictate the architecture at some level. Most of the time this means you need to create a plugin or module in a given directory, and some rules of implementation that you need to follow. But how you decide the architecture in your module or component, or between the different components that you create. That is up to you. And also this is architecture that requires some thinking.
So what exactly is architecture?
Architecture is the ability to change. The better your architecture, the easier it is to change the features of your system. The faster and cheaper changes can be made in the future.
A perfect architecture means you have little technical debt. The time it takes to build features should be the size of the feature. More technical debt means that each feature takes more time to build then the previous one. This is not something you want.
The downside of architecture is that it takes more upfront time before you have working software.
But think a minute about this. Do you rather have software that works, but cant’ be changed? Meaning that it becomes useless in the future. Or do you rather have software that does not work. But can be easily changed to work? This means that the software can be changed to become and stay useful forever.
In reality we don’t live in those 2 extremes. But in practice this are the 2 extremes we need to think about now. I rather have a good working system next week, then a bad one now.
The business experts and your customers are not developers. They don’t know the consequences of a bad architecture. You are hired for that! It’s your job to ask for that extra time to get a good architecture. They might not like it now. But they will definitely love you later!