Architectural patterns are general reusable solutions to common problems in software architecture within a given context.

Click on the “Embedded Application Research Institute” above and select “Top/Star Public Account“

Valuable resources delivered instantly!

Author | C Language Programming Learning Base

Organizer | Embedded Application Research Institute

A pattern is a solution to a problem in a specific context.

However, many developers still struggle to understand the differences between various software architectural patterns, and some know very little about them.

Generally, there are seven main architectural patterns:

① Layered Architecture

② Multi-layer Architecture

③ Pipe-Filter Architecture

④ Client-Server Architecture

⑤ Model-View-Controller Architecture

⑥ Event-Driven Architecture

⑦ Microservices Architecture

1. Layered Architecture Pattern

The most common architectural pattern is the layered architecture, also known as n-tier architecture.

Most software architects, designers, and developers are very familiar with this architectural pattern. Although there is no specific limit to the number and type of layers, most layered architectures consist of four layers: presentation layer, business layer, persistence layer, and database layer, as shown in the figure below:

1. Context

All complex systems need to independently develop and evolve various parts of the system. For this reason, system developers need to clearly and systematically separate concerns so that the various modules of the system can be developed and maintained independently.

2. Problem

Software needs to be segmented in such a way that each module can be developed and evolved independently, with minimal interaction between their parts, supporting portability, modifiability, and reusability.

3. Solution

To achieve separation of concerns, the layered pattern divides software into individual units (called “layers”). Each layer is a set of modules that provide a set of highly cohesive services. Their usage must be unidirectional. Layers treat a group of 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 easy to build efficient roles and responsibilities.

✪ The second concept is that the layered architectural pattern is a technical partitioning architecture rather than a domain partitioning architecture. They are composed of components, not domains.

✪ The final concept is that each layer in a layered architecture is marked as either closed or open. A closed layer means that a request moving from one layer to another must pass through the layer immediately below it to reach the next layer below. Requests cannot skip any layers.

4. Weaknesses

Layering can lead to performance degradation. This pattern is not suitable for high-performance applications, as the efficiency of fulfilling a business request through multiple layers in the architecture is not high.

Layering also increases the upfront costs and complexity of the system.

5. Uses

We should apply this method to small, simple applications or websites. It is a good choice for scenarios with very tight budgets and timelines.

2. Multi-layer Pattern

Solution:

Many systems’ execution structures are organized into a series of logically grouped components. Each group is called a layer.

1. Context

In a distributed deployment, it is often necessary to partition the system’s infrastructure into different subsets.

2. Problem

How do we split the system into multiple independently executing structures: groups of software and hardware connected by some communication media?

3. Weaknesses

High upfront costs and complexity.

4. Uses

Used in distributed systems.

3. Pipe-Filter Architecture

A recurring pattern in software architecture is the pipe-filter pattern.

1. Context

Many systems need to transform discrete data streams from input to output. Many types of transformations recur 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 common interaction mechanisms between components. This way, they can flexibly combine with each other. These common loosely coupled components can be easily reused. Independent components can execute in parallel.

3. Solution

The pipes in this architecture form communication channels between filters. The first concept is that, for performance reasons, each pipe is undirected and point-to-point, accepting input from one source and often directly outputting to another source.

In this pattern, there are four types of filters.

✪ producer (source): the starting point of a process.

✪ transformer (map): transforms some or all of the data.

✪ tester (reduce): tests one or more conditions.

✪ consumer (sink): the endpoint.

4. Weaknesses

Not very suitable for interactive systems due to their transformational nature.

Excessive parsing and un-parsing can lead to performance loss and increase the complexity of writing the filters themselves.

5. Uses

The pipe-filter architecture is used for various applications, particularly for simplifying single-direction processing tasks, such as EDI and ETL tools.

Compilers: consecutive filters perform lexical analysis, syntax analysis, semantic analysis, and code generation.

4. Client-Server Architecture

1. Context

Many shared resources and services are desired by a large number of distributed clients, 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 one place or a few places. We want to improve scalability and availability by centrally controlling these resources and services while distributing the resources themselves across multiple physical servers.

3. Solution

In the client-server pattern, components and connectors have specific behaviors.

The component called “client” sends requests to the component called “server” and then waits for a reply.

The server component receives the client’s request and sends a reply back to it.

4. Weaknesses

The server can become a performance bottleneck and a single point of failure.

After the system is built, decisions about functional locations (on the client or on the server) are often complex and have high change costs.

5. Uses

For systems with many components (clients) sending requests to other components (servers) providing services, we can use the client-server pattern to model part of this system: online applications, such as email, shared documents, or banking services.

5. Model-View-Controller Architecture (MVC)

1. Context

The user interface is often the most frequently modified part of an interactive application. Users generally 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 the user interface functionality be independent of the application functionality while still responding to changes in user input or underlying application data?

When the underlying application data changes, how can 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 might not be worth it.

The abstractions of model, view, and controller may not apply to certain user interface toolkits.

5. Uses

MVC is a commonly used architectural pattern for developing user interfaces for websites or mobile applications.

6. Event-Driven Architecture

1. Context

It is necessary to provide computing and information resources to handle incoming application-generated independent asynchronous events, which can scale with increasing demand.

2. Problem

Building distributed systems that can service asynchronously arriving event-related information and scale from simple small to complex large.

3. Solution

Deploy independent event processes or handlers for event processing. Incoming events enter a queue. The scheduler pulls events from the queue according to the scheduling policy and assigns them to the appropriate event handlers.

4. Weaknesses

Performance and error recovery may be issues.

5. Uses

Using this pattern, e-commerce applications would work as follows:

Order Service creates an Order, which is in a pending state, and then publishes an OrderCreated event.

✪ Customer Service receives this event and attempts to reserve credit for this Order. Then it publishes a Credit Reserved event or CreditLimitExceeded event.

✪ Order Service receives the event sent by Customer Service and changes the order status to approved or canceled.

7. Microservices Architecture

1. Context

Deploy server-based enterprise applications supporting 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 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 boundary. Different services can be written in different programming languages, manage their own databases, and be developed by different teams.

4. Weaknesses

The system design must tolerate service failures and requires more system monitoring. Service orchestration and event collaboration overhead can be significant.

Of course, we also need more money.

5. Uses

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.

Copyright Statement:This article is sourced from the internet, sharing knowledge for free, and the copyright belongs to the original author. If there are copyright issues, please contact me for deletion.

Previous Highlights

Understand what software architecture is in seconds!

Smart instrument embedded system architecture design

Amazing! These embedded program architectures are very useful

These three elegant embedded software architectures are worth having!

Embedded system software architecture design (long in-depth article)

If you find this article helpful, please click [Read] and share it, which is also a support for me.