Як упроваджується DI в Clean Architecture?
У Clean Architecture упровадження залежностей (Dependency Injection, DI) - це спосіб реалізувати Dependency Rule на практиці: внутрішні шари визначають абстракції, а зовнішні - передають їм конкретні реалізації.
1. Принцип
Бізнес-логіка (use cases, entities) не створює залежності сама. Усе, що їй потрібно, передається ззовні.
Це дозволяє внутрішньому коду працювати з інтерфейсами, не знаючи, який саме репозиторій, API чи сервіс під капотом.
2. Як це виглядає за шарами
Внутрішній шар (Use Case)
Визначає інтерфейси, але не знає реалізацію:
class OrderRepository(Protocol):
def save(self, order): ...Зовнішній шар (Adapter / Infrastructure)
Реалізує ці інтерфейси:
class SqlOrderRepository(OrderRepository):
def save(self, order):
db.insert(order)Точка збирання (Composition Root)
Десь зовні (наприклад, у main.py) залежності пов'язуються:
def main():
repo = SqlOrderRepository()
use_case = CreateOrderUseCase(order_repo=repo)
controller = OrderController(use_case)Так use case отримує готову залежність, не створюючи її всередині себе.
3. Де відбувається впровадження
Впровадження завжди виконується на зовнішньому рівні:
- У веб-застосунку - у контролері або DI-контейнері (FastAPI, Spring, NestJS).
- У CLI - у точці запуску (
main()). - У тестах - через мок-об'єкти.
4. Навіщо це потрібно
- Дотримується Dependency Rule (внутрішній шар не залежить від зовнішнього).
- Спрощує тестування (можна підставляти моки).
- Дозволяє легко змінювати реалізацію (наприклад, перейти з SQL на NoSQL).
- Робить архітектуру розширюваною і гнучкою.
Підсумок:
У Clean Architecture залежності впроваджуються ззовні всередину, через конструктори, DI-контейнери або функції ініціалізації, щоб бізнес-логіка залежала лише від абстракцій, а не від конкретних реалізацій.
Коротка відповідь
Для співбесідиКоротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.