Asosiy tarkibga o'tish

About architecture

Problems

Usually, the conversation about architecture is raised when the development stops due to certain problems in the project.

Bus-factor & Onboarding

Only a limited number of people understand the project and its architecture

Examples:

  • "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"

Implicit and uncontrolled consequences

A lot of implicit side effects during development/refactoring ("everything depends on everything")

Examples:

  • "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"

Uncontrolled reuse of logic

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 shared folders, thereby creating a large dump of modules from it (where most are used only in one place)

Examples:

  • "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"

Requirements

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

Explicitness

  • 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

Control

  • 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

Adaptability

  • 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

See also