Usually, the conversation about architecture is raised when the development stops due to certain problems in the project.
Only a limited number of people understand the project and its architecture
- "It's difficult to add a person to the development"
- "For every problem, everyone has their own opinion on how to get around" (let's envy the angular)
- "I don't understand what is happening in this big piece of monolith"
A lot of implicit side effects during development/refactoring ("everything depends on everything")
- "The feature imports the feature"
- "I updated the store of one page, and the functionality fell off on the other"
- "The logic is smeared all over the application, and it is impossible to track where the beginning is, where the end is"
It is difficult to reuse/modify existing logic
At the same time, there are usually two extremes:
- Either the logic is written completely from scratch for each module (with possible repetitions in the existing codebase)
- Either there is a tendency to transfer all-all implemented modules to
sharedfolders, thereby creating a large dump of modules from it (where most are used only in one place)
- "I have N implementations of the same business logic in my project, for which I still pay"
- "There are 6 different components of the button/pop-up/... In the project"
- "Dump of helpers"
Therefore, it seems logical to present the desired requirements for an ideal architecture:
Wherever it says "easy", it means "relatively easy for a wide range of developers", because it is clear that it will not be possible to make an ideal solution for absolutely everyone
- It should be easy to master and explain the project and its architecture to the team
- The structure should reflect the real business values of the project
- There must be explicit side effects and connections between abstractions
- It should be easy to detect duplicate logic without interfering with unique implementations
- There should be no dispersion of logic throughout the project
- There should not be too many heterogeneous abstractions and rules for a good architecture
- A good architecture should speed up the solution of tasks, the introduction of features
- It should be possible to control the development of the project
- It should be easy to expand, modify, delete the code
- The * decomposition and isolation of** functionality must be observed
- Each component of the system must be easily replaceable and removable
- A good architecture should be applicable to most projects
- With existing infrastructure solutions
- At any stage of development
- There should be no dependence on the framework and platform
- It should be possible to easily scale the project and the team, with the possibility of parallelization of development
- It should be easy to adapt to changing requirements and circumstances