Day 25 – Five Classic Software Architecture Styles: Focus on System Organization

1. What Is an Architecture Style

An architecture style is a recurring overall organization pattern used by software systems. It typically defines the component types, connection methods, data and control flow, and constraints on component composition. Styles are not specific frameworks or products; for example, Kafka is a product, while event‑driven or implicit‑call is a style.

2. Data‑Flow Style: Data Processed Like a Product

2.1 Batch‑Processing Sequence

Input file → Step A completes → Intermediate file → Step B completes → Intermediate file → Step C completes → Output file

Features: whole batch processed before the next step starts, data passed via files or full data sets, low emphasis on real‑time feedback. Example: an online hospital exports all appointment records at midnight, cleans them, then generates statistical, financial, and operational reports.

Suitable for nightly reports, offline settlement, large‑scale file conversion, periodic data processing. Advantages: clear steps, easy implementation and verification, each step can run independently, good for throughput‑oriented, low‑latency‑requirement tasks. Disadvantages: high end‑to‑end latency, many intermediate files, unsuitable for interactive real‑time systems.

2.2 Pipe‑and‑Filter

Data source → Filter A → Pipe → Filter B → Pipe → Filter C → Output

Each filter performs a specific transformation; the pipe transports data between filters. Filters can work in parallel and process data item‑by‑item or in chunks. Classic example: a compiler where source code passes through lexical analysis, syntax analysis, semantic analysis, and code generation. Other examples: medical imaging pipelines, audio/video processing, signal processing, log stream cleaning, continuous format conversion.

Advantages: filters are reusable, replaceable, and recombinable; easy to add steps; supports parallel and streaming processing; clear overall structure. Disadvantages: filters must agree on data formats, format conversion may add overhead, error handling and interaction control become complex, not suitable for systems requiring extensive shared state.

Key distinction: batch processing waits for the entire batch before moving on, while pipe‑and‑filter streams data as soon as a portion is ready, allowing concurrent execution of stages.

3. Call/Return Style: Explicit Invocation and Result Return

3.1 Main‑Program–Subprogram

RegistrationMain
├─ Call IdentityCheckSubprogram → returns verification result
├─ Call QuerySlotSubprogram → returns slot result
└─ Call CreateRegistrationSubprogram → returns creation result

The main program controls overall flow; subprograms perform specific tasks. Calls form a tree‑like hierarchy. Suitable for small‑scale, stable, procedural workflows.

Advantages: simple, intuitive, clear call order. Disadvantages: strong control coupling, main program can become complex, changes at higher levels may affect many subprograms.

3.2 Data Abstraction and Object‑Oriented

Objects encapsulate their own data and operations; other objects interact via public methods. Encapsulation, inheritance, polymorphism, and responsibility separation enable collaboration.

Advantages: hides internal changes, promotes reuse and extensibility, maps well to real‑world domain objects. Disadvantages: complex object relationships can be hard to understand, fine‑grained calls may incur overhead, managing object state and lifecycle can be intricate.

3.3 Layered Architecture

Presentation → Business Logic → Data Access → Database/Infrastructure

Each layer provides services to the layer above and consumes services from the layer below. Closed layering forbids cross‑layer access; open layering allows constrained cross‑layer calls.

Advantages: clear responsibilities, easier modification, replacement, and reuse of individual layers; supports team division and layered testing; isolates upper layers from lower‑layer changes. Disadvantages: performance overhead from multiple calls, strict layering may be hard to maintain in practice, cross‑layer access can break constraints.

3.4 Client/Server

Clients initiate requests; servers manage data, computation, or shared services and return results. Two‑tier C/S has clients directly accessing a database server; three‑tier adds an application server; B/S treats browsers as clients.

Advantages: centralized management of resources and services, clear separation of client and server responsibilities, multiple clients can share server capabilities. Disadvantages: server can become a performance bottleneck or single point of failure; network issues affect service availability; thick clients increase installation, upgrade, and maintenance costs.

4. Data‑Centric Style: Components Around Shared Data

4.1 Repository Style

Components actively read and write a central data store, which does not dictate the next component to execute.

Example: registration, billing, medical record, and statistics systems all operate on a unified patient data repository, each reading or updating as needed.

Advantages: centralized data management, consistency, easy integration via a common data model, convenient to add read‑only components, simplifies backup, security, and analysis. Disadvantages: the central repository can become a performance bottleneck and single point of failure; heavy reliance on shared data; schema changes impact many components; complex permission and concurrency control.

4.2 Blackboard System

A blackboard holds the problem state, intermediate results, and candidate solutions. Knowledge sources each possess a specific expertise or solving method. A control component selects an appropriate knowledge source based on the current blackboard state, which then contributes to the solution, updating the blackboard for the next iteration.

Example: an assisted diagnosis system writes symptoms, images, lab results, and history to the blackboard; imaging, lab, and disease‑rule knowledge sources each add judgments; the control component selects the next source based on evidence.

Suitable for speech recognition, pattern recognition, image understanding, and problems that are complex, unstructured, and lack a predetermined solving sequence.

Advantages: can combine heterogeneous knowledge and algorithms, fits uncertain problems and incremental solving, allows gradual addition of new knowledge sources. Disadvantages: complex control strategy, hard to predict and test the solving process, difficult to design blackboard structure and knowledge‑source interfaces, performance evaluation is challenging.

5. Virtual‑Machine Style: Interpreted Execution

5.1 Interpreter

An interpreter reads a language or script and executes its semantics via an interpretation engine, maintaining current control state and runtime data.

Example: a hospital defines a custom appointment‑restriction language—"age > 65 AND department = geriatrics => priority appointment"—which the interpreter evaluates at runtime.

