Shulou(Shulou.com)06/03 Report--

This article mainly introduces "what is the importance of software architecture". In daily operation, I believe many people have doubts about the importance of software architecture. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "what is the importance of software architecture?" Next, please follow the editor to study!

Software development can be described as a complex system process, which requires expertise in various technical areas and related business. Like the blueprint of the master plan, components of this software development process can be promoted by defining the architecture of the software.

Why do we need software architecture?

> Big Ball of Mud

Early developers used to design software without architecture, which at first seemed to have the advantage of no planning overhead and faster prototyping. But as they got deeper into the process, the software became as rigid and unmanageable as a muddy ball. As the cost of each change became higher and higher, this method was later called "mud ball" (Big Ball of Mud).

Over time, such projects become difficult to manage, so each new iteration greatly increases maintenance costs. This limits the development of the software beyond the scope originally defined at the beginning of the project.

In the development of software design for many years, developers have put forward some robust architecture methods to avoid software design problems with less architecture (also known as "muddy ball"). Here are some of the most famous

Hierarchical architecture

Multi-tier architecture

Service oriented Architecture (SOA)

Micro-service architecture

Hierarchical architecture

This method is based on the principle of separation of concerns. Software design is divided into overlapping layers. Each layer has a special responsibility. The architecture divides the software into the following layers

Presentation layer

Business logic layer

Data link layer

The presentation layer has a user interface that interacts with the outside world. This is also responsible for providing the user experience, as this is the only layer exposed to end-user interaction.

As the name implies, the business logic layer contains the business logic of software applications. This layer separates UI / UX from business-related computing, providing the flexibility to modify logic based on changing business requirements without affecting other layers.

The data link layer is responsible for interacting with persistent storage such as databases and for domain-independent miscellaneous data processing (that is, business-independent).

Data and control flow from each layer of the design to another. These layers also add abstraction to the design. Because the stability is directly proportional to the abstraction to a certain extent, it also improves the stability of the software to a certain extent.

> Layered Representation of Architecture

Benefits:

Compared with other methods, it is easier to implement

Provide abstraction due to separation of concerns between layers

The isolation between layers protects other layers from modification by one layer.

Due to low coupling, the software becomes easier to manage

Disadvantages:

There is not much scalability

Software built in this way will tend to have a monomer structure that is not easy to modify.

Even if it is not necessary to transfer data from some layers, the data must flow out of another layer at a time. This problem is called the "sewage pool problem".

Multi-tier architecture

This architecture method divides the software suite into several layers according to the principle of client-server communication. The architecture can have one or two layers in an n-tier system, separating the responsibilities between the data provider and the consumer.

It uses the request response pattern to communicate between defined layers. Unlike a hierarchical architecture, it provides scalability either horizontally (extending the network through high-performance nodes) or vertically (extending each node by improving individual performance)

Single layer system

In this approach, a single system can act as both a client and a server, and can simplify deployment without the need for inter-system communication (ISC). Therefore, a good communication speed is provided.

Such a system is only suitable for small-scale single-user applications, not for complex multi-user applications.

Two-tier system

> 2-Tiered Architecture

Such a system consists of two physical machines, a server and a client. It provides data management operations and isolation between data processing and presentation operations.

Customers have presentation, business logic and data link layers.

The server stores data, such as a database

3-tier / n-tier system

> 3-Tiered Architecture

Such an architecture is highly scalable both horizontally and vertically. In general, implementing an n-tier architecture is expensive, but can provide high performance. Therefore, it is the first choice in large and complex software solutions.

It can be combined with advanced service-oriented architecture styles to generate highly complex models. This architecture is recommended when the software is complex and requires performance and scalability, as it may be a more expensive approach in terms of resources and time.

Service-oriented architecture

SOA is a service-based architecture model in which components and applications communicate using well-defined services.

It consists of five elements, namely:

Service

Service bus

Service library service catalog

SOA security

SOA governance

The client sends requests over the network using standard protocols and data formats. This request processed by ESB can be regarded as the core of SOA. ESB is responsible for orchestration and routing. ESB uses the service repository to direct requests to dedicated services. The dedicated service can interact with other services or databases to form a response payload (response data).

The complete request response call complies with SOA governance and security rules to complete transactions that ensure security and correctness.

> https://www.udemy.com/course/software-architecture-and-design-essentials/

There are usually two types of services:

Atomic services: provide features that cannot be further decomposed

Composite services: a collection of atmospheric services to provide complex composite functions

Types of services:

Services can be of the following types, namely:

Physical service

Domain service

Public utility service

Integrated service

Apply for service

Security service

Micro-service architecture

The microservice architecture is described according to the definition provided by Martin Fowler in an article written in 2014.

In short, the microservice architecture style is a way to develop a single application into a set of small services, each of which runs in its own process and communicates with lightweight mechanisms (usually HTTP resource API). These services are built around business functions and can be deployed independently by a fully automated deployment mechanism. There is little centralized management of these services, which can be written in different programming languages and use different data storage technologies.

It is based on the principle of service componentization. This architecture decomposes the software into various components that can be defined as services. Each service has a single responsibility, and each service is isolated in nature. Changes to one service should not affect other services.

> https://divante.com/blog/monolithic-architecture-vs-microservices/

What does microservice include?

An architectural combination of isolated, concise and fine-grained micro-services that can be extended independently.

The architecture consists of five parts, as follows:

Service

Service bus

External configuration

API Gateway

Container

Characteristics of microservices

The microservice architecture should include the following characteristics:

Componentization through services

Organize around business capabiliti

Product is not a project

Smart endpoints and dumb pipes

Decentralized governance

Decentralized data management

Infrastructure automation

A failed design

Evolutionary design

It is recommended to develop different microservices with different teams and allow each microservice to evolve over time, just like bubbles in the air. Because data communication is carried out in accordance with standard protocols and data formats, the structure of a service does not affect functions in common services.

> Comparison of different architectures

Benefits:

Provides low coupling due to high isolation

Enhanced modularization

Failures in one service do not affect the entire system because they are isolated

Provide a high degree of flexibility

Provide a high degree of scalability

Easy to modify can accelerate the speed of evolutionary iteration

Better error handling can be achieved.

Avoid the problem of layers of architecture and data flow only through related services

Disadvantages:

Different services are more likely to fail when communicating with each other.

It is difficult to manage a large number of services.

Issues that need to be addressed, such as network latency and load balancing and other similar distributed architecture issues

Complex testing in distributed Environment

Implementation will take more time

At this point, the study of "what is the importance of software architecture" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.