// Architecture Styles · 01
Layered Architecture
Stack the code by job: presentation on top, data at the bottom.
How it fits together
- OrdersController uses / calls OrderService (calls)
- OrderService uses / calls OrderRepository (calls)
- OrderRepository uses / calls Database (SQL)
- OrdersController fails / error path OrderRepository (no skipping)
Spot it
- SQL queries inside controllers
- Business rules copied across screens
- No obvious place for new code to go
It costs
Easy to grasp, but the business logic ends up depending on the database.
Go deeperThe full explanation and what to ask for · 1 min readExpandCollapse
Each layer has one job and only talks to the layer beneath it. That makes it obvious where code belongs and lets you replace a UI without touching the rules.
It is a sound default for CRUD-heavy apps. It hurts when the business logic is rich: the logic layer depends on the data layer, so persistence concerns leak upward and tests need a database. Layers that only pass calls through are a sign it is too heavy.
Clean Architecture keeps the layers but inverts the bottom dependency so the domain sits at the centre. Layering slices the code horizontally; a modular monolith slices it by business capability first.
Ask for it
- presentation layer
- business logic layer
- data access layer
- strict vs relaxed layering
- dependency direction
Split this controller into three layers: a thin controller that maps HTTP, a service class that holds the business rules, and a repository over the ORM. Each layer may only call the one directly below it.