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

This article mainly explains "what are the software architecture patterns that software architecture programmers need to know". The explanation in this article is simple and clear and easy to learn and understand. let's study and learn "what software architecture patterns software architecture programmers need to know"!

Architecture pattern is a general and reusable solution to common problems in software architecture in a given context.

Patterns are the solution to the problem in context.

Today, many programmers are still confused or even unaware of the differences between architectural patterns.

Let me explain to you... !

Hierarchical architecture

Pipes and filters

Client server

Model view controller

Event-driven architecture

Micro-service architecture

Hierarchical architecture

The most common architectural pattern is a hierarchical architecture, or n-tier architecture. Most software architects, designers, and developers are well known. Although there are no special restrictions on the number and type of layers that must exist, most hierarchical architectures consist of four layers: presentation, business, persistence, and database, as shown below.

> an popular example of n-tier architecture

Context

All complex systems need to develop and evolve each part of the system independently. For this reason, the developers of the system need a clear and documented separation of concerns so that the modules of the system can be developed and maintained independently.

problem

The software needs to be segmented so that modules can be developed and developed independently, and there is little interaction between the parts, thus supporting portability, modification and reusability.

Solution

In order to achieve the separation of concerns, the hierarchical model divides the software into units called layers. Each layer is a set of modules that provide a tight set of services. Usage must be one-way. The layer completely partitions a set of software, and each partition is exposed through a public interface.

The first concept is that each layer has specific roles and responsibilities. For example, the presentation layer will be responsible for handling all UI. Because the separation of concerns within a hierarchical architecture makes it easy to establish effective roles and responsibilities.

In the second concept, the hierarchical architecture pattern is the architecture of technology partitioning, not the architecture of domain partitioning. They are component groups, not by domain.

The final concept is that each layer in a hierarchical architecture is marked as closed or open. A closed layer means that a request is moved from one layer to another, and it must pass through the layer below it to reach the next layer below it. The request cannot skip any layers. > Closed layers and request access

weakness

Layers can cause performance degradation. This pattern cannot apply itself to high-performance applications because it is not efficient to traverse multiple layers of the architecture to meet business requests.

The addition of layers also increases the upfront cost and complexity of the system.

Usage

For small, simple applications or websites, we should use this style. This is a good choice for budget and time constraints.

Multi-layer mode

Context

In distributed deployment, it is usually necessary to distribute the infrastructure of the system into different subsets.

problem

How do we divide the system into computationally independent execution structures: software and hardware groups connected through some communication media?

Solution

> a multi-tier example-consumer website J2EE

The executive structures of many systems are organized into logical groupings of components. Each packet is called a layer.

weakness

A lot of upfront cost and complexity.

Usage

For distributed systems.

Pipes and filters

One pattern in the recurring software architecture is the pipeline filter pattern.

> the pipe filter style

Context

Many systems are required to convert streams of discrete data items from input to output. In fact, many types of conversions occur repeatedly, so you need to create them as separate, reusable parts.

problem

Such systems need to be divided into reusable, loosely coupled components with simple, general interaction mechanisms. In this way, they can be flexibly combined with each other. General-purpose and loosely coupled components are easy to reuse. Independent components can be executed in parallel.

Solution

The pipes in this architecture form a communication channel between filters. The first concept is that each pipe is non-directional and point-to-point for performance reasons, accepting input from one source and always directing output to another.

There are four types of filters in this style, as shown below.

Producer (source): the starting point of the process.

Converter (mapping): performs conversion on some or all of the data.

Tester (reduction): test one or more conditions.

Consumer (recipient): destination.

weakness

Because of the conversion characteristics of the interactive system, it is not a good choice.

Too much parsing and unparsing can lead to performance losses and increase the complexity of writing the filter itself.

Usage

The pipeline filter architecture is used in a variety of applications, especially tasks that facilitate simple one-way processing, such as EDI,ETL tools.

Compiler: continuous filters perform lexical analysis, parsing, semantic analysis, and code generation.

Client server

Context

There are many shared resources and services that distributed clients want to access, and we want to control them to control access or quality of service.

problem

By managing a set of shared resources and services, we can improve modifiability and reusability by excluding common services and having to modify them in a single location or a few locations. We want to improve scalability and availability by centrally controlling these resources and services while allocating resources themselves across multiple physical servers.

Solution

In the client-server style, components and connectors have specific behavior.

A component called a client sends a request to a component called a server and waits for a reply.

The server component receives a request from the client and sends a reply to it.

weakness

The server may be a performance bottleneck and a single point of failure.

After the system is built, decisions about where to locate functionality (on the client or on the server) are often complex and costly to change.

Usage

We can use the client-server style to model part of a system that has many components that send requests (clients) to another component (server) that provides services: online applications, such as e-mail, document sharing and banking.

Model View Controller MVC

Context

The user interface is usually the most frequently modified part of an interactive application. Users usually want to view the data from different angles, such as bar charts or pie charts. These representations should reflect the current state of the data.

problem

How do you distinguish user interface functions from application functions, and how do you respond to changes in user input or underlying application data?

How do I create, maintain, and coordinate multiple views of the user interface when the underlying application data changes?

Solution

The Model View Controller (MVC) pattern divides the application functions into the following three components.

A model that contains data for the application.

View that displays parts of the underlying data and interacts with the user.

The controller mediates between the model and the view and manages notification of state changes.

weakness

For a simple user interface, complexity may not be worth it.

Abstractions of models, views, and controllers may not apply to some user interface toolkits.

Usage

MVC is an architectural pattern that is typically used for Web mobile applications when developing user interfaces.

Event-driven architecture

Context

Computing and information resources need to be provided to handle events generated by incoming independent asynchronous applications in a manner that can be expanded as requirements increase.

problem

Build a distributed system that can serve asynchronous arrival messages associated with events, and the distributed system can scale from small and simple to large and complex.

Solution

Deploy a separate event flow / handler for event handling. Arrival event queue. The scheduler extracts events from the queue and assigns them to the appropriate event handlers according to the scheduling policy.

weakness

Performance and error recovery can be a problem.

Usage

E-commerce applications that use this method will work as follows: the order service creates an order in a pending state and publishes an OrderCreated event.

Customer Service receives the event and attempts to keep credit for the order. It then issues a "keep credit" event or a "CreditLimitExceeded" event.

The order service receives events from customer service and changes the order status to approved or cancelled

Micro-service architecture

Context

Deploy server-based enterprise applications that support multiple browsers and native mobile clients. The application processes client requests by executing business logic, accessing the database, exchanging messages with other systems, and returning responses. The application may expose a third-party API.

problem

The overall application may become too large and complex to support effectively, while deployment cannot achieve optimal distributed resource utilization, such as in a cloud environment.

Solution

Build the application as a service suite. Each service can be deployed and extended independently and has its own API boundary. You can write different services in different programming languages, manage your own databases, and be developed by different teams.

weakness

The system must be designed to withstand service failures that require more system monitoring. Service choreography and event collaboration overhead.

We need more memory.

Usage

Many use cases apply to micro-service architectures, especially those that involve a large number of data pipelines. For example, a micro-service-based system is well suited to a company's retail store sales reporting system. Each step of the data preparation process will be handled by microservices: data collection, cleaning, normalization, enrichment, summarization, reporting, etc.

Thank you for your reading. the above is the content of "what software architecture patterns software architecture programmers need to know". After the study of this article, I believe you have a deeper understanding of the software architecture patterns that software architecture programmers need to understand, and the specific usage still needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.