Common Software Architecture Patterns and Their Applications

Before starting major code development, selecting an appropriate architectural style is essential for providing required functionality and quality attributes in large‑scale enterprise systems.

According to Wikipedia, an architecture pattern is a general, reusable solution to a commonly occurring problem in software architecture, similar to design patterns but with a broader scope.

The article briefly introduces ten common architecture patterns, describing their purposes, strengths, and weaknesses.

Layered Pattern

The layered pattern organizes a program into groups of sub‑tasks at specific abstraction levels, each layer providing services to the one above it. Typical four‑layer division in information systems:

Presentation layer – UI layer

Application layer – service layer

Business logic layer – domain layer

Data access layer – persistence layer

Applications: general desktop applications, e‑commerce web applications.

Client‑Server Pattern

Consists of a server and multiple clients; the server provides services to clients, which request them, while the server continues listening for further requests.

Applications: online services such as email, file sharing, banking.

Master‑Slave Pattern

The master distributes work among slaves and aggregates results from them.

Applications: database replication (master DB as authoritative source, slaves synchronize), peripheral devices on a system bus.

Pipe‑Filter Pattern

Builds systems that generate and process data streams; each processing step is a filter component, and data flows through a pipeline, allowing buffering or synchronization.

Applications: compilers (lexical analysis, parsing, code generation), bioinformatics workflows.

Broker Pattern

Uses decoupled components in a distributed system that interact via remote service calls; a broker component coordinates communication between components.

Applications: messaging software such as Apache ActiveMQ, Apache Kafka, RabbitMQ, JBoss Messaging.

P2P Pattern

Each component (peer) can act as both client and server, dynamically changing roles.

Applications: file‑sharing networks (Gnutella, G2), multimedia protocols (P2PTV, PDTP), cryptocurrency products (Bitcoin, blockchain).

Blackboard Pattern

Useful for problems without a deterministic solution; consists of a global memory (blackboard), knowledge sources (specialized modules), and control components that select, configure, and execute modules.

Applications: speech recognition, vehicle identification and tracking, protein structure identification, sonar signal interpretation.

Interpreter Pattern

Designs components to interpret programs written in a domain‑specific language, defining a class for each language symbol.

Applications: database query languages (SQL), communication protocol description languages.

MVC Pattern

Divides interactive applications into Model (core data and logic), View (user interface), and Controller (handles user input), separating internal data representation from presentation.

Applications: mainstream internet application architectures, web frameworks such as Django and Rails.

Pattern Comparison

Pattern

Advantages

Disadvantages

Layered

Reusable lower‑level services; clear layer definitions; modifications confined to a layer.

Not universally applicable; sometimes layers must be skipped.

Client‑Server

Easy to model services for client requests.

Server threads may become a bottleneck; inter‑process communication can be heavy.

Master‑Slave

Accuracy through delegation to slaves.

Independent slaves lack shared state; communication latency can be problematic.

Pipe‑Filter

Supports concurrent processing; easy to add filters; reusable filters.

Overall speed limited by slowest filter; data conversion overhead.

Broker

Dynamic modification, addition, deletion, and relocation of objects; transparent distribution.

Requires standardized service descriptions.

P2P

Decentralized computation; high fault tolerance; scalable resources.

Service quality not guaranteed; security challenges; performance depends on node count.

Event Bus

Easy to add publishers, subscribers, and connectors; effective for highly distributed apps.

Scalability may suffer as all messages pass through a single bus.

MVC

Multiple views for the same model; runtime view attachment/detachment.

Increased complexity; user actions may cause unnecessary updates.

Blackboard

Easy to add new applications; extensible data space structure.

Changing data space structure is hard; may need synchronization and access control.

Interpreter

Supports highly dynamic behavior; enhances end‑user programmability; easy to replace interpreter.

Interpreted languages can be slower than compiled ones.

For more details, readers are encouraged to like, comment, and join the architecture discussion group via the provided QR code.