Layered Architecture

Separation of concerns through horizontal layers with well-defined responsibilities

1. Overview: Layered Architecture, which confines change impact within a layer by separating concerns horizontally

    flowchart LR
    A["Business logic, UI, and DB access<br/>mixed in monolithic code —<br/>change impact spreads widely"] --"Separate concerns,<br/>define layer boundaries"--> B["Presentation, Business,<br/>Persistence, Database —<br/>responsibilities split by layer"] --"Isolated change,<br/>independent testing"--> C["Improved maintainability<br/>and reusability"]

    style A fill:#FFEBEE,stroke:#D32F2F,color:#000
    style B fill:#E3F2FD,stroke:#1976D2,color:#000
    style C fill:#E8F5E9,stroke:#388E3C,color:#000

Definition: The most common architectural pattern, in which a software system is split horizontally into layers by concern, with each layer depending only on the layer directly below it. This confines the impact of change to within a layer and lets each layer be developed, tested, and replaced independently.

Characteristics: (One-way dependency) Upper layers use lower layers, but lower layers know nothing about upper layers. (Separation of Concerns, SoC) Each layer focuses on a single responsibility, increasing cohesion and reducing coupling. (Foundation of major frameworks) The default structural pattern of major enterprise frameworks such as Java (Spring MVC), .NET, and Django.

2. Core Structure of Layered Architecture

A. Layer Structure and Separation of Responsibilities

    flowchart TD
    L1["Presentation Layer<br/>receives user requests,<br/>returns responses<br/>Controller, View, DTO"]
    L2["Business Logic Layer<br/>domain rules,<br/>business processing<br/>Service, Domain Model"]
    L3["Persistence Layer<br/>data access,<br/>transformation, mapping<br/>Repository, DAO, ORM"]
    L4["Database Layer<br/>data storage and retrieval<br/>RDBMS, NoSQL, Cache"]

    L1 -->|"business call"| L2
    L2 -->|"data request"| L3
    L3 -->|"SQL / API"| L4

    style L1 fill:#E3F2FD,stroke:#1976D2,color:#000
    style L2 fill:#F3E5F5,stroke:#7B1FA2,color:#000
    style L3 fill:#FFF3E0,stroke:#F57C00,color:#000
    style L4 fill:#1E3A5F,stroke:#1E3A5F,color:#fff

Layer	Key Responsibility	Included Elements	Replacement Example
Presentation	HTTP request handling, input validation, response serialization	Controller, REST API, View Template	Web → CLI → Mobile swap
Business Logic	Applies domain rules, coordinates transactions, executes use cases	Service, Domain Model, Use Case	Only this layer changes when business rules change
Persistence	ORM mapping, CRUD abstraction, query optimization	Repository, DAO, JPA Entity	JPA → MyBatis → JDBC swap
Database	Data storage, retrieval, indexing	MySQL, PostgreSQL, Redis, MongoDB	Only the Persistence layer changes when the DB is swapped

B. Inter-Layer Dependency Rules and Variant Patterns

    flowchart TD
    subgraph R1["　"]
        direction LR
        STR["Strict Layered<br/>only adjacent-layer calls allowed<br/>complete separation of concerns"]
        REL["Relaxed Layered<br/>direct calls to non-adjacent layers allowed<br/>used when performance optimization is needed"]
    end
    subgraph R2["　"]
        direction LR
        HEX["Hexagonal Architecture<br/>ports and adapters pattern<br/>isolates external dependencies"]
        ONI["Onion Architecture<br/>domain placed at the innermost core<br/>dependencies point inward only"]
    end

    style STR fill:#E3F2FD,stroke:#1976D2,color:#000
    style REL fill:#F3E5F5,stroke:#7B1FA2,color:#000
    style HEX fill:#FFF3E0,stroke:#F57C00,color:#000
    style ONI fill:#E8F5E9,stroke:#388E3C,color:#000
    style R1 fill:none,stroke:none
    style R2 fill:none,stroke:none

Anti-patterns in Inter-Layer Dependencies

Anti-pattern	Description	Resolution
Architecture Sinkhole	A request passes through a layer without any real processing	Minimize the number of layers, remove pass-through delegation
Layer skipping	Presentation calls Persistence directly	Adopt relaxed layering or route through an interface
Circular dependency	A lower layer references back to an upper layer	Correct the dependency direction by applying DIP
Bloated service	All logic concentrates in the Business Layer	Distribute logic into domain models using DDD Aggregates

Pattern Comparison

Pattern	Characteristics	Suitable Scale
Traditional layered	Simple, easy to understand, fast to develop	Small-to-medium CRUD applications
Hexagonal	Isolates external technology via ports and adapters	Complex domains where testing and replaceability matter
Clean Architecture	Dependency inversion, domain-first	Long-term maintenance, large enterprise systems
MSA	Separated by service unit instead of layers	Large systems needing independent deployment and scaling

3. Expected Benefits and Application of Layered Architecture

Category	Key Expected Benefit	Application and Practical Use
Maintainability	Change impact is confined within a layer, reducing modification cost	Only the Persistence layer changes on a DB swap; upper layers unaffected
Testability	Each layer can be unit- and integration-tested independently	Replace lower layers with mocks to test the Business Layer in isolation
Team division of labor	Dedicated teams per layer enable parallel development	Split roles across Frontend (Presentation), Backend (Business), and DBA (DB)
Technology replacement	Layer boundaries allow independent tech-stack swaps	Only the affected layer changes on an ORM swap or UI framework change

4+1 View Model MVC Pattern