Embedded software may experience coupling between drivers and applications due to hardware resource limitations. However, for large projects with ample resources, complex business logic and the need for future expansion and maintenance necessitate the adoption of layered and modular thinking, which is the essence of architectural patterns.
-
Layered Architecture -
Multi-tier Architecture -
Pipeline-Filter Architecture -
Client-Server Architecture -
Model-View-Controller Architecture -
Event-Driven Architecture -
Microservices Architecture
01
Layered Architecture Pattern
The most common architectural pattern is the layered architecture, which typically consists of four layers: presentation layer, business layer, persistence layer, and database layer, as shown below:
1. Context
Complex systems often experience independent development and evolution of various parts. For this reason, system developers need to clearly and logically separate concerns so that each module of the system can be developed and maintained independently.
2. Problem
Software needs to be divided in such a way that each module can be developed and evolved independently, with minimal interaction between parts, supporting portability, modifiability, and reusability.
3. Solution
To achieve separation of concerns, the layered pattern divides software into units called “layers.” Each layer is a set of modules that provides a cohesive set of services. Its usage must be one-way. A set of software is treated 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 construct efficient roles and responsibilities.
✪ The second concept is that the layered architecture pattern is a technical partitioning architecture rather than a domain partitioning architecture. They are composed of components rather than domains.
✪ The final concept is that each layer in the 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 directly below it to reach the next layer down. Requests cannot skip any layers.
4. Weaknesses
Layering can lead to performance degradation. This pattern is not suitable for high-performance applications because the efficiency of processing a business request through multiple layers of architecture is not high. It can also increase the upfront costs and complexity of the system.
5. Uses
This approach should be applied to small, simple applications.
02
Multi-tier Pattern
Many systems’ execution structures are organized into a series of logically grouped components. Each group is referred to as a layer.
1. Context
In a distributed deployment, it is often necessary to distribute the system’s infrastructure into different subsets.
2. Problem
How do we partition the system into multiple independently executing structures: software and hardware groups connected by some communication medium?
3. Weaknesses
High upfront costs and complexity.
4. Uses
Used in distributed systems.
03
Pipeline-Filter Architecture
A recurring pattern in software architecture is the pipeline-filter pattern.
1. Context
Many systems require conversion of 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, allowing them to flexibly combine with each other. These common loosely coupled components can be easily reused. Independent components can execute in parallel.
3. Solution
The pipelines in this architecture constitute the communication channels between filters. The first concept is that, for performance reasons, each pipeline is undirected and point-to-point, accepting input from a 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 data.
✪ tester (reduce): tests one or more conditions.
✪ consumer (sink): the endpoint.
4. Weaknesses
Not well-suited for interactive systems due to their transformational nature.
Excessive parsing and depParsing can lead to performance loss and increase the complexity of writing filters themselves.
5. Uses
The pipeline-filter architecture is used for various applications, especially for simplifying single-task processing.
04
Client-Server Architecture
1. Context
Many shared resources and services are desired by numerous distributed clients, hoping 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 or few locations. We aim to enhance scalability and availability by concentrating control over these resources and services while distributing them across multiple physical servers.
3. Solution
In the client-server model, components and connectors have specific behaviors.
The component called “client” sends requests to a component called “server” and then waits for a reply.
The server component receives the client’s request and sends a reply back.
4. Weaknesses
The server can become a performance bottleneck and a single point of failure.After the system is built, decisions about functionality locations (on the client or on the server) are often complex and have highchange costs.
5. Uses
For systems where many components (clients) send 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.
05
Model-View-Controller Architecture (MVC)
1. Context
The user interface is often the most frequently modified part of an interactive application. Users typically 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 functionality be independent of application functionality while still responding to user input or changes in underlying application data?
When underlying application data changes, how can multiple views of the user interface be created, maintained, and coordinated?
3. Solution
The Model-View-Controller (MVC) pattern divides application functionality into three types of components:
✪ Model, which contains the application’s data.
✪ View, which displays some 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 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.
06
Event-Driven Architecture
1. Context
There is a need to provide computing and information resources to process incoming application-generated independent asynchronous events, which can scale with increased demand.
2. Problem
Building distributed systems that can serve asynchronously arriving event-related information and can scale from simple small systems to complex large ones.
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 scheduling policies and assigns them to the appropriate event handlers.
4. Weaknesses
Performance and error recovery can be problematic.
5. Uses
eCommerce applications using this model 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 either a Credit Reserved event or a CreditLimitExceeded event.
✪ Order Service receives the event sent by Customer Service and changes the order status to approved or canceled.
07
Microservices Architecture
1. Context
Deploying 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.
2. Problem
Integrated applications become too large and complex to be effectively supported and deployed for optimal distributed resource utilization, such as in cloud environments.
3. Solution
Build the application into 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 can be quite costly.
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, aggregation, reporting, etc.
Follow our video account
EEPW Chip Perspective
Insights into the Chip World
Understand Chip Trends
↓↓↓↓ ClickRead the original text to view more news