When starting to write code for the first time, random code is written. Without any schema. Only the person who wrote it can continue a project written like this. Sometimes when we look at the projects we have done for the first time, it takes a long time to find where and what we have done. We can't even understand the codes we wrote ourselves :)
When we start work in a company or when we are involved in a large-scale project, we understand that there must be certain rules so that the written code structures can be easily understood by all team members. At this point, architectures come to our rescue. Because instead of creating a structure that only our own team can understand, using these structures that are already accepted in the software world will make our work more professional.
This is how the adventure of software architectures begins. So what exactly is this thing called architecture?
Software architecture refers to the fundamental structures of a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations. (wikipedia)
When we think of the word architecture in its literal sense, we arrive at the same conclusion. It is actually a design for the software that is intended to be made. Software architecture is the plan of how and in what way the software will be built. Choosing the right architecture is vital before starting a software. Because later on, architectural change will be very difficult and costly. This is like trying to adapt a building built with a wrong plan to a different plan later on. In such a case, it will be easier if the building is demolished and rebuilt.
"How do You Know if Your Software Architecture is Good?
Following are indications that you have a good software architecture:
1- The software should be easy to maintain
2- No code duplication
3- Team members should be able to easily understand the written codes-classes.
4- Existing modules must be changeable and expandable
5- It should be scalable
6- Team members should be able to easily add new features. And the software shouldn't be too affected by these new features.
7- It should be less affected by possible database changes.
8- The system should be easily reconfigurable.
The conditions here can be increased or decreased. But in general, our architecture should be able to afford them.
So what are these Software Architecture Patterns?
Although there are many software architecture patterns, we will talk about the 5 most commonly used architectural patterns, according to Mark Richards, author of the "Software Architecture Patterns" book:
1. Layered Architecture Pattern
Layered architecture is the most widely used architectural pattern. You may also have heard of it as the n-Tier. It is very popular among software experts because many software projects in the industry are made with this architecture or because it is more used in programming languages trainings that you can find on the internet.
It is suitable for projects that need to be build quickly. It can also be said to be suitable for more inexperienced developers with relatively limited knowledge of architectural patterns. Because that is richer in terms of tutorials or resources. The fact that it contains sustainability and testability standards is one of the reasons why it is more preferred.
The fact that the changes that need to be made in the basics may require a complete re-planning of the application can be counted among its negative aspects. Java EE, Express, Laravel and many more frameworks are built with this architecture. Naturally, applications created with these frameworks emerge in this architecture.
It basically consists of four layers. There are Presentation-Application-Business(Logic) and Data Access layers. Sometimes three layers are used too. A 3-tier architectural Client-Server Architecture pattern using Presentation-Busines-Data Access can also be counted.
For example, MVC, MVVM, VIPER use this architectural pattern.
2. Event-Driven Architecture
Many software that interact directly with humans spend most of their time doing nothing. Such software is always in standby mode. Event-driven architecture can be preferred in such software. This system, which accepts all data and is idle, becomes active when a transaction arrives. This process is then assigned to the appropriate modules by a central unit. These qualify as an Event and only when the event occurs the software does the necessary work.
With this architecture, it is possible to write modules that perform operations such as mouse clicks and fingerprint reading. Programming a keystroke-activated keyboard is a very suitable example of event-driven architecture.
Like layered architecture, not every data has to pass through all layers. The software can be easily extended when new event types are wanted to be added to the software. The fact that the written modules do not affect each other facilitates the testability of the software. In software using Event-Driven architecture, defining a default process for the failure of modules makes the software more stable.
Notification systems are usually built on the basis of this architecture. Otherwise, continually checking notifications can cause high resource consumption. I think it would't be wrong to say that the most suitable architecture for systems with user interfaces or asynchronous data flow is event-driven architecture.
3. Microkernel Architecture
When we consider internet browsers, we know that many add-ons can be added and used in a very functional way. There are different plugins for different processes. Each process is considered as a different core. These cores can be used repeatedly in different models, and a model can use more than one core at the same time.
IDEs like VSCode or Eclipse that can be added plugins are actually the best examples. They have minimal features to run the code when they are first installed. We can add the features with the help of plugins that we want our code to work while compiling . In these IDEs, we open files, write code, and meanwhile, a lot of microprocesses are running in the background.
It can be a good choice if you want more flexibility and modularity than layered architecture. But it has worse consequences in terms of performance. If you're developing an application that has a fixed set of core routines and a dynamic set of rules that need to be updated frequently this is probably the best architecture to choose.
4. Microservices Architecture
Small projects are always sweet. Because they are always easier to understand, modify or test. But in growing software projects, things get difficult when complex functions, processes and modules are involved. Sweet little softwares don't get so cute when they grow up :) Because they don't accept changes easily anymore. Modifications would be difficult and complex.
The purpose of the Microservice architecture is to create many small programs and then bring together for one large program. In such a case, it will be easier to add new small programs or perform operations on an existing one.
These microservices, which are separated according to their responsibilities, can work alone. Not to be confused with the microkernel approach. Here, different services performing different tasks can be easily separated. For example, e-commerce sites are very busy on Black Friday discount days. Services can be special written for those days. Only services that require that much server power are run when needed. On other days, services that require less expense are returned. Another difference from the micro core architecture is that all the small parts need to come together and serve a single purpose.
Communication costs may increase in this architecture, which requires easy separation of all tasks. If a service written for taking the images of a website works very slowly compared to the loading of the site, the visuality may be distorted until the images are loaded on the site. It is the architecture most preferred by international companies that generally work remotely. It is the best choice of companies like Netflix.
5. Space-Based Architecture
There are two primary components within this architecture pattern: a processing unit and virtualized middleware. Mark Richars
Processing unit: Includes backend processes, web-based components, and application components. While a single processing unit is sufficient for small-scale projects, processing units may increase with growing projects. Processing units resemble microservice architecture in terms of their self-contained structure.
Virtualized middleware: Controls data synchronization and requests. The most important component of the software is always databases.
Any problem with databases can cause the entire application to crash. This problem has been tried to be solved by performing distributed database operations in space-based architecture. In the distributed database part, the term "cloud architecture" is also used for this architecture, as jobs can be assigned to multiple servers.
It makes use of RAM so that user logs do not tire the database too much. A lot of work stored in RAM allows software made with this architecture to run faster. However, the difficult nature of transaction support in RAM databases makes it difficult to use.
While the ability to test independent modules independently is among the advantages of the architecture, it may not be suitable for software that includes operations that require some types of analysis. For example, for an operation that requires averaging, it will be necessary to access all the distributed data. Such transactions are divided into sub-processes and propagated to nodes. When all operations are completed, the average should be calculated. This causes performance issues. Apart from that, it is very suitable for softwares where functions that require individual processing are concentrated. Since these processes can be handled in RAM without reaching the database, the process is very fast. It is highly preferred in projects such as social networks.
Conclusion
Someone who has just started software may be faced with questions such as "Which architecture should I choose?", "How do I choose?". If you are a new starter or still at the junior level, you can start with MVC, one of the layered architecture patterns. At later times, you can learn about other options and choose the right one for your next project.
Architecture knowledge alone will not be enough for the modules we mentioned here to be independent from each other or to offer options such as adding new modules. Because a class written without applying the Single Responsibility principle, one of the SOLID principles, cannot be separated from the whole structure.
Most of the items mentioned in the 0-Advanced Software Development article, which is the first of this series of articles, is interdependent. Applying only one item can increase your code quality, but applying a single item will not improve high level your software.
In this article, I mentioned 5 of the most used architectural patterns. Of course, software architectures are not limited to these. With there are many more architectures, it is not possible to master an architecture with such short explanations. I will try to write more about these architectural patterns after this series of articles is finished. I'm thinking of making a few simple iOS apps with Swift using some of them and sharing them here. Let's leave it here for now. Thank you for reading.
In the Advanced Software Development series:
Next article: "2- Why/How to Write a Comment? What is Clean Code?".
Don't forget to like if you think it's useful :)
Always get better…
Top comments (0)