Architecture pattern is a general reusable solution to common problems in software architecture in a given context.
- A pattern is a solution to a problem in a specific context.
In general, there are mainly the following seven architecture modes:
- Layered architecture
- Multi-tier architecture
- Pipeline-filter architecture
- Client-server architecture
- Model-View-Controller Architecture
- Event-driven architecture
- Microservice architecture
1. Layered architecture model
- The most common architecture pattern is the layered architecture or n-tier architecture.
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 are mainly composed of four layers: presentation layer, business layer, persistence layer, and database layer, as shown in the following figure.
n-tier architecture example
1. Context
All complex systems experience the need to develop and evolve each part of the system independently. For this reason, system developers need to have a clear and coherent separation of concerns so that each module of the system can be independently developed and maintained.
2. The problematic
software needs to be divided in such a way: each module can be developed and derived independently, the interaction between the respective parts is very small, and it supports portability, modifiability and reusability.
3. Scheme
In order to achieve separation of concerns, the layered model divides the software into units (called "layers"). Each layer is a set of modules, providing a set of highly cohesive services. Its use must be one-way. The layer treats a group of software as a complete partition, and each partition exposes 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 of the layered architecture makes it very simple to build efficient roles and responsibilities.
- The second concept is that the layered architecture model is a technical partition architecture, rather than a domain-based partition architecture. They are composed of components, not domains.
- The last concept is that each layer in the layered architecture is marked as closed or open. A closed layer means that a request moves from one layer to another, and it must pass through the layer directly below it to reach the next layer below it. The request cannot skip any layers.
Closed layer and request access
4. Weaknesses
- Layering can cause performance degradation. This model is not suitable for high-performance applications, because the efficiency of implementing a business request through multiple layers in the architecture is not high.
- Layering will also increase the upfront cost and complexity of the system.
5. Purpose
- We should apply this approach to small and simple applications or websites. This is a good choice for scenarios where budget and time are very tight.
2. Multilayer mode
1. Context
- In a distributed deployment, it is usually necessary to divide the system infrastructure into different subsets.
2. Problem
- How do we divide the system into multiple computationally independent execution structures: software and hardware groups connected by some communication media?
3. Scheme
- The execution structure of many systems is organized into a series of logical groupings. Each group is called a layer.
Example of multi-layer mode
4. Weaknesses
- A lot of upfront cost and complexity.
5. Purpose
- Used in distributed systems.
3. Pipeline-filter architecture
- A recurring pattern in software architecture is the pipe-filter pattern.
Pipe filter mode
1. Context
- Many systems need to convert discrete data streams from input to output. Many type conversions are repeated in practice, so it is ideal to create them as independent reusable parts.
2. Problem
- These systems need to be divided into reusable loosely coupled components, with simple and common interaction mechanisms between components. In this way they can be flexibly combined with each other. These general loosely coupled components are easy to reuse. Those independent components can be executed in parallel.
3. Scheme
The pipes in this architecture constitute the communication channel between the filters. The first concept is that for performance reasons, each pipeline is non-directional and point-to-point, accepting input from one source and often directly outputting to another source.
In this mode, there are the following four filters:
- producer (source): the starting point of a process
- transformer (map): transform some or all data
- tester (reduce): test one or more conditions
- consumer (sink): end point
4. Weaknesses
- Not suitable for interactive systems because of their conversion characteristics.
- Excessive parsing and de-analysis will lead to performance loss and increase the complexity of writing the filter itself.
5. Purpose
- Pipeline-filter architecture is used in various applications, especially to simplify single processing tasks, such as EDI, ETL tools.
- Compiler: Continuous filters perform lexical analysis, syntax analysis, semantic analysis, and code generation.
4. Client-filter architecture
1. Context
- There are many shared resources and services that a large number of distributed clients want to access, and we want to control access or service quality.
2. Problem
By managing a set of shared resources and services, we can improve modifiability and reusability by decomposing common services and modifying them in a single location or a few locations. We want to increase scalability and availability by centrally controlling these resources and services while distributing the resources themselves on multiple physical servers.
3. Scheme
- In the client-server model, components and connectors have specific behaviors.
- The component called "client" sends the request to the component called "server" and then waits for a reply.
- The server component receives the client's request and sends a reply to it.
4. Weaknesses
- The server becomes a performance bottleneck and a single point of failure location.
- After the system is built, the decision about the functional location (on the client side or on the server) is usually complex and costly to change.
5. Purpose
For a system that has many components (clients) sending requests to other service-providing components (servers), we can use the client-server model to model part of the system: online applications, such as e-mail, shared documents, or Banking services.
5. Model-View-Controller Architecture (MVC)
1. Context
The user interface is usually the most frequently modified part of an interactive application. Users usually 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 can user interface functions be independent of application functions, while still responding to user input or changes to underlying application data?
- How to create, maintain, and coordinate multiple views of the user interface when the underlying application data changes?
3. Scheme
The model-view-controller (MVC) pattern divides application functions into the following three types of components:
- The model contains the data of the application.
- View, which displays part of the underlying data and interacts with the user.
- The controller mediates between the model and the view and manages notifications of state changes.
4. Weaknesses
- For simple user interfaces, the complexity is not worth it.
- The model, view, and controller abstractions may not be applicable to some user interface toolkits.
5. Purpose
- MVC is an architecture pattern commonly used in the development of user interfaces for websites or mobile applications.
6. Event-driven architecture
1. Context
- It is necessary to provide computing and information resources to process independent asynchronous events generated by incoming applications. This approach can be expanded as demand increases.
2. Problem
- Build a distributed system that can serve information about events that arrive asynchronously, and can scale from simple and small to complex and large.
3. Scheme
- Deploy independent event processes or handlers for event processing. The arriving event enters the queue. The scheduler pulls events from the queue according to the scheduling strategy and assigns them to the appropriate event handlers.
4. Weaknesses
- Performance and error recovery may be the problem.
5. Purpose
The e-commerce application using this program will work as follows:
- The Order Service creates an Order, which is in a pending state, and then publishes an OrderCreated event.
- Customer Service receives this event and tries to deduct credit for this Order. Then issue a Credit Reserved event or CreditLimitExceeded (credit limit exceeded) event.
- The Order Service receives the event sent by the Customer Service and changes the order status to approved or cancelled.
7. Microservice architecture
1. Context
Deploy server-based enterprise applications to 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 will become too large and complex to be effectively supported and deployed to achieve optimal utilization of distributed resources, such as in a cloud environment.
3. Scheme
Build the application into a service suite. Each service is independently deployed and extensible, with its own API boundary. Different services can be written in different programming languages, manage their own databases, and developed by different teams.
4. Weaknesses
- The system design must be able to tolerate service failures and requires more system monitoring. Service orchestration and event collaboration are expensive.
- Of course, we still need more money.
5. Purpose
Microservice architecture can be applied to many usage scenarios, especially those involving large data pipelines. For example, a microservice system would be ideal for a reporting system about a company’s retail store sales. Each step of the data presentation process will be processed by a microservice: data collection, cleaning, standardization, enrichment, aggregation, reporting, etc.