Suggest an editImprove this articleRefine the answer for “How does Clean Architecture differ from Layered Architecture?”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)The difference between **Clean Architecture** and classic **Layered Architecture** is not the number of layers, but the direction of dependencies, the principles of logic isolation, and scalability: in Layered, dependencies flow top-down (UI → DB), while in Clean they always point inward, toward business logic. **Key point:** in Layered, replacing a framework or database is painful and expensive; in Clean it is painless, because business logic defines interfaces and infrastructure implements them.Shown above the full answer for quick recall.Answer (EN)ImageThe difference between **Clean Architecture** and classic **Layered Architecture** is not just the number of layers, but the **direction of dependencies**, the **principles of logic isolation**, and the project's **scalability**. Below is a clear, systematic comparison: --- ### 1. **Layered Architecture** **Classic scheme:** ```javascript UI → Application → Domain → Infrastructure ``` **The essence:** - The program is split into layers by "technical" purpose. - Dependencies point **top-down**: the UI knows about business logic, and business logic knows about infrastructure (for example, databases). - Upper layers depend on lower ones. **The main idea:** Each layer handles its own concern (interface, business logic, data access), but **upper layers are tied to lower ones**. **Downsides:** - Hard to test business logic without infrastructure. - Replacing the database or framework requires cascading changes. - As the project grows, isolation breaks down: business logic starts "knowing" about technologies. --- ### 2. **Clean Architecture** **Robert Martin's (Uncle Bob's) scheme:** ```javascript Entities Use Cases Interface Adapters Frameworks & Drivers ``` **Main rule:** **Dependencies point inward**, from outer to inner. Inner layers **know nothing** about outer ones. **Key principles:** - Business rules (Entities, Use Cases) do not depend on UI, DB, or frameworks. - Everything external (web, database, API, UI) is plugged in through interfaces and dependency injection. - Any framework can be replaced without touching the core logic. **Advantages:** - Maximum testability: domain tests can run without any environment. - Easy technology swaps (UI, ORM, API, etc.). - Business logic stays "clean": it contains no framework-world code. --- ### 3. **Key differences** | Criterion | Layered Architecture | Clean Architecture | |---|---|---| | **Direction of dependencies** | Top-down (UI → DB) | Inward (from outer to core) | | **Awareness of frameworks** | Inside business logic | Only in outer layers | | **Testability** | Complex, requires infrastructure | Simple, core is isolated | | **Center of the system** | Technical layers (UI, DB) | Business logic and use cases | | **Replacing a framework** | Painful and expensive | Painless | | **SOLID principles** | Partially | Fully | | **Typical dependency** | Domain depends on Data | Data depends on Domain | --- ### 4. **Example:** If in **Layered Architecture** business logic calls the `UserRepository` repository, then in **Clean Architecture** business logic **defines the** `UserRepository` **interface**, and infrastructure **implements** it. --- ### 5. **Summary:** - **Layered**: simple, convenient for small applications, but fragile as they grow. - **Clean**: harder to start with, but scales and allows changing technologies without painFor the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.