7 Architectural Patterns in Embedded Software Design

Click below【Learn Embedded Together to follow, learn together, and grow together

An architectural pattern is a general reusable solution to a commonly occurring problem in software architecture within a given context.

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, or even know very little about them.

Overall, there are mainly the following 7 architectural patterns:

1. Layered Architecture

2. Multi-layer Architecture

3. Pipe/Filter Architecture

4. Client/Server Architecture

5. Model/View/Controller Architecture

6. Event-Driven Architecture

7. Microservices Architecture

1Layered 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 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 diagram below.

A popular n-tier architecture example

1 Context

All complex systems undergo the need for the independent development and evolution of various parts of the system. For this reason, system developers need to clearly and coherently 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 develop and evolve independently, with minimal interaction between parts, supporting portability, modifiability, and reusability.

3 Solution

To achieve separation of concerns, the layered pattern divides the software into individual units (called “layers”). Each layer is a set of modules that provides a set of highly cohesive services. Its usage must be unidirectional. Layers treat a set 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 simple to build 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 go through the layer directly below it to reach the next lower layer. Requests cannot skip any layers.

Closed layers and request access

4 Weaknesses

Layering can lead to performance degradation. This pattern is not suitable for high-performance applications because 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 approach to small, simple applications or websites. This is a good choice for scenarios with very tight budgets and time constraints.

2Multi-layer Pattern

1 Solution

An example of a multi-layer pattern: consumer website J2EE

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 partition the system into multiple independently executing structures: a group of software and hardware connected by some communication medium?

3 Weaknesses

High upfront costs and complexity.

4 Uses

Used in distributed systems.

3Pipe and Filter Architecture

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

Pipe-filter pattern

1 Context

Many systems require transformation from 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 loosely-coupled components are easy to reuse. Those independent components can execute in parallel.

3 Solution

The pipes in this architecture constitute the 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 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 the filters themselves.

5 Uses

The pipe-filter architecture is used in various applications, especially to simplify single-direction processing tasks, such as EDI, ETL tools.

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

4Client-Filter Architecture

1 Context

There are many shared resources and services that a large number of distributed clients wish to access, and we want to control access or service quality.

2 Problem

By managing a group 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 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 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.

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) can be complex and have high costs of change.

5 Uses

For systems where many components (clients) send 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.

5Model, 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 changes in user input or underlying application data?

When 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’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 model, view, and controller abstraction 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.

6Event-Driven Architecture

1 Context

There is a need to provide computing and information resources to handle incoming application-generated independent asynchronous events, which can scale with demand.

2 Problem

Building a distributed system that can serve asynchronously arriving event-related information and can 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 based on scheduling policies and assigns them to the appropriate event handlers.

4 Weaknesses

Performance and error recovery can be issues.

5 Uses

In e-commerce applications using this pattern, the workflow goes as follows:

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

• Customer Service receives this event and attempts to charge credit for this Order. Then it publishes either a Credit Reserved event or a<span>CreditLimitExceeded</span> event.

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

7Microservices Architecture

1 Context

Deploy server-based enterprise applications that support various browsers and native mobile clients. The application handles 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

Monolithic applications can 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 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 can be quite expensive.

Of course, we also need more money.

5 Uses

Many scenarios 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 from the internet, copyright belongs to the original author. If there is any infringement, please contact for removal.

Follow me【Learn Embedded Together】, let’s learn together and grow together.

If you find this article good, click “Share”, “Like”, “See”!