Layered Architecture

The classic layers

Layer	Responsibility	Should not contain
Presentation (UI or API)	Show data, accept input, translate requests and responses	Business rules, SQL
Business / domain	The rules of the problem: validation, calculations, workflows	HTTP details, storage details
Data access	Load and save data, hide the storage technology	Business decisions
Database / external systems	Store data, provide other services	Application logic

Names vary (service layer, application layer, repository), but the pattern is the same: presentation, domain, data.

How a request travels

A user submits an order. The presentation layer receives it and checks the format. The business layer checks the rules and calculates totals. The data layer writes the rows. The result passes back up the same way. Each layer talks only to its neighbour.

Where validation belongs

Validation happens in several layers, and each checks something different:

• Presentation or API layer: the shape and format of input, such as required fields, types, lengths and whether an email looks like an email.
• Business layer: the rules of the problem, such as “stock must cover the quantity” or “a discount code can be used once”.
• Database: constraints such as not null, unique and foreign keys. They are the last line of defence and catch what slipped through, including bugs and concurrent writes.

Checks in the browser only give the user fast feedback. Anyone can bypass them by calling the API directly, so the server must repeat every check that matters (see Input Validation).

Rules for keeping layers useful

• Dependencies point one way. Upper layers call lower ones, never the reverse. A data layer that imports a UI class breaks the layering.
• Do not skip layers without a reason, or the layering stops meaning anything.
• Pass plain data structures across boundaries. Do not hand database objects to the UI.
• Keep each layer testable. The business layer should be testable without a database or web server.

Layers versus tiers

A layer is a logical division in the code. A tier is a physical one, a separately deployed part such as browser, application server and database server. A three-layer application may run on one machine or on three.

Costs of layering

Layers give clarity and replaceability, but a simple feature may need edits in every layer, and too many pass-through methods add noise. Other structures exist, such as hexagonal (“ports and adapters”), clean architecture and microservices. They share the same aim of separating concerns in different ways. A monolith can be well layered inside a single deployable unit, and coupling and cohesion tell you whether the boundaries are working.

Try it

Open a project you work on and find one feature end to end (for example “create an item”). Note which files take part and put each into a layer. Look for one place where a layer does something that belongs elsewhere, and describe how you would move it.