Software Architecture: Layered Architecture

This article explains the layered architecture pattern—covering exam topics, core components, and practical examples.

When building an application that needs to remain maintainable and extensible over time, you need a clear structure. Layered architecture is one of the most widely used architectural patterns. It divides an application into horizontal layers, each with a specific responsibility. In exams and professional practice, you’ll frequently encounter questions about the layers themselves, their purposes, and communication rules between them.

In a Nutshell

Layered architecture organizes systems into separate tiers with distinct responsibilities. Each layer handles a specific aspect of the application and communicates only with the layer directly beneath it. This promotes separation of concerns, maintainability, testability, and scalability.

Core Concept

Layered architecture divides an application into vertically stacked, logically separate tiers. Each layer has a clearly defined responsibility and typically communicates only with the layer immediately below it. This prevents business logic, presentation, and data storage from becoming tangled.

The typical layers are:

Presentation Layer (UI): Displays data and captures user input. It contains no business logic.
Business Logic Layer: Houses domain logic, rules, and processes. Validation typically occurs here.
Data Access Layer: Handles reading and writing data, often through repositories or DAOs.
Infrastructure Layer: Provides cross-cutting concerns like logging, security, caching, and configuration.

Many designs also include a Service Layer acting as a façade between the UI and business logic, or a Domain Layer that shields core logic more rigorously.

Exam Essentials

Clear responsibility per layer: Each layer has a defined purpose and contains only code that belongs there.
Communicate only with adjacent layers: Layers should not skip over one another; they speak only to the layer directly below.
Separation of concerns: UI, logic, and data access are isolated, improving maintainability.
Supports testability: Each layer can be tested in isolation when accessed through interfaces.
Interchangeability: Layers can be replaced without affecting others, provided interfaces remain stable.
Common in professional certifications: Layered architecture is a classic exam topic and frequently required in project documentation.
Security: Validation, authentication, and authorization belong in the middle layers, not the UI.
DTOs: Data Transfer Objects move data between layers without exposing internal entities.
Error handling: Errors are handled in the layer best positioned to resolve them, or passed upward.
Documentation: A layer diagram with descriptions of each tier is essential in project documentation.
Cost efficiency: Clear layers reduce maintenance costs and ease onboarding of new team members.

Core Components

UI (Presentation Layer) The UI layer is the user-facing interface. It displays data, captures input, and passes it to the layer below. It contains only presentation and navigation logic, never business logic.
Business (Business Logic Layer) The business layer holds the core logic of the application. Business rules, calculations, and decisions are implemented here. Validation typically happens before data passes to the data access layer.
Data Access (Data Access Layer) The data access layer handles reading and writing data. It abstracts the database or other data sources through repositories or DAOs. The layer above it remains unaware of database technology details.
Infrastructure Infrastructure components are cross-cutting: logging, configuration, caching, encryption, messaging, and technical utilities. They can be used across all layers without entangling business logic.
DTOs (Data Transfer Objects) DTOs are simple objects that carry data between layers. They contain no logic and prevent internal entities or database models from leaking into the UI.
Validation Validation checks whether input conforms to business rules. It typically occurs in the business layer, supplemented by basic format checks in the UI layer.
Error Handling Each layer handles errors within its scope. Technical errors are often managed in the data access or infrastructure layer; business errors belong in the business layer. User-friendly messages emerge from the UI layer.
Service Layer The service layer provides a façade for business logic. It orchestrates multiple domain objects and exposes a well-defined interface to the UI layer.
Auth/AuthZ Authentication and authorization belong in the middle layers. The UI shows only what the user is permitted to see, but the decision to allow an operation is made in the business or service layer.
Build/Deploy Structure Layers can reflect the physical project structure. Separate projects or packages per layer clarify understanding and enforce architectural rules.

Practical Example: Booking System

The following example shows how a simple booking system can be structured using the layered pattern.

What does this show?

The UI layer captures a booking from the user and displays results.
The business layer validates the booking, checks seat availability, and calculates the price.
The data access layer persists the booking to the database and retrieves available seats.
The infrastructure layer logs the transaction and ensures only authorized users can book.

Why show this?

This example illustrates how data and responsibility flow through the layers. It demonstrates why the UI should never call the database directly and why validation belongs in the business layer. It also shows how DTOs can transport only necessary data between layers.

Booking System:

┌─────────────────────────────────────┐
│ UI Layer (React)                    │
│ → Input: Create booking             │
└──────────────┬──────────────────────┘
               │ DTO (BookingRequest)
               ▼
┌─────────────────────────────────────┐
│ Service Layer (Java Spring)         │
│ → Orchestration, auth check         │
└──────────────┬──────────────────────┘
               │
               ▼
┌─────────────────────────────────────┐
│ Business Layer (Java)               │
│ → Validation, price calculation     │
└──────────────┬──────────────────────┘
               │ DTO (BookingEntity)
               ▼
┌─────────────────────────────────────┐
│ Data Access Layer (JPA/Repository)  │
│ → Persist and retrieve booking      │
└─────────────────────────────────────┘

Strengths and Weaknesses

Strengths

Good testability: Each layer can be tested in isolation when it has stable interfaces.
Clear separation of concerns: UI, logic, data, and infrastructure are separate. This makes code easier to understand.
Better teamwork: Different teams can work in parallel on separate layers—frontend, backend, and database, for example.
Exchangeability: One layer can be swapped out without changing others, as long as interfaces remain the same.
Reusability: The business layer can be used with different UI technologies or clients.
Maintainability: Changes usually affect only one layer, which simplifies onboarding and debugging.

Weaknesses

