Software architecture: the essential to know
The concept of software architecture is as indispensable as it is ignored by most developers. Those who are interested in it, even a little bit, have a huge advantage over others. Without any effort invested in the subject, your system is doomed to become impractical. Let’s go through the basics to avoid this.
Concept
Just saying the word “architecture” can intimidate a lot of developers and scare them away. Today, I’m going to prove to you that there’s nothing impressive about all this.
Software architecture is simply the organization in which the different components of your application will be separated and will communicate with each other.
In some companies, when the stakes are high enough, you’re going to have a person dedicated to this issue. A person who will make it a personal matter. A person in the position of software architect.
But it’s actually quite rare to have someone like that.
So what happens in real life without an architect? Most of the time, it becomes the problem of all the developers in a team. And out of laziness or just bystander effect, everyone ignores the issue.
The product is developed without vision, as quickly as possible, condemning it to the nastiest of curses.
Utility
The ultimate goal of software architecture is to facilitate the development, evolution, deployment and maintenance of a system.
Minimize intervention time and cost. Maximize and maintain developer productivity in the face of change. Make any addition or modification simple and fast.
If I insist so much on this point, it’s not for nothing.
A good software architecture obviously allows your application to work well. But that’s not the main reason it exists. It’s not the main reason why so much effort and care is put into the architecture.
You can very well have a software architecture that doesn’t exist – or that is very bad – and have a product that works perfectly.
In the real world, this is what happens most of the time. But the price to pay is that when it comes time to make this product evolve, it’s a nightmare. And it’s the responsible developers who pay the price.
By proposing some basic rules to your team, you can easily make your life – and that of your colleagues – more pleasant.
Scope
Software architecture is frequently confused with a bunch of other concepts and details that don’t matter here. Let’s start by clearing up all these.
An architecture is not the choice of a framework, a language and/or a database. A good architecture makes these choices secondary and interchangeable until the last moment.
A good architecture brings out the heart of the problem to be solved, not the implementation details.
There are many different types and philosophies around software architecture. I could do a whole article that lists them. The how of the why plus the why plus infinity.
But your time is precious, so I’m going to focus only on the one I know well and have practiced many times.
The well known “Clean Architecture” by Robert C. Martin.
This way of doing architecture has worked wonders where I’ve seen it. By dint of it, I became a fanatic of this way of doing things. It works, it’s fun to use and it’s absolutely wonderful to evolve.
Two fundamentals
First of all, it must be understood that everything I will discuss from now on is governed by SOLID principles. If you are not familiar with them, you should know that they are fully explained and dissected in the book.
Layered
You have to start with a strict and well isolated partitioning of the different layers that make up your application.
The architecture of a system is entirely defined by different independent layers. You start from the layer that deals with details and go to the most critical layer. From the user interface to the heart of the business rules.
To give you a global vision, we can start by looking at the official clean architecture schema.
Let us continue with the second fundamental to decipher all these hieroglyphics.
The dependency rule
It is a software architecture rule that specifies the relationship between the layers of your system. A high level component must not know anything about a lower level component. No dependency and/or mention of the lower layer must be introduced in the top layer.
Let’s zoom in on the clean architecture schema, to better understand the gibberish of the previous paragraph.
In the middle is the most important layer of your application: the business rules!
What are the most critical rules, which have the most impact, and which define the core of your application? This is the logic that must be found in the business rules.
Make it a component, completely separate from the rest, that does not depend on anything or anyone. A collection of methods and functions that could work on their own. This is the highest level.
What needs to change the least, what is needs to be the most protected, at the center of everything.
The next lower layer is the use cases. The rules that govern how business rules will be used. In which order and in which direction the data flow will be used.
In contrast to business rules, use cases have a dependency : business rules.
However, like business rules, use cases do not know the existence of the layers that depend on them. And the same logic is repeated from the most general layer of the application to the most specific.
The details depend on everything, the core depends on nothing.
These two major fundamentals already give you an idea of what should be put in place upstream for a good software architecture. Unfortunately I couldn’t find a way to continue this article without making a four hours long post.
Go further
I have suffered to talk to you about such a dense and complex subject, in such a short format. To allow you to understand the usefulness and the overall concept, this article is more than enough.
If you want to master these notions and use them in your work, you need to go further.
You understood it, my big recommendation of the day is the book Clean Software Architecture by Robert C. Martin.
This book is based on the premise that you are a developer who wants to evolve in the future and have a more global vision of things. So it starts from the code you already know. It goes on to introduce you to the principles of SOLID programming in detail. Then it will progressively approach each of the fundamentals of clean architecture and the links between them.
As you can imagine, there is more than just the two fundamentals I told you about.
Then he ends up applying everything you’ve learned with a case study that makes all the concepts covered very concrete.
You don’t need to know any particular language to read it. Basics in object-oriented programming (simple abstraction) are preferable.
I spent half of the time nodding my head in “dev epiphany” mode while reading it. I came out of it with a different and more global vision of the job. Just for that alone, I think it should be read by any developer looking to improve those skills.
Epilogue
The code quality of your application starts with its base. The basis of your application is its architecture. This upstream work has a major impact on the update and deployment cycles of your application in the future. Understanding and using these notions will also have a major impact on your career.
