Suggest an editImprove this articleRefine the answer for “What is layered architecture?”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)**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. **Key point:** each layer only knows about the nearest layer below it, which provides independence between layers, the ability to swap implementations, and ease of testing.Shown above the full answer for quick recall.Answer (EN)Image**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 PostgreSQLFor the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.