Architecture styles,
cataloged into patterns.
A style is the blueprint's big picture — like "this house is a bungalow." A pattern is the tested recipe you drop inside it — like "put the kitchen island here." This chapter is the catalogue architects use so nobody has to invent the wheel twice.
Architectural Style vs. Architectural Pattern
This one distinction is asked about constantly — get it locked in before anything else.
The high-level template
Defines the overall structure of the system — the system-wide skeleton. Example: Layered, Data-Centered, Distributed. Buschmann's framing: it specifies system-wide structural properties and impacts every subsystem's architecture.
The specific, reusable solution inside it
A concrete, tested recipe for a common problem that lives inside that structure. Example: MVC living inside a Layered style, or Pipes-and-Filters living inside a Data Flow style.
Design patterns are medium-scale — applying one has no effect on the system's fundamental structure, only on a subsystem's internal architecture.
Four names, four decades, one idea getting refined
Gave the world "the language of patterns" — for buildings
Catalogued 253 patterns for physical architecture, each documenting a picture, its context, the problem it solves, evidence of validity, and related patterns. Example: "Light on Two Sides of Every Room" — give every room windows on two sides for better natural light.
Introduced Architectural Styles
Researchers found recurring high-level problem solutions in terms of elements and their relationships — originally called architectural styles. Goal: "use a solution a million times over, without ever doing it the same way twice." Example: Client–Server — reused everywhere, implemented differently each time (Gmail's client is a browser; a banking app's client is a mobile app).
Published 23 object-oriented Design Patterns
A finer-grained set of OO detailed-design solutions, directly influenced by Alexander's work, each described in a strict specification format.
Unified styles + patterns into "Architectural Patterns"
Gave well-known architectural styles a pattern-like (context–problem–solution) treatment, and explicitly distinguished Architectural Patterns (system-wide) from Design Patterns (subsystem-level).
Five families of architectural patterns
Patterns are grouped by the type of system they suit. Big systems often combine more than one family at once.
Data-Centered
Centralized data repository — clients access & work on shared data.
Data Flow
Oriented around transporting / transforming a stream of data.
Distributed
Independent processing units interacting over a network.
Interactive
User-centric systems built around heavy user ↔ system interaction.
Hierarchical
Components structured in layers/levels of abstraction and responsibility.
Everything orbits one shared store
Data-Centered
central repositoryA centralized repository holds the data, while clients access and perform work on it. Clients don't talk to each other directly — the repository is the intermediary.
Several Client S/W boxes all
point arrows inward/outward to one central Data store cylinder — no
client-to-client arrows at all.
Data moves through a chain, changing shape
Data Flow
transport & transform a streamSystems oriented around transporting and/or transforming a stream of data — think video streaming, signal processing.
A chain:
Data Source → Filter1 → Filter2 → Filter3 → Data Sink. Each filter
processes its input and produces output, passed along a pipe to the next filter.
Independent units, talking over a network
Distributed
networked processing unitsInteraction between several independent processing units connected via a network — e.g. web applications.
| Client-Server | Decentralized — clients request, one central server responds. E.g. a web server serving pages to browsers. |
|---|---|
| Broker | A mediator component routes requests, translates messages, and often handles security/scalability. E.g. SOA — services interacting through a messaging system. |
Works offline only (calculator, offline dictionary) → Interactive.
Needs server communication (WhatsApp, Gmail, banking app) → Distributed.
As a Repository (Data-Centered) → all apps share one central database.
As part of a Client-Server system (Distributed) → clients send SQL queries, server processes them.
Built around the user, running locally
Interactive
user-centric, localSystems that serve users and require heavy interaction between the user and the system — everything runs on one machine.
User Interface → Application Logic → Data Management → Local Database — all
on the same machine.
| Interactive (local) | Runs fully on one machine, works offline, single user. |
|---|---|
| Distributed (networked) | Split across client + server, needs internet, supports many users. |
Layers of abstraction and responsibility
Hierarchical
levels, vertical or horizontalComponents structured as a hierarchy — vertically (layers) and/or horizontally (modules) — to reflect different levels of abstraction and responsibility.
Top Level Module → branches
into Intermediate Modules → branches into Low Level Modules.
Highest layer = most abstract; lowest layer = closest to hardware/base operations.
Classification → Pattern → Example, in one table
| Classification | Pattern(s) | Example |
|---|---|---|
| Data-Centered | Blackboard, Repository | DBMS, compilers, CASE tools |
| Data Flow | Pipes-and-Filters | Video processing, average-calculation pipelines |
| Distributed | Client-Server, Broker | Web apps, SOA messaging systems |
| Interactive | — | Offline calculator, offline game |
| Hierarchical | — | Operating systems, manufacturing/robotics control |
Match the requirement to the pattern
Straight from a graded exam — same shape of question, worth drilling until it's automatic. Options given: Blackboard, Pipe-Filter, Client-Server, Broker Client-Server.