Layered Architecture

Organize your application into presentation, business logic, and data access layers.

Layered (or n-tier) architecture organizes an application into horizontal layers, each with a specific responsibility. It’s the most common architecture for enterprise applications.

The Layers

┌──────────────────────────┐
│  Presentation Layer       │  HTTP handlers, controllers, views
├──────────────────────────┤
│  Business Logic Layer     │  Domain models, services, rules
├──────────────────────────┤
│  Data Access Layer        │  Repositories, ORM, external APIs
└──────────────────────────┘

Dependency Rule

Dependencies point downward only. The presentation layer depends on business logic; business logic depends on data access. Never the reverse.

When to Use

Monolithic applications with a clear domain
Teams that need simplicity over distributed complexity
CRUD-heavy applications where business logic is moderate
Rapid prototyping — easy to scaffold all three layers

When to Avoid

When you need independent scaling of different capabilities
When multiple teams need to deploy independently
When latency between layers is a concern (remote layers add network hops)

Variations

Variation	Description
Strict layering	Each layer can only call the layer directly below it
Relaxed layering	A layer may skip layers (e.g., presentation calls data access directly)
Clean Architecture	Dependency inversion — business logic defines interfaces, outer layers implement

Code Structure (Example)

myapp/
├── handlers/       # Presentation (HTTP)
├── services/       # Business Logic
├── repositories/   # Data Access
└── models/         # Domain Objects

Trade-offs

Pro	Con
Simple to understand	Can become a “big ball of mud”
Easy to test in isolation	Temptation to skip layers
Works well with CRUD	Not great for complex workflows
Single deployment unit	Scaling is all-or-nothing

Next: Microservices