Architectural Patterns¶
Architectural patterns describe how an entire application is laid out — how layers separate, how data flows across the system, and where dependencies point. They are distinct from design patterns, which solve local problems within a small cluster of classes.
A useful test: if it tells you how the whole app is structured, it's an architectural pattern. If it solves one isolated coupling, creation, or behavior problem, it's a design pattern.
Design Patterns vs Architectural Patterns¶
| Design Pattern | Architectural Pattern | |
|---|---|---|
| Scope | A few collaborating classes | The entire application |
| Decides | How a small problem is solved locally | How layers, modules, and data flow are organized |
| Example | Observer, Strategy, Factory, Decorator | MVC, MVVM, BLoC, Clean Architecture |
| Reference | Design Patterns (GoF, 1994) | Pattern-Oriented Software Architecture (POSA, 1996); various authors |
| Granularity | Class / object level | System / module level |
They are not separate worlds
Architectural patterns are built out of design patterns:
- MVVM relies on Observer (data binding between View and ViewModel).
- BLoC relies on Stream-based Observer + Mediator.
- Clean Architecture relies on Dependency Inversion (a SOLID principle) to make dependencies point toward the domain.
- Flux / Redux is essentially Observer + Command on a single store.
The building blocks are design patterns. The assembled blueprint is architecture.
Two Families¶
Architectural patterns fall into two broad families that solve different problems:
-
Presentation-Layer Patterns
How the UI is structured: who owns state, how the View talks to business logic, and how user input flows into the system.
MVC · MVP · MVVM · MVI · BLoC · Flux / Redux · VIPER
-
Application-Layering Patterns
How the whole app is divided into layers and which direction dependencies point. About protecting the domain from frameworks and I/O.
Layered (N-tier) · Hexagonal · Onion · Clean Architecture
Quick-pick Comparison¶
| Pattern | Family | Primary concern | Where you'll see it |
|---|---|---|---|
| MVC | Presentation | Separate input handling from rendering | Rails, Laravel, Spring MVC, ASP.NET |
| MVP | Presentation | Make View dumb and testable via a Presenter | Classic Android (pre-MVVM), GWT, WinForms |
| MVVM | Presentation | Two-way data binding between View and ViewModel | WPF, Jetpack Compose, Vue, Knockout, SwiftUI |
| MVI | Presentation | Unidirectional state stream, immutable state | Android (Kotlin Flow), Cycle.js |
| BLoC | Presentation | Streams in / Streams out — separate UI from logic | Flutter |
| Flux / Redux | Presentation | Single store, action → reducer → state | React ecosystem, NgRx, Vuex |
| VIPER | Presentation | Strict role separation (View/Interactor/Presenter/Entity/Router) | iOS apps, large enterprise iOS codebases |
| Layered (N-tier) | Application | Horizontal slicing: Presentation → Business → Data | Most enterprise apps; default for new projects |
| Hexagonal | Application | Domain isolated behind ports; adapters plug in I/O | DDD-heavy backends, microservices |
| Onion | Application | Concentric layers; dependencies point inward | .NET / DDD communities |
| Clean Architecture | Application | Dependency Rule — inner layers know nothing of outer | Modern backends, mobile (esp. Android/iOS) |
How to choose
- Small UI app — start with MVC or MVVM. Don't reach for VIPER or Clean until you feel the pain of mixing concerns.
- Reactive UI framework (Flutter, React, modern Android) — your framework already biases you: BLoC for Flutter, Redux/Flux for React, MVVM/MVI for Android.
- Large business backend — pick a layering pattern (Hexagonal/Onion/Clean). They're more similar than different; pick the one whose vocabulary your team likes.
- Don't mix levels — BLoC and Clean Architecture aren't competitors. BLoC is how the UI talks to use cases; Clean is how the use cases are organized. You can use both at once.