Card 03/ 10
Layered Architecture: Presentation, Business and Data
Each layer calls only the one below it, so a change stays in one place.
Layered architecture organises the code inside an application into horizontal layers, each with one job, where each layer calls only the layer directly below it. The usual three are presentation, which handles requests and pages; business logic, which holds the rules; and data access, which reads and writes the database.
A request through it. A request to cancel an order arrives at the presentation layer, which reads the order id and the user. It calls the business layer, which checks that the order has not shipped and that this user owns it. That calls the data layer, which updates the row. Each layer knows only the one beneath it.
What it makes easy. A change stays in one layer: a new page layout touches presentation, a new refund rule touches business logic, a new database touches data access. Each layer can be tested apart from the others, and new developers know where to look.
What it makes hard. A feature that adds one field crosses every layer. Simple screens can end up with layers that only pass data through. And a team that splits work by layer, one team per layer, needs all of them for every feature.
What it is not. Layers do not decide deployment. All three layers usually ship together in one deployable; splitting them onto separate servers does not make a system microservices, it makes every call between layers a network call.
Use it when
- Organising code inside a monolith or inside each service
- Business rules should be testable without a web server or a database
Avoid it when
- It is mistaken for a way to deploy or scale parts separately
Where it is known from. Most web frameworks lead to it: a Spring application's controllers, services and repositories are the three layers under other names.
So use layers to keep each kind of change in one place inside a deployable, and choose how to deploy separately.
← → move through sections and cards