How To Determine A Good Application Architecture

When I started writing a small but real growing project, I noticed that the app shouldn’t only work well but also should be well organized. Don’t believe that thoughtful architecture is needed only for large projects. Proper architecture saves a lot of effort, time and money. And often it determines whether your project will survive or not. To my surprise, it is not so easy to find the answer to the simple question: “How to build a good/beautiful app architecture?”. Despite the fact that there are many books and articles devoted to design patterns and design principles, for example, SOLID principles and how to properly code, equally, there was a feeling that something important was missing.

Criteria for good architecture

Generally speaking, there is no universally accepted term “app architecture”. However, when it comes to practice, it’s clear to most developers which code is good and which one is bad. Good application architecture is primarily a profitable architecture that makes the process of developing and maintaining an app easier and more efficient. The app with good architecture is easier to expand and modify, as well as test, debug, and understand. That is, in fact, we can formulate a list of quite reasonable and universal criteria:

System efficiency.

First of all, an app, of course, must solve the tasks and perform its functions well, and in various conditions. These include characteristics such as reliability, security, performance, ability to cope with increased load (scalability), etc.

System flexibility.

Any application has to be changed over time - requirements change, new ones are added. The faster and more convenient you can make changes to existing functionality, the fewer problems and errors this will cause - the more flexible and competitive the system would be.

Therefore, in the development process, try to evaluate what is obtained in case if you later might need to change it. Ask yourself: “What happens if the current architectural solution turns out to be wrong?”, “How much code will undergo changes in this case?”. Changing one fragment of the system should not affect its other fragments.

System extensibility.

The ability to add new entities and functions to the system without violating its basic structure. At the initial stage, it makes sense to lay in the system only the basic and most necessary functionality, but at the same time, the architecture should allow easy addition of further functionality as needed. And so that making the most likely changes requires the least effort.

The requirement that the system architecture be flexible and extensible is so important that it is even formulated as a separate principle - the “

Open-Closed Principle” (the second of the five principles of SOLID)

: Software entities (classes, modules, functions, etc.) must be open for extension, but closed for modification.

Scalability of the development process.

An opportunity to shorten the development period by adding new people to the project. The architecture should allow parallelizing the development process so that many people can work on the program at the same time. 

Testability.

A code that is easier to test will contain fewer bugs and work more reliably. But tests not only improve code quality. Many developers come to the conclusion that the requirement of “good testability” is also a guiding force that automatically leads to a good design and at the same time one of the most important criteria for evaluating its quality. 

Reusable.

It is desirable to design the system so that its fragments can be reused in other systems.

Well-structured, readable, and understandable code. Accompanying.

As a rule, a lot of people work on an app - some leave, new ones come. After writing, to accompany the app, as a rule, is also necessary for people who have not participated in its development. Therefore, good architecture should make it possible for new people to relatively easily and quickly understand the system.

The project should be well structured, not contain duplication, have a well-designed code and preferably documentation. And if possible, it is better to use standard, generally accepted solutions familiar to programmers in the system. The more exotic the system, the more difficult it is for others to understand.

And for completeness, the criteria for bad architecture:

• It is hard to change because any change affects too many other parts of the system. (Rigidity)

• When changes are made, other parts of the system break unexpectedly. (Fragility)

• The code is hard to reuse in another application because it is too hard to get it out of the current application. (Immobility)

If you want to know the latest trends and news about Application Architecture - you can visit Gartner Summit, which will take place in London 8-9 June 2020.

Hopefully, this article helped you understand how to determine good app architecture! It’s always important to think in the long term, building an app to make it functional right now can do the same but will it really support any sort of growth & change?