1 Software Architecture System

Preliminary Knowledge: The Evolution of Internet Architecture https://blog.csdn.net/ZGL_cyy/article/details/126330968

1.1 System and Subsystem

System : generally refers to a group composed of a group of related individuals, operating according to certain rules, and able to complete the work that individual components cannot do alone.

Relation : A system is composed of a group of related individuals, and unrelated individuals cannot form a system. For example, putting together a car engine and a bunch of apples cannot be called a system. Only by combining the engine, chassis, tires, and frame can it become a car and form a system.
Rules : Individuals in the system need to operate according to specified rules, rather than individual individuals acting independently. The rules stipulate the way of individual division of labor and cooperation in the system. For example, a car engine is responsible for generating power, which is then output to the wheels through the transmission and drive shaft to drive the car forward.
Ability : There is an essential difference between system ability and individual ability. System ability is not the sum of individual abilities, but a new ability. For example, a car can carry a load forward, but the engine, transmission, drive shaft, and wheels themselves do not have this ability.

Subsystem : A subsystem is also a system consisting of a group of related individuals, most likely part of a larger system. The definition of a subsystem is the same as the definition of a system, but the angle of observation is different. A system may be a subsystem of another larger system.

Take WeChat as an example to do an analysis:

WeChat itself is a system, including subsystems such as chat, login, payment, and circle of friends.
The circle of friends system also includes subsystems such as updates, comments, and likes.
Comments This system may include anti-brush subsystem, audit subsystem, release subsystem, and storage subsystem.
The comment review subsystem no longer includes subsystems in the business sense, but includes various modules or components, which are also systems in another dimension. For example, MySQL, Redis, etc. are storage systems, but not business subsystems

1.2 Modules, components, services

Module : is a consistent and closely related software organization. It includes two parts of program and data structure respectively. Modern software development often uses modules as the unit of composition
Components : Self-contained, programmable, reusable, language-independent software units that can be easily used to assemble applications

Modules and components are all part of the system, but the system is disassembled from different angles. For example:

After splitting the system from a logical point of view, the obtained units are "modules" ; after splitting the system from a physical point of view, the obtained units are "components" .
The main purpose of dividing modules is separation of responsibilities; the main purpose of dividing components is unit reuse.

For example, if we want to create a student information management system, this system can be split from a logical point of view and can be divided into: login registration module, personal information module, and personal achievement module; split from a physical point of view, it can be split into applications , Nginx, Web Server, MySQL, etc.

**Services: **Services and components have a certain similarity: they will be used by external applications. The biggest difference between the two is that components are used locally (such as Jar files); while services are running and used remotely through synchronous or asynchronous remote interfaces (such as RESTFul interfaces, web services, message systems, RPC, or socket)

A service is a form that can run independently and provide functions externally. It is possible to decompose a complex project into multiple services. When a certain service hangs up, it will not bring down the entire system. If there is no service, every time a new function is added to the system, it will affect all functions; if service is adopted, each service is only responsible for its upstream and downstream services.

insert image description here

1.3. Software Architecture System

insert image description here

2 Architecture Principles

2.1 Decoupling

In software engineering, coupling refers to dependencies between objects. The higher the coupling between objects, the higher the maintenance cost. Objects should therefore be designed to minimize the coupling between classes and components. In software design, the degree of coupling and cohesion are usually used as the standard to measure the degree of module independence. One criterion for dividing modules is high cohesion and low coupling.

Coupling exists in various fields, not unique to software design. In theory, absolute zero coupling is impossible, but some methods can be used to minimize coupling. Reducing the degree of coupling can be understood as decoupling. The core idea of decoupling in design is [independent and independent of each other].

2.2 Layering

Hierarchical structure is the most popular and widely used design method of application software. In a system with a layered structure, each subsystem is organized in a hierarchical form, and the upper layer uses various services of the lower layer, while the lower layer knows nothing about the upper layer. Each layer hides the details of the layers below it from the layer above it.

Classic three-tier architecture :

In the software architecture, the classic three-tier architecture consists of the user interface layer, business logic layer, and data access layer from top to bottom. In the era when this layered architecture was proposed, most systems were often relatively simple, essentially a single-architecture database management system. This layered architecture effectively isolates business logic and data access logic, enabling these two different concerns to evolve relatively freely and independently. The classic three-tier architecture looks like this:

insert image description here

The design principle of layering is: to ensure that the components of the same layer are at the same abstraction level . This is the so-called "single level of abstraction principle". This principle can be applied to layered architectures. For example, as shown in the figure below:

insert image description here

2.3 Packaging

Suppose we have a program that logically has some different objects, and these objects communicate with each other.

Within a class, encapsulation is achieved when the state of each object is kept relatively isolated . Other objects cannot observe the state of this object. All they can do is call some generic functionality called "methods".

Therefore, the object uses methods to control its own state, and no one else can touch it unless explicitly allowed. If you want to communicate with an object, you need to use the methods provided. But by default, you cannot change the state of an object.

3 Architectural Approaches

The architectural diagram is to represent the overall outline of the software system, the interrelationships and constraint boundaries among various components, as well as the overall view of the physical deployment of the software system and the evolution direction of the software system. In order for stakeholders to understand and follow architectural decisions, it is necessary to convey architectural information, and architectural diagrams are a good carrier. Different perspectives and roles have different focuses, and the architecture diagrams seen are different.