Запропонувати правкуПокращити цю статтюДопрацюйте відповідь до «Що являє собою шарувата архітектура?». Ваші зміни проходять модерацію перед публікацією.Потрібне підтвердженняКонтентЩо ви змінюєте🇺🇸EN🇺🇦UAПереглядЗаголовок (UA)Коротка відповідь (UA)**Шарувата архітектура (Layered Architecture)** - один із класичних підходів до проектування програмних систем, при якому застосунок ділиться на логічні рівні (шари), кожен з яких виконує строго визначені функції і взаємодіє лише з сусідніми шарами. **Ключове:** кожен шар знає тільки про найближчий нижній, що забезпечує незалежність шарів, можливість підміняти реалізацію і легкість тестування.Показується над повною відповіддю для швидкого нагадування.Відповідь (UA)Зображення**Шарувата архітектура (Layered Architecture)** - це один із класичних підходів до проектування програмних систем, при якому застосунок ділиться на **логічні рівні (шари)**, кожен з яких виконує строго визначені функції і взаємодіє тільки з сусідніми шарами. --- ### Основна ідея Система розбивається на **ієрархію рівнів**, де: - верхні шари використовують функціональність нижніх, - нижні не знають про верхні, - кожен шар вирішує задачі **свого рівня абстракції**. Це створює **структуровану, керовану** архітектуру з чіткими межами відповідальності. --- ### Класична структура шаруватої архітектури Зазвичай виділяють 4 основні шари: 1. **Presentation (представлення / UI)** Відповідає за взаємодію з користувачем чи зовнішніми системами. Приклади: вебінтерфейс, API, мобільний застосунок. Основна задача - відобразити дані і передати дії користувача далі. 2. **Application (прикладний / сервісний шар)** Містить бізнес-логіку на рівні процесів і сценаріїв. Приклад: координує кроки "створити замовлення", "оплатити", "надіслати сповіщення". Тут немає деталей зберігання чи UI. 3. **Domain (доменна логіка / бізнес-правила)** Серце системи: бізнес-об'єкти, правила, інваріанти. Приклад: клас `Order`, правило "замовлення не можна оплатити двічі". Ізольований від інфраструктури. 4. **Infrastructure (інфраструктура / дані)** Забезпечує взаємодію із зовнішнім світом: БД, мережа, файли. Приклад: репозиторії, драйвери, зовнішні API. Слугує "опорою" для верхніх шарів. --- ### Принцип взаємодії Кожен шар знає **тільки про найближчий нижній**: `UI -> Application -> Domain -> Infrastructure` Це забезпечує: - незалежність шарів; - можливість підміняти реалізацію; - легкість тестування (наприклад, можна підмінити шар даних моками). --- ### Переваги - **Модульність** і читабельність коду. - **Тестованість**: можна перевіряти кожен шар ізольовано. - **Розширюваність**: можна змінювати технологію БД чи UI, не торкаючись логіки. - **Повторне використання**: доменна логіка не залежить від інтерфейсів. --- ### Недоліки - Можлива **зайва складність** для простих застосунків. - Можуть з'являтися **надлишкові переходи між шарами** ("балаканина шарів"). - Порушення меж (наприклад, якщо UI напряму лізе в базу) призводять до **архітектурної деградації**. - При великій кількості рівнів - **втрати продуктивності**. --- ### Приклад Інтернет-магазин: - **UI** - React-застосунок, що показує кошик. - **Application** - сервіс замовлень: викликає методи доменної логіки і звертається до репозиторіїв. - **Domain** - об'єкт `Order` з методами `addItem()`, `calculateTotal()`. - **Infrastructure** - реалізація `OrderRepository`, що зберігає дані в PostgreSQLДля рев’юераПримітка для модератора (необов’язково)Бачить лише модератор. Прискорює рев’ю.