Чисту архітектуру, яку запропонував Роберт С. Мартін (Uncle Bob), визначає чітка структура організації програмних систем. Її основною метою є створення систем, незалежних від фреймворків, інтерфейсів користувача, баз даних чи будь-яких зовнішніх служб. Така незалежність дозволяє легко тестувати, забезпечує гнучкість та адаптованість. Але часто постає питання: Чи завжди потрібно включати інфраструктурні та постійні шари у дизайн чистої архітектури?
Відповідь на це питання залежить від розуміння ролі цих шарів в архітектурі та характеру розробленої програми.
Мета інфраструктурного та постійного шарів
1. Інфраструктурний шар
Інфраструктурний шар відповідає за реалізацію низькорівневих деталей системи, таких як взаємодія з зовнішніми системами, фреймворками чи бібліотеками. Прикладами є HTTP-клієнти, файлові системи та зовнішні API.
Ключові ролі:
- Абстрагування зовнішніх залежностей.
- Надання реалізацій інтерфейсів, визначених у доменних чи додатних шарах.
- Обробка комунікації між зовнішніми системами та основною частиною програми.
2. Постійний шар
Постійний шар відповідає за обробку довгострокового зберігання даних. Цей шар взаємодіє з базами даних, кешами чи іншими механізмами зберігання даних.
Ключові ролі:
- Керування життєвим циклом сутностей даних.
- Забезпечення консистентності та цілісності даних.
- Надання моста між доменними моделями та їх зберіганням.
Чому ці шари важливі?
Розподіл обов'язків
Чиста архітектура наголошує на важливості відокремлення бізнес-логіки від зовнішніх факторів. Без інфраструктурного та постійного шарів зовнішні залежності можуть потрапити в основні шари, що порушить цей принцип і ускладнить підтримку та тестування системи.
Тестування та мокінг
Маючи інфраструктурні та постійні обов'язки в окремих шарах, простіше замінити або змокати їх під час тестування. Наприклад, інтерфейс репозиторію можна змокати для симуляції поведінки бази даних без реальної бази.
Гнучкість та підтримуваність
Якщо ваша програма зростає або змінюється, наявність окремих шарів дозволяє замінювати чи оновлювати компоненти без впливу на основну логіку. Наприклад:
- Перехід від SQL до NoSQL.
- Замінити одного постачальника хмарних послуг на іншого.
Коли можна пропустити ці шари?
Хоча інфраструктурні та постійні шари корисні в більшості випадків, є сценарії, де їх явна реалізація може бути непотрібною:
- Прості додатки:
- Для малих проєктів або прототипів додавання цих шарів може ввести непотрібну складність. Безпосередня взаємодія з фреймворками чи базами даних може бути більш практичною.
2. Відсутність зовнішніх залежностей:
- Якщо ваш додаток не взаємодіє із зовнішніми системами або не потребує постійного зберігання даних, ці шари можуть бути надмірними.
3. Одинична відповідальність:
- Для мікросервісів або окремих утиліт, що виконують лише одну задачу, ви можете виявити, що ці шари є зайвими.
Найкращі практики використання цих шарів
Якщо ви вирішили включити інфраструктурні та постійні шари до вашої програми, дотримуйтесь наступних найкращих практик:
- Визначте інтерфейси в основних шарах:
- Завжди визначайте інтерфейси (наприклад,
IRepository,IStorageService) в доменному або додатному шарі та реалізуйте їх в інфраструктурному шарі.
2. Покладайтесь на абстракції:
- Використовуйте ін'єкцію залежностей для того, щоб ваші основні шари залежали лише від абстракцій, а не від конкретних реалізацій.
3. Утримуйте шари від зв'язування:
- Уникайте жорсткої прив'язки між основною логікою та інфраструктурними/постійними шарами. Це забезпечить їх незалежність і тестованість.
4. Використовуйте шари доцільно:
- Не ускладнюйте архітектуру, створюючи шари, які не виконують чіткої ролі.
Висновок
Інфраструктурні та постійні шари є важливими компонентами чистої архітектури в більшості випадків.
Вони допомагають зберігати розподіл обов'язків, забезпечують тестованість і надають гнучкість для майбутніх змін. Однак їх необхідність залежить від складності та масштабу програми. У малих чи простих програмах можна обійтися без цих шарів заради спрощення. У кінцевому підсумку рішення має ґрунтуватися на принципі проектування систем, які легко змінювати, тестувати та підтримувати.
Перекладено з: Do We Need Infrastructure and Persistent Layers in Clean Architecture?