Выбор ответа Middle Clean Architecture и слои обновлено
Когда use case полезен
Вопрос
В каком случае отдельный use case (interactor) действительно оправдан?
Попробуйте сами
Выберите вариант, и откроется разбор.
Показать ответ и разбор
Коротко
Правильный ответ: Когда он объединяет несколько репозиториев или содержит бизнес-правило для разных экранов. Use case-прокладка GetUserUseCase с одной строкой repo.getUser() добавляет файл и ничего не даёт.
Варианты ответа
- Всегда, даже если он только вызывает один метод репозитория: без этого нарушается Clean Architecture
- Только для сетевых запросов, чтобы view model не знала о Retrofit или URLSession
- Никогда: бизнес-логика должна жить во view model, а use case это лишняя прослойка
- Когда он объединяет несколько репозиториев или содержит бизнес-правило для разных экрановправильный ответ
Разбор
Use case-прокладка GetUserUseCase с одной строкой repo.getUser() добавляет файл и ничего не даёт. Ценность появляется, когда в нём бизнес-правило (рассчитать скидку, проверить лимиты) или координация нескольких источников, и это нужно в нескольких местах. Многие команды разрешают view model вызывать репозиторий напрямую, а use case заводят по необходимости. Официальный гайд Android называет domain-слой опциональным.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.
Ещё по теме «Clean Architecture и слои»
- Правило зависимостей в Clean Architecture
- Что можно импортировать в domain-слой
- Зачем маппить DTO в доменные модели
- Ошибки на границах слоёв
- Пакеты по слоям или по фичам
- Инверсия зависимостей
- Слои мобильного приложения
- Сколько моделей нужно на сущность