Overhead on small projects: Simple applications may require too much structure and boilerplate code.
Performance losses: Each additional layer adds latency and mapping overhead, especially when converting many DTOs.
Rigidity: Strict enforcement can make cross-cutting concerns difficult to implement cleanly.
Complexity: Layer rules must be enforced and monitored, otherwise the codebase quickly becomes a mess.
Misplaced logic: When business logic drifts into the wrong layer, the model loses its benefits.

Free-Form Answers

For IHK projects, choose the layered model when you need to document an application with clearly separated responsibilities. Show a layer diagram, describe each layer in one sentence, and justify why the separation makes sense. Mention where validation, authentication, and error handling occur. For very small tools or prototypes, the layered model may add unnecessary overhead.

Learning Strategy

1. Sketch the layered model

Draw a layer diagram with UI, Service, Business, Data Access, and Infrastructure. Mark the allowed communication paths and note the responsibility of each layer.

2. Develop your own example

Take an example from your daily life, such as an online shop or a booking system. Think about which classes belong in which layer and which DTOs are transported between them.

3. Practice the rules

State the key rules of the layered model in your own words: “A layer only communicates with its direct neighbor.” “The UI contains no business logic.” “Validation belongs in the business layer.”

4. Analyze error examples

Find code samples where layers are mixed—for instance, SQL queries directly in the UI. Think about how you would refactor the code to follow the layered model.

5. Walk through an exam scenario

Imagine an exam question: “Justify the choice of a layered model for a booking system.” Write an answer that addresses separation of concerns, testability, and maintainability.

Topic Analysis

Technical core: Layers, DTOs, interfaces, validation, error handling, service layer
Challenges: Avoiding layer mixing, balancing strictness with flexibility, overhead in small projects
Security: Authentication, authorization, and validation in the middle layers
Documentation: Layer diagram, layer descriptions, justification for architectural choices
Economics: Maintainability, parallel development, exchangeability, reduced change costs

FAQ: Layered Model and Layered Architecture

1. What is a layered model?

A layered model divides an application into stacked, logically separate layers. Each layer has its own responsibility and typically communicates only with the layer directly beneath it.

2. What is Layered Architecture?

Layered Architecture is an architectural pattern that divides an application into horizontal layers. It is one of the most commonly used patterns in software development.

3. What layers typically exist?

Typical layers are Presentation, Business Logic, Data Access, and Infrastructure. Depending on the variant, there may also be a Service Layer or a Domain Layer.

4. What is the role of the Presentation Layer?

The Presentation Layer displays data and captures user input. It contains no business logic, only presentation and navigation logic.

5. What is the role of the Business Logic Layer?

The Business Logic Layer contains domain logic, business rules, calculations, and validations. It is the heart of the application.

6. What is the role of the Data Access Layer?

The Data Access Layer handles reading and writing data. It abstracts the database or other data sources, for example through Repositories or DAOs.

7. What is the role of the Infrastructure Layer?

The Infrastructure Layer provides cross-cutting concerns such as Logging, Caching, Configuration, Encryption, and Messaging.

8. What is a Service Layer?

A Service Layer is an additional layer between the UI and business logic. It orchestrates multiple business processes and provides the UI with a clearly defined interface.

9. What is a DTO?

A DTO (Data Transfer Object) is a simple object that carries data between layers. It contains no logic and prevents internal entities from being exposed to the UI.

10. What does separation of concerns mean?

Separation of concerns means that different aspects of an application—such as presentation, logic, and data access—are split into separate components. This reduces coupling and complexity.

11. Which layers may communicate with each other?

In the classic layered model, a layer communicates only with its direct neighbor below it. This prevents dependencies from sprawling across the system.

12. What happens when layers are mixed?

When layers are mixed, spaghetti code emerges quickly. The application becomes harder to test, maintain, and replace.

13. Where does validation belong?

Business validation belongs in the Business Logic Layer. The UI Layer can perform basic format checks, but must not enforce business rules.

14. Where does authentication belong?

Authentication and authorization belong in the middle layers—the Service or Business Layer. The UI only displays what a user can see; the decision about permissions is made centrally.

15. What is a Repository?

A Repository is a pattern from the Data Access Layer. It encapsulates access to the data source and provides the Business Logic Layer with a clean interface for reading and writing data.

16. What is a DAO?

A DAO (Data Access Object) is an object that encapsulates access to a database or other data source. It is a similar pattern to the Repository.

17. Why is the layered model testable?

Each layer can be tested in isolation when it has stable interfaces. The Data Access Layer can be replaced with a Fake or Mock to test the Business Logic.

18. Why is the layered model maintainable?

Changes usually affect only one layer. If you replace the UI, you do not need to adjust the business logic. If you switch databases, you stay within the Data Access Layer.

19. When is the layered model not appropriate?

For very small projects, simple scripts, or prototypes, the layered model can introduce unnecessary overhead and boilerplate code.

20. What is a layer diagram?

A layer diagram shows the layers of an application as stacked blocks and the allowed communication paths between them. It is an important documentation tool.

21. What is the difference between layers and tiers?

Layers describe the logical separation within an application. Tiers describe the physical distribution across different machines or networks—for example, Client, Server, and Database.

22. What is a Domain Layer?

A Domain Layer is an additional layer that protects pure business logic especially well. It contains Entities, Value Objects, and Domain Services, independent of technology and UI.

23. What is Hexagonal Architecture?

Hexagonal Architecture, also called Ports and Adapters, is a variant of the layered model. It separates application logic in the center from external adapters like UI, Database, or Messaging.

24. What is the Onion Model?

The Onion Model is another variant of the layered model. Domain logic sits at the center, and all other layers—Infrastructure and UI—are outer rings that depend on it.

25. What should project documentation about the layered model include?

Documentation should include a layer diagram, the responsibility of each layer, the allowed communication paths, and a justification for choosing this model. Security aspects such as validation and authorization should also be covered.