What is layered architecture?

Layered Architecture is one of the classic approaches to designing software systems, in which an application is split into logical levels (layers), each performing strictly defined functions and interacting only with neighboring layers.

---

#The core idea

The system is broken down into a hierarchy of levels, where:

• the upper layers use the functionality of the lower ones,
• the lower ones do not know about the upper ones,
• each layer handles tasks at its own level of abstraction.

This creates a structured, manageable architecture with clear boundaries of responsibility.

---

#The classic structure of layered architecture

Typically, 4 main layers are distinguished:

1. Presentation (UI) Handles interaction with the user or external systems. Examples: a web interface, an API, a mobile app. The main task is to display data and pass the user's actions further on.
2. Application (application / service layer) Contains business logic at the level of processes and scenarios. Example: coordinates steps such as "create an order", "pay", "send a notification". There are no storage or UI details here.
3. Domain (domain logic / business rules) The heart of the system: business objects, rules, invariants. Example: the Order class, the rule "an order cannot be paid twice". Isolated from infrastructure.
4. Infrastructure (infrastructure / data) Handles interaction with the outside world: the database, network, files. Example: repositories, drivers, external APIs. Serves as the "foundation" for the upper layers.

---

#The interaction principle

Each layer only knows about the nearest layer below it: UI -> Application -> Domain -> Infrastructure

This provides:

• independence between layers;
• the ability to swap an implementation;
• ease of testing (for example, the data layer can be replaced with mocks).

---

#Advantages

• Modularity and readable code.
• Testability: each layer can be checked in isolation.
• Extensibility: the database or UI technology can be changed without touching the logic.
• Reuse: the domain logic does not depend on the interfaces.

---

#Disadvantages

• Possible unnecessary complexity for simple applications.
• Excessive transitions between layers can appear ("layer chatter").
• Boundary violations (for example, if the UI reaches directly into the database) lead to architectural degradation.
• With a large number of levels, there can be performance losses.

---

#Example

An online store:

• UI - a React application showing the cart.
• Application - the order service: calls the domain logic's methods and reaches out to the repositories.
• Domain - the Order object with addItem() and calculateTotal() methods.
• Infrastructure - the OrderRepository implementation, which stores data in PostgreSQL