Essential Classic Software Architecture Styles Every Architect Must Know

What Is a Software Architecture Style?

A software architecture style is a reusable pattern that describes how components are organized, how they interact, and what topological constraints exist. Choosing the right style lets architects solve problems efficiently.

1. Data‑Flow Style

The system consists of a series of processing steps where data flows from one step to the next, each step only cares about its input and produces output. Two sub‑styles are described:

Batch processing : each step runs after the previous one finishes; data is passed as files or datasets. Example: a bank’s nightly reconciliation system that aggregates daily transactions, verifies accounts, generates reports, and archives data sequentially.

Pipeline‑filter : each step (filter) processes data as it streams, allowing concurrent execution. Example: a Linux command line pipeline cat log.txt | grep "ERROR" | sort | uniq -c where each command is a filter and the pipe (|) connects them.

Typical applications: batch processing – banking end‑of‑day settlement, ETL, payroll; pipeline‑filter – compilers, audio/video transcoding, log analysis, CI/CD pipelines.

2. Call/Return Style

Components are organized by explicit call relationships. The caller sends a request, the callee executes and returns a result, making control flow clear and traceable.

Sub‑style: Main program / sub‑program : a single‑threaded sequential execution where data is passed via parameters or shared globals. Example: early C programs where main() calls various functions; easy to understand but hard to extend.

3. Object‑Oriented Style

Data and behavior are encapsulated in objects that interact through message passing. Inheritance and polymorphism enable natural extensibility.

Example: Java Spring framework where a Controller calls a Service, which calls a Repository, forming a clear responsibility chain.

4. Layered Style

Each layer may call only the layer directly below it (strict layering) or any lower layer (loose layering). Interfaces isolate layers, so changes in one layer do not affect others.

Typical use: classic MVC three‑tier web applications (Controller → Service → DAO) widely adopted in enterprise systems.

5. Independent Component Style

Components are highly autonomous and communicate via events or messages, without knowing each other’s identities.

Process‑communication sub‑style : separate processes interact through IPC mechanisms such as pipes, sockets, or shared memory. Example: micro‑services where an Order service publishes a message via RabbitMQ and an Inventory service consumes it asynchronously.

Event‑driven sub‑style : publishers do not know subscribers and vice‑versa; adding a subscriber does not require changing the publisher, illustrating the Open‑Closed Principle. Example: an e‑commerce platform that publishes an “order created” event, which triggers independent services for inventory, logistics, and points.

6. Virtual‑Machine Style

A simulated execution environment runs programs or rules, providing cross‑platform capability and flexibility.

Interpreter sub‑style : code is parsed and executed at runtime without prior compilation. Examples: Python interpreter, JavaScript engine V8, workflow rule scripts.

Rule‑based sub‑style : business rules are separated from program logic and can be changed dynamically. Example: a banking risk‑control system that flags transfers over 50,000 CNY from remote locations, with the rule stored in a rule repository that business users can modify without code changes.

7. Repository (Warehouse) Style

A central shared data store (the repository) is the only means for components to collaborate; components do not communicate directly.

Database sub‑style : components read/write a common database, relying on transactional guarantees for consistency. Example: traditional ERP systems where procurement, sales, and finance modules share an Oracle database.

Blackboard sub‑style : the repository is active; changes trigger independent knowledge sources that read the blackboard and contribute to a final solution. Example: a speech‑recognition system where acoustic, syntactic, and semantic modules write their intermediate results to a blackboard, which is then used to produce the final transcription.

Mnemonic for Quick Recall

“Data pipeline, call hierarchy, independent events, virtual machine can interpret, repository shares data.” This phrase helps remember the five major styles and their sub‑styles.