How do design patterns differ from architectural patterns, and why does the distinction matter when you choose one?
answer
- participants: classes vs modules/services
- reversible in hours vs months
- quality attributes vs local code forces
- hexagonal is *built from* Adapter + Strategy
- ladder: idiom → design → architectural
basics
~20 sDesign patterns organise a few classes or functions inside a module (Strategy, Observer, Decorator). Architectural patterns organise whole systems — modules, processes, services (layered, hexagonal, event-driven, microservices). Design patterns are cheap to change; architectural ones are expensive and constrain deployment and teams.
solid answer
~50 sThe difference is scope, participants, and cost of reversal. A design pattern's participants are classes, objects or functions inside one module; its consequences are local — readability, coupling, testability — and swapping Strategy for a lookup table is an afternoon's refactor. An architectural pattern's participants are modules, processes, data stores or services; it fixes dependency direction, deployment units and often team boundaries (Conway's law). Layered, Ports & Adapters/hexagonal, MVC, Pipes & Filters, Event-Driven, CQRS, Microservices are architectural; Observer, Adapter, Command, Builder are design. Practically: choose architectural patterns from quality attributes you must satisfy — independent deployability, latency, failure isolation, auditability — and accept they are near-irreversible; choose design patterns from local forces (a varying algorithm, an incompatible interface) and prefer the simplest thing that removes the duplication. Applying an architectural pattern to solve a class-level problem, or a design pattern to solve a system-level one, is a classic misfit.
go deeper
Say design patterns arrange a few classes inside a module, architectural patterns arrange whole systems, and give one example of each.
Add the axes — participants, blast radius, cost of reversal — and show that architectural styles are implemented using design patterns.
Talk about decision inputs (quality attributes vs local forces), the misfit failure modes in both directions, and when a choice deserves an ADR.
Connect to org design: architectural patterns encode team boundaries and operational cost, so the real evaluation is fitness-for-constraints plus the organisation's ability to run them, with a reversibility budget.
## Definitions **Design pattern** — a recurring, named arrangement of a *small number of collaborating classes/objects/functions* that solves a problem inside one program or module. Canonical catalogue: the 1994 Gang of Four book (Gamma, Helm, Johnson, Vlissides), split into creational (Factory Method, Builder, Singleton, Abstract Factory, Prototype), structural (Adapter, Decorator, Facade, Composite, Proxy, Bridge, Flyweight) and behavioural (Strategy, Observer, Command, Template Method, State, Iterator, Visitor, Mediator, Chain of Responsibility, Memento, Interpreter). **Architectural pattern (or architectural style)** — a named arrangement of *whole subsystems*: modules, layers, processes, services, data stores, and the rules connecting them. Examples: Layered, Ports & Adapters (hexagonal), Clean/Onion, Model-View-Controller and its relatives (MVP, MVVM), Client-Server, Pipes & Filters, Blackboard, Event-Driven / Publish-Subscribe backbone, Service-Oriented, Microservices, Modular Monolith, CQRS, Event Sourcing, Space-Based. **Idiom** sits below both: a language-specific micro-solution (RAII, `defer`, comprehensions, context managers). The ladder is idiom → design pattern → architectural pattern, and this three-level split comes from the POSA series (*Pattern-Oriented Software Architecture*, Buschmann et al.). ## The axes that separate them | Axis | Design pattern | Architectural pattern | |---|---|---| | Participants | classes, objects, functions | modules, processes, services, stores | | Blast radius | one module/package | whole system | | Consequences | coupling, testability, readability, allocation cost | availability, latency, deployability, failure isolation, team autonomy, cost | | Cost to reverse | hours to days | months, sometimes a rewrite | | Who decides | the developer writing the code, in review | architecture forum / staff+ with stakeholder buy-in | | Chosen from | local forces: varying algorithm, incompatible interface, expensive construction | quality attributes / non-functional requirements and constraints | ## Why the distinction matters when choosing 1. **Different decision inputs.** Design patterns are chosen from *local code forces*: "this algorithm varies per customer" → Strategy; "this third-party interface doesn't match ours" → Adapter. Architectural patterns are chosen from *quality attributes*: "teams must deploy independently" → services; "reads outnumber writes 1000:1 with different shapes" → CQRS; "we must reconstruct historical state for audit" → Event Sourcing. 2. **Different reversibility, so different rigour.** Because architectural choices are expensive to undo, they deserve an explicit record (an ADR — architecture decision record) with the alternatives and consequences. Design patterns rarely need one; the code is the record. 3. **Different failure modes.** Over-applying design patterns produces "pattern soup": indirection with no varying axis, five classes where a function would do. Over-applying architectural patterns produces distributed monoliths, network calls where a function call would do, and operational cost the org cannot carry. 4. **They compose, they don't compete.** A hexagonal architecture is *implemented with* design patterns: each port is an interface, each adapter is literally the Adapter pattern, an event-driven backbone is Observer at system scale, and a repository is a Facade/Gateway over persistence. Being able to say "this architectural style is realised by these design patterns" is a strong interview signal. ## Common misfits - **Architectural solution to a local problem:** extracting a microservice because one class had two reasons to change. You bought network partitions, versioning, and distributed tracing to solve a refactor. - **Design solution to a system problem:** adding an in-process Observer to "decouple" two teams' code that still deploy together and share a database — the coupling that hurt was deployment and data, not method calls. - **Naming confusion:** calling MVC a design pattern. MVC constrains whole-application structure (and in some framings is a compound of Observer + Strategy + Composite); calling it design-level hides its system-wide reach. - **Assuming architecture is only about diagrams.** An architectural pattern's most important part is its *consequences*, not its boxes. ## How to answer crisply Lead with the three axes — participants, blast radius, reversibility — give two examples per level, then make the composition point (hexagonal is built out of Adapter/Strategy) and the decision-input point (quality attributes vs local code forces).
- Name an architectural pattern and the design patterns typically used to implement it.Ports & Adapters (hexagonal): ports are interfaces owned by the domain; each driven adapter is the Adapter pattern over a database, queue or HTTP client; swapping implementations per environment is Strategy; a Facade often fronts a subsystem, and Dependency Injection wires the whole thing.
- Is MVC a design pattern or an architectural pattern?Usually classified architectural, because it partitions a whole application into presentation, state and control and dictates the dependency and update flow. Its internals are realised with design patterns — classically Observer for view updates and Strategy for the controller.
- How does the distinction change how you document a decision?Architectural choices get an ADR with context, alternatives and consequences because they are expensive to reverse and affect many teams. Design-pattern choices are documented by the code and the class names, plus a comment only when the varying axis is non-obvious.
saying these in an interview costs you the question
- Saying architectural patterns are 'just bigger design patterns' with no mention of reversibility, deployment or teams.
- Treating microservices as a design pattern you can adopt inside one module.
- Believing design and architectural patterns are alternatives rather than composable layers.
- Choosing an architectural style from fashion or resume value instead of quality attributes.
- Claiming that using GoF patterns everywhere is what 'good architecture' means.