I am Lao Wen, an embedded engineer who loves learning.
Follow me to become better together!
A pattern is a solution to a problem in a specific context.
In general, there are mainly these 7 architectural patterns:
-
Layered Architecture
-
Multi-layer Architecture
-
Pipe/Filter Architecture
-
Client/Server Architecture
-
Model/View/Controller Architecture
-
Event-Driven Architecture
-
Microservices Architecture
1Layered Architecture Pattern
Most software architects, designers, and developers are very familiar with this architectural pattern. Although there are no specific restrictions on the number and types of layers, most layered architectures consist of four layers: presentation layer, business layer, persistence layer, and database layer, as shown in the figure below.
A popular n-tier architecture example2 Problem
3 Solution
To achieve separation of concerns, the layered pattern divides software into various units (called “layers”). Each layer is a set of modules that provides a set of highly cohesive services. Its usage must be one-way. Layers group software as a complete partition, with each partition exposing a public interface.
-
The first concept is that each layer has specific roles and responsibilities. For example, the presentation layer is responsible for handling all user interfaces. This separation of concerns in layered architecture makes it very simple to build efficient roles and responsibilities.
-
The second concept is that the layered architecture pattern is a technical partition architecture, not a domain partition architecture. They are composed of components, not domains.
-
The final concept is that each layer in a layered architecture is marked as closed or open. A closed layer means that requests moving from one layer to another must pass through the layer immediately below it to reach the next lower layer. Requests cannot skip any layers.
Closed layers and request access
Layering also increases the upfront costs and complexity of the system.
2Multi-layer Pattern
A multi-layer pattern example: Consumer website J2EEUsed in distributed systems.
3Pipe and Filter Architecture
Pipe-filter pattern
Many systems need to transform discrete data flows from input to output. Many types of transformations frequently occur in practice, so it is ideal to create them as independent, reusable parts.
These systems need to be divided into reusable, loosely coupled components, with simple, common interaction mechanisms between components. This allows them to flexibly combine with each other. These loosely coupled components are easy to reuse. Those independent components can execute in parallel.
In this pattern, there are four types of filters.
-
producer (source): the starting point of a process.
-
transformer (map): transforms some or all data.
-
tester (reduce): tests one or more conditions.
-
consumer (sink): the endpoint.
Excessive parsing and un-parsing can lead to performance loss and increase the complexity of writing the filters themselves.
Compilers: continuous filters perform lexical analysis, syntax analysis, semantic analysis, and code generation.
4Client-Server Architecture
Many distributed clients want to access a large number of shared resources and services, and we want to control access or service quality.
By managing a set of shared resources and services, we can improve modifiability and reusability by breaking down common services and modifying them in a single location or a few locations. We want to improve scalability and availability by concentrating control of these resources and services while distributing the resources themselves across multiple physical servers.
In the client-server model, components and connectors have specific behaviors.
The server component receives the client’s request and sends a reply back to it.
The server can become a performance bottleneck and a single point of failure.
Decisions about functional locations (whether on the client or server) are often complex and have high variable costs after the system is built.
5 Uses
For systems with many components (clients) sending requests to other components (servers) providing services, we can use the client-server model to model part of this system: online applications, such as email, shared documents, or banking services.
5Model-View-Controller Architecture (MVC)
1 Context
The user interface is often the most frequently modified part of an interactive application. Users often want to view data from different perspectives, such as bar charts or pie charts. These representations should reflect the current state of the data.
2 Problem
How do user interface functions operate independently of application functions while still responding to changes in user input or underlying application data?
When underlying application data changes, how do we create, maintain, and coordinate multiple views of the user interface?
3 Solution
The model-view-controller (MVC) pattern divides application functionality into three types of components:
-
Model, which contains the application data.
-
View, which displays part of the underlying data and interacts with the user.
-
Controller, which mediates between the model and the view and manages notifications of state changes.
4 Weaknesses
For simple user interfaces, the complexity may not be worth it.
The model, view, and controller abstractions may not be suitable for certain user interface toolkits.
5 Uses
MVC is a commonly used architectural pattern for developing user interfaces for websites or mobile applications.
6Event-Driven Architecture
1 Context
It is necessary to provide computing and information resources to handle incoming independent asynchronous events generated by applications, which can scale with increasing demand.
2 Problem
Building a distributed system that can service asynchronously arriving event-related information and can scale from simple small systems to complex large ones.
3 Solution
Deploy independent event processes or processors for event handling. Incoming events enter a queue. The scheduler pulls events from the queue based on scheduling policies and assigns them to appropriate event processors.
4 Weaknesses
Performance and error recovery can be issues.
5 Uses
For example, an ecommerce application using this pattern would work as follows:
The Order Service creates an Order, which is in a pending state, then publishes an<span>OrderCreated</span> event.
-
The Customer Service receives this event and tries to deduct credit for this Order. It then publishes either a Credit Reserved event or
<span>CreditLimitExceeded</span>(exceeding credit limit) event. -
The Order Service receives the event sent by Customer Service and changes the order status to approved or canceled.
Deploy server-based enterprise applications that support various browsers and native mobile clients. The application processes client requests by executing business logic, accessing databases, exchanging information with other systems, and returning responses. This application may expose a third-party API.
2 Problem
Integrated applications can become too large and complex to be effectively supported and deployed to achieve optimal distributed resource utilization, such as in cloud environments.
3 Solution
Build the application as a suite of services. Each service is independently deployable and scalable, with its own API boundaries. Different services can be written in different programming languages, manage their own databases, and be developed by different teams.
Of course, we also need more money.
Many use cases can apply microservices architecture, especially those involving large data pipelines. For example, a microservices system for reporting on a company’s retail store sales would be ideal. Each step in the data presentation process would be handled by a microservice: data collection, cleaning, normalization, condensation, aggregation, reporting, etc.
Source: The content is from the internet, and the copyright belongs to the original author. If there is any infringement, please contact for deletion.
-END-