Architecture Styles
Contents
The eight architecture styles covered in this wiki represent the major structural approaches to organising a software system. Each is a distinct set of trade-offs across the Architecture Characteristics that matter most for a given problem. Style selection is driven by which characteristics the system needs — not by fashion or familiarity. (→ Fundamentals Of Software Architecture)
For full ratings across 11 characteristics and a detailed decision guide, see Architecture Styles Comparison.
The Eight Styles
| Style | Partitioning | Quanta | Relative Cost | Best Fit |
|---|---|---|---|---|
| Layered Architecture | Technical | 1 | ★★★★★ (cheapest) | Simplest viable system; budget-constrained |
| Pipeline Architecture | Technical | 1 | ★★★★ | ETL, data transformation pipelines |
| Microkernel Architecture | Domain | 1 | ★★★ | Product-based systems needing plug-in customisation |
| Service Based Architecture | Domain | 1–few | ★★★ | Pragmatic distributed; ACID transactions needed |
| Event Driven Architecture | Domain | Multiple | ★★★ | High scalability and elasticity; async workloads |
| Space Based Architecture | Domain | 1–few | ★★ | Extreme performance; high-concurrency spikes |
| Soa Architecture | Technical | Variable | ★ | Legacy enterprise (avoid for new systems) |
| Microservices Architecture | Domain | Many | ★ (most expensive) | Large teams; maximum agility; mature DevOps |
Monolith vs Distributed
Monolithic styles — single deployment unit, single Architecture Quantum:
- Layered Architecture — simplest; technical partitioning
- Pipeline Architecture — ETL-oriented; technical partitioning
- Microkernel Architecture — plug-in extensibility; always one quantum
Distributed styles — multiple deployment units, multiple quanta possible:
- Service Based Architecture — coarse-grained services; pragmatic middle ground
- Event Driven Architecture — asynchronous; highest elasticity
- Space Based Architecture — in-memory data grid; extreme throughput
- Soa Architecture — orchestration-driven; legacy pattern
- Microservices Architecture — fine-grained; maximum modularity
Every distributed style pays the 8 Fallacies of Distributed Computing tax — design explicitly for unreliable networks, latency, and partial failures.
Technical vs Domain Partitioning
The Technical Vs Domain Partitioning decision is the most important early structural choice:
Technical partitioning groups components by role (presentation, business, persistence). Shared changes cross layers. Examples: layered, pipeline, SOA.
Domain partitioning groups components by business capability. Changes are localised to a domain. Examples: microkernel, service-based, event-driven, space-based, microservices.
Domain partitioning has better agility; technical partitioning has lower initial complexity.
Primary Decision Rule
Ask first: does the system require multiple sets of Architecture Characteristics for different parts? If yes, a distributed style is required. If no, a monolith is viable and usually preferable.
See the full decision guide in Architecture Styles Comparison.
Style Evolution Paths
Most systems start simpler and migrate toward higher agility as team and operational maturity grows:
- Layered → Service-Based: split into 4–12 domain services; keep shared DB initially
- Service-Based → Microservices: split databases; increase granularity; add DevOps automation
- Layered → Modular Monolith: add domain partitioning within a single deployment as an intermediate step
The Evolutionary Architecture and strangler fig pattern provide the migration mechanics.