Layered / N-Tier

## What a layered architecture is A layered (also called **N-tier**) architecture organizes a system into horizontal slices stacked on top of each other, most commonly three, sitting above the physical database: - **Presentation** — UI, controllers, API endpoints. - **Business/application logic** — the domain rules, orchestration, validation. - **Data access** — repositories, DAOs, ORM mappings. The word **'tier'** technically refers to a physical deployment boundary — a three-tier deployment puts the web server, application server, and database server on separate machines or processes — while **'layer'** is a purely logical grouping inside the same codebase or process. In practice the terms are used almost interchangeably today, and most systems people call 'layered' are logically layered but not necessarily physically tiered. ## The dependency rule The core mechanism is a strict, **unidirectional dependency rule**: each layer may only call the layer immediately below it, never upward. Layer N exposes an API (interfaces, classes, functions) that layer N+1 consumes; layer N itself holds no reference to, import of, or knowledge about layer N+1. Data and results flow back up the stack the ordinary way — through return values, DTOs, or exceptions — not by the lower layer reaching back into the caller via a callback, event listener, or shared mutable object. Concretely: 1. A controller (presentation) invokes a service method (business layer) and gets back a domain object or DTO. 2. The service invokes a repository (data layer) and gets back an entity. 3. The repository issues SQL or ORM calls and gets back result sets. At no point does the repository hold a reference to the controller. ## What the rule buys This rule exists to buy three things. 1. **First, separation of concerns**: each layer has one reason to change — the UI framework, the business rules, or the storage technology — and that reason doesn't force edits in the other layers. 2. **Second, replaceability and independent testability**: because the business layer only depends on an abstraction of the data layer (a repository interface), you can substitute a fake or in-memory repository in unit tests without a real database, and swap the concrete persistence technology without rewriting business logic. 3. **Third, team scalability**: front-end, backend/domain, and persistence specialists can each own a layer and reason about it locally, because the layer's public surface is the contract, not its internals. ## The trade-off The trade-off is real, not free. Layering adds **indirection**. Crossing a boundary usually means mapping one representation to another (entity to DTO to view model), which is: - boilerplate; - a source of subtle bugs when mappings drift; - and a nontrivial source of runtime overhead in latency-sensitive systems — each hop can mean an allocation and a copy. For a small CRUD app, imposing three or four layers 'because that's how enterprise apps are built' is often pure ceremony: the abstraction never gets exercised, and the extra files just slow down every change. ## The failure mode in production The most common production failure mode is the dependency rule breaking silently rather than a lower layer literally calling upward. It happens gradually: - someone imports a JPA entity directly into a template for convenience; - a data-access class fires a domain event the UI listens to directly; - or (a genuine, less common, version of upward coupling) a repository is handed a callback or UI-layer object to invoke on completion 'to save a round trip.' Once that happens, the data layer can no longer be compiled, tested, or reused without pulling in UI or web-framework dependencies, defeating the entire point of separating them; a schema change now has an unpredictable blast radius into template rendering code. ## Where the shape shows up A concrete, widely recognized instance of this shape is the classic three-tier Java EE application: | Tier | Typical implementation | |---|---| | Presentation | JSP/Servlet or Spring MVC controllers | | Business | EJB or Spring service classes | | Data-access | JDBC/Hibernate DAOs or Spring Data repositories | It is frequently deployed with the web tier, application tier, and database server as genuinely distinct physical tiers behind a firewall. The equivalent shape recurs in ASP.NET (Controllers -> Services -> Repositories -> SQL Server) and is still the default mental model most engineers reach for when told to 'add a layer' to a monolith.