Advantages: language can be modified easily, execution environment is isolated from the underlying platform, behavior can change without recompiling the core system. Disadvantages: slower than direct execution, interpreter design is complex, errors may surface only at runtime.

5.2 Rule System

A rule system contains a rule base, a fact (working) memory, and an inference engine. The engine matches facts against rules, resolves conflicts, and fires applicable rules.

Example: facts "patient has fever, elevated white blood cells, specific imaging feature" trigger the rule "if these conditions hold, suggest disease X risk".

Advantages: separates knowledge from control code, rules are easy to add or modify, suitable for enumerated expert knowledge. Disadvantages: performance degrades with many rules, possible rule conflicts or loops, overall impact of rules is hard to understand and test.

6. Independent‑Component Style: Loosely Coupled Processes

6.1 Process Communication

Independent processes run with their own control and state, communicating via explicit messages, sockets, or remote calls. Example: a registration service process sends a payment request message to a payment service process, which returns a result; the processes may be deployed on different nodes.

Advantages: supports concurrency and distributed deployment, each process can be scaled or upgraded independently, failures are partially isolated. Disadvantages: communication, synchronization, and concurrency control are complex; must handle network timeouts, retries, and message loss; distributed debugging is difficult.

6.2 Event System (Implicit Call)

Publishers emit events without knowing the subscribers. Interested components register or subscribe in advance; when an event occurs, the system notifies all subscribers.

Example: after a successful registration, the registration service publishes a "registration‑successful" event; SMS, statistics, and audit services consume the event without the publisher invoking them directly.

Advantages: loose coupling between publisher and subscribers, easy to add new consumers, suitable for asynchronous processing and extensibility, components can evolve independently. Disadvantages: overall control flow is less visible, must manage event ordering, duplication, loss, and eventual consistency; debugging, tracing, and testing become harder.

7. Common Confusions and How to Disambiguate

Pipe‑and‑Filter vs. Event System: pipe‑and‑filter passes data from one stage to the next; event system broadcasts events without knowing receivers.

Layered Architecture vs. Pipe‑and‑Filter: layered architecture involves upward service calls and returns; pipe‑and‑filter streams data transformations.

Repository vs. Blackboard: repository components actively read/write shared data; blackboard uses a control component to select knowledge sources that incrementally solve a problem.

Interpreter (architecture style) vs. Interpreter (design pattern): the former describes overall system organization around an interpretation engine; the latter describes a local code structure for parsing expressions.

8. Real‑World Systems Often Mix Multiple Styles

An online hospital might use layered architecture for the registration application, an event system to notify SMS/audit/statistics after registration, a pipe‑and‑filter pipeline for medical‑image processing, a repository for unified patient records, a blackboard for assisted diagnosis, a rule system for insurance‑policy evaluation, and process communication for inter‑service messaging.

9. Five‑Step Style‑Selection Method

Does the description emphasize data passing through successive transformation steps? → Choose Data‑Flow.

Does it emphasize a main program, object methods, hierarchical calls, or client‑server requests? → Choose Call/Return.

Does it emphasize multiple components working around a shared central data store? → Choose Data‑Centric.

Does it emphasize interpreting a custom language or matching facts against rules? → Choose Virtual‑Machine.

Does it emphasize independent processes, messages, events, or publish‑subscribe coupling? → Choose Independent Component.

First identify the broad category, then use the highlighted “question‑eye” keywords to pinpoint the specific sub‑style.

10. Quick Reference Table for Question‑Eye Keywords

Batch, whole file, previous step must finish → Batch‑Processing Sequence

Compiler, signal, audio/video, continuous conversion → Pipe‑and‑Filter

Main control module, call tree, subprogram → Main‑Program–Subprogram

Object, encapsulation, method, state → Data Abstraction & Object‑Oriented

Each layer provides service to the layer above, OSI → Layered Architecture

Client, server, request‑response → Client/Server

Central database, shared data, unified model → Repository

Knowledge source, control, incremental solving, speech recognition → Blackboard

Custom language, script, interpretation engine → Interpreter

Rule base, fact base, inference engine → Rule System

Independent process, explicit message receiver → Process Communication

Publish‑subscribe, broadcast, registration, implicit call → Event System

11. Sample Answer Templates for Exam Questions

Pipe‑and‑Filter

For a system that requires data to pass through multiple independent processing steps, adopt the pipe‑and‑filter style. Encapsulate each step as a filter, connect them with a pipe, and allow filters to be reused, replaced, or executed in parallel. Be aware of the need for a common data format and the overhead of format conversion, error handling, and potential performance costs.

Layered Architecture

When system responsibilities are complex and need change isolation, use a layered architecture. Divide the system into presentation, business‑logic, and data‑access layers, each offering services to the layer above via clear interfaces. This yields clear responsibilities and easier modification, but incurs extra call overhead and may be hard to enforce strict layering.

Event System

For a scenario where a registration success must trigger notifications, auditing, and statistics, choose an event‑system style. The registration service publishes a "registration‑successful" event; subscribed components handle it independently, reducing coupling. However, you must address event ordering, duplicate consumption, message loss, and eventual consistency.

Blackboard

When an assisted‑diagnosis problem is uncertain and requires collaboration among multiple knowledge sources, adopt a blackboard system. Knowledge sources read the blackboard state, contribute partial results, and the control component selects the next source based on current evidence, gradually forming a diagnosis. The control strategy, testing, and performance evaluation are complex.

12. Three‑Minute Overview

The classic architecture styles fall into five categories. Data‑flow includes batch‑processing and pipe‑and‑filter; Call/Return includes main‑program–subprogram, object‑oriented, layered, and client/server; Data‑Centric includes repository and blackboard; Virtual‑Machine includes interpreter and rule system; Independent Component includes process communication and event system. Real systems often combine several styles; exam answers should identify the dominant mechanism, not just the presence of a keyword.