Запропонувати правкуПокращити цю статтюДопрацюйте відповідь до «Чим Clean Architecture відрізняється від Layered Architecture?». Ваші зміни проходять модерацію перед публікацією.Потрібне підтвердженняКонтентЩо ви змінюєте🇺🇸EN🇺🇦UAПереглядЗаголовок (UA)Коротка відповідь (UA)Відмінність **Clean Architecture** від класичної **Layered Architecture** - не в кількості шарів, а в напрямку залежностей, принципах ізоляції логіки і масштабованості проєкту: у Layered залежності йдуть зверху вниз (UI → DB), а в Clean - завжди всередину, до бізнес-логіки. **Ключове:** у Layered заміна фреймворка чи бази - боляче і дорого, у Clean - безболісно, бо бізнес-логіка визначає інтерфейси, а інфраструктура їх реалізує.Показується над повною відповіддю для швидкого нагадування.Відповідь (UA)ЗображенняВідмінність **Clean Architecture** від класичної **Layered Architecture (багатошарової архітектури)** - не просто в кількості шарів, а в **напрямку залежностей**, **принципах ізоляції логіки** і **масштабованості проєкту**. Нижче - чітке, системне порівняння: --- ### 1. **Layered Architecture (багатошарова)** **Класична схема:** ```javascript UI → Application → Domain → Infrastructure ``` **Суть:** - Програма ділиться на рівні за "технічним" призначенням. - Залежності спрямовані **зверху вниз**: UI знає про бізнес-логіку, бізнес-логіка знає про інфраструктуру (наприклад, бази даних). - Верхні рівні залежать від нижніх. **Головна ідея:** Кожен шар відповідає за своє завдання - інтерфейс, бізнес-логіка, доступ до даних, але **верхні шари прив'язані до нижніх**. **Мінуси:** - Важко тестувати бізнес-логіку без інфраструктури. - Заміна БД чи фреймворка вимагає каскадних змін. - З ростом проєкту порушується принцип ізоляції: бізнес-логіка починає "знати" про технології. --- ### 2. **Clean Architecture (чиста архітектура)** **Схема Роберта Мартіна (Uncle Bob):** ```javascript Entities Use Cases Interface Adapters Frameworks & Drivers ``` **Головне правило:** **Залежності спрямовані всередину** - від зовнішнього до внутрішнього. Внутрішні шари **не знають** про зовнішні. **Ключові принципи:** - Бізнес-правила (Entities, Use Cases) не залежать від UI, БД чи фреймворків. - Усе зовнішнє (веб, база, API, UI) підключається через інтерфейси та ін'єкцію залежностей. - Будь-який фреймворк можна замінити, не торкаючись ядра логіки. **Переваги:** - Максимальна тестованість - доменні тести можна запускати без оточення. - Легка зміна технологій (UI, ORM, API тощо). - Бізнес-логіка "чиста": у ній немає коду зі світу фреймворків. --- ### 3. **Ключові відмінності** | Критерій | Layered Architecture | Clean Architecture | |---|---|---| | **Напрямок залежностей** | Зверху вниз (UI → DB) | Всередину (від зовнішнього до ядра) | | **Знання про фреймворки** | Усередині бізнес-логіки | Лише на зовнішніх шарах | | **Тестованість** | Складна, потребує інфраструктури | Проста, ядро ізольоване | | **Центр системи** | Технічні шари (UI, DB) | Бізнес-логіка і use cases | | **Заміна фреймворка** | Боляче і дорого | Безболісно | | **Принципи SOLID** | Частково | Повною мірою | | **Типова залежність** | Domain залежить від Data | Data залежить від Domain | --- ### 4. **Приклад:** Якщо в **Layered Architecture** бізнес-логіка викликає репозиторій `UserRepository`, то в **Clean Architecture** бізнес-логіка **визначає інтерфейс** `UserRepository`, а інфраструктура **реалізує** його. --- ### 5. **Підсумок:** - **Layered** - проста, зручна для невеликих застосунків, але крихка при рості. - **Clean** - складніша на старті, але масштабується і дозволяє змінювати технології без болюДля рев’юераПримітка для модератора (необов’язково)Бачить лише модератор. Прискорює рев’ю.