Due to hardware resource limitations, embedded software may encounter coupling between drivers and applications. However, for large projects with ample resources, the need for complex business logic and subsequent expansion and maintenance necessitates a layered and modular approach, which is the essence of architectural patterns. Generally, there are seven architectural patterns:
① Layered Architecture
② Multi-layer Architecture
③ Pipeline – Filter Architecture
④ Client – Server Architecture
⑤ Model – View – Controller Architecture
⑥ Event-Driven Architecture
⑦ Microservices Architecture
Among these, the bolded parts are considered suitable architectural patterns for embedded systems. In actual development, multiple patterns are generally nested to ensure software isolation and decoupling.
1. Layered Architecture Pattern
The most common architectural pattern is the layered architecture, which mainly consists of four layers: presentation layer, business layer, persistence layer, and database layer, as shown in the following diagram:
1. Context
Complex systems undergo independent development and the evolution of various parts. For this reason, system developers need to clearly and methodically separate concerns so that each module 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 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 set of highly cohesive services. Its usage must be unidirectional. Layers represent a complete partition of software, 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 partition architecture, rather than a domain 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 moving from one layer to another must go through the layer directly beneath 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 processing a business request through multiple layers in the architecture is not high. It also increases the upfront costs and complexity of the system.
5. Uses
This approach should be applied to small, simple applications.
-
Comments
The original text is aimed at internet software, while for embedded systems, it can be divided into business layer, common component layer, system adaptation layer, and hardware driver layer. The concept of software layering is a fundamental idea, perhaps not clearly reflected in embedded software due to hardware resource limitations.
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 distribute the system’s infrastructure into different subsets.
2. Problem
How can we segment the system into multiple independently executing structures connected by some communication medium?
3. Weaknesses
High upfront costs and complexity.
4. Uses
Used in distributed systems.
-
Comments
Due to personal limitations, I do not currently understand its usage and scope in embedded software.
3. Pipeline-Filter Architecture
A recurring pattern in software architecture is the pipeline-filter pattern.
1. Context
Many systems require the transformation of discrete data streams from input to output. Many types of transformations occur repeatedly in practice, so creating them as independent reusable parts is ideal.
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 commonly loosely coupled components are easy to reuse. 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 one source and often directly outputting to another source.
In this mode, 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 very suitable for interactive systems due to their transformation characteristics.
Excessive parsing and un-parsing can lead to performance loss and increase the complexity of writing filters themselves.
5. Uses
The pipeline-filter architecture is used in various applications, especially for simplifying tasks that involve unidirectional processing.
-
Comments
It seems similar to a broadcasting and receiving pattern, which can be used in bare-metal development based on microcontrollers without an operating system message queue mechanism, where all time-sharing tasks share a broadcast queue, and upon receiving, choose to process those of interest or delete broadcast messages to truncate subsequent operations.
4. Client-Filter Architecture
1. Context
Many distributed clients wish to access shared resources and services, 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 one 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.
3. Solution
In the client-server model, 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 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 variable costs.
5. Uses
For systems where many components (clients) send requests to other components providing services (servers), we can use the client-server model to model part of the system: online applications, such as email, shared documents, or banking services.
-
Comments
This seems to apply only to internet software.
5. Model-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 can user interface functionality be independent of application functionality while still responding to changes in user input or 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 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 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 in web or mobile applications.
-
Comments
This pattern is generally used in scenarios where display support is needed, separating the maintenance management of underlying data from interface display, so that changes in business requirements and display parts have less impact on the underlying foundation, seeming to be a special case of the software layering pattern.
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
Constructing a distributed system that can serve asynchronously arriving event-related information and can scale from simple and small to complex and 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
In an e-commerce application using this solution, the workflow would be as follows:
The Order Service creates an Order, which is in a pending state, and then publishes an OrderCreated event.
✪ The Customer Service receives this event and attempts to charge the credit for this Order. It then publishes a Credit Reserved event or a CreditLimitExceeded event.
✪ The Order Service receives the event sent by Customer Service and changes the order status to approved or canceled.
-
Comments
This is easily understood in embedded software. The so-called events are interrupt information detected by hardware. Embedded software generally embodies this idea, with a while loop waiting for events to trigger, such as external button interrupts, serial port receive interrupts, or internal timer timeout interrupts. This framework is beneficial for peripheral expansion, theoretically not interfering with each other.
7. 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. This application may expose a third-party API.
2. Problem
Integrated applications can become too large and complex to be effectively supported and deployed for optimal distributed resource utilization, such as in a cloud environment.
3. Solution
Build the application into 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.
4. Weaknesses
The system design must tolerate service failures and requires more system monitoring. Service orchestration and event collaboration overhead can be significant.
5. Uses
Many use cases can apply microservices architecture, especially those involving large data pipelines. For example, a microservices system for a reporting system on retail sales of a company would be ideal. Each step of the data presentation process would be handled by a microservice: data collection, cleaning, normalization, condensing, aggregation, reporting, etc.
-
Comments
In embedded software development, this is more suitable for a relatively independent function, after adapting its basic interface, modularizing a complex function, with external input parameters, executing internally, and outputting results or triggering callbacks after completion. This function has a simple external interface, and external parties do not need to pay much attention to the internal implementation, facilitating software decoupling and maintenance.
<Original text from the internet, adapted with appropriate interpretations for embedded software>