Layered architecture

Pattern · Chapter 7

Core idea

One of the most common techniques for partitioning a complicated system.
The application is split into horizontal layers, each sitting on top of a lower one.
A layer depends on one or more layers below it (depending on open/closed), but is independent of layers above it.
Classic example: three layers — presentation, business, data.

Closed layer: requests flowing down must pass through it and cannot bypass it. Provides isolation → code easier to change/write/understand; changes to one layer don’t ripple to others.
Open layer: requests may skip it. Increases complexity and lowers maintainability (more dependencies), but avoids needless traffic when a layer only forwards requests.
Example: a shared-services layer between business and data can be made open so the business layer can reach the data layer directly when the shared layer isn’t needed.
Key judgment: closed layers give isolation, but experienced architects selectively open specific layers when appropriate. Not all layers must be uniformly open or closed.

Layers = logical separations of the application. Multiple layers can live on one machine (multi-layer architecture).
Tiers = physical separations. A three-tier architecture deploys the three parts to three separate machines (multi-tier architecture).
Some people use the terms interchangeably; confirm meaning when precision matters.

Reduces complexity via Separation of Concerns (SoC); each layer understood on its own.
Minimized inter-layer dependencies → implementations of a layer can be swapped without affecting others.
Easier development: pattern is well known; maps to how orgs staff teams (UI devs for presentation, backend devs for business/data).
Improves testability: a layer can be isolated and others mocked/stubbed.
Higher reusability when multiple apps share the same business/data layers.
When deployed to tiers, extra benefits: increased scalability (add hardware per tier), greater availability (failover across machines), enhanced security (firewalls between tiers), reusable physical tiers.

A single requirement change (e.g. adding a field) may force changes across all layers → lowers agility and complicates deployment.
More code needed for inter-layer interfaces/plumbing.
Teams must be diligent about placing logic in the correct layer (no business logic in presentation, no data-access in business).
Performance cost of traversing layers and transforming data representations; worse across physical tiers, which also add monetary and hardware-management costs.

Clients and a server communicate directly; many clients per server.
Client holds UI code; server holds the database (traditionally an RDBMS). Most logic on server, some can be on client.
Thick/fat client = client holds significant logic; thin client = server does the work.
Risk: business logic duplicated on client and server violates DRY and lowers maintainability; prefer centralizing shared logic.

A grouping of SQL statements forming a logical unit; historically used to cut network round-trips (one call runs many statements).
Benefits: precompiled execution plans, security (grant execute without table permissions), reusability.
Drawbacks: limited coding constructs, business logic not centralized.
Modern guidance: keep application logic OUT of stored procedures — it belongs outside the data layer. Still useful for complex queries / multi-statement, large-data queries where performance matters.

Multiple tiers; the three-tier variant (presentation/business/data) rose with the web, replacing rich two-tier clients.
Presentation tier: UI rendering, data formatting, basic input validation (no business logic — that’s the business tier); own usability concerns; aim for thin clients.
Business (application) tier: business rules, validations, calculations, business entities; intermediary between presentation and data.
Data tier: persistent storage (e.g. RDBMS) and data access. Can further split into a persistence layer (ORM/data access) and a database layer (data store) so tech can be swapped.

Software Architect’s Handbook (Packt, 2018), Ch.7 “Layered architecture”, pp. 500-515.