Что размещается в UseCase в Clean Architecture
Комментарии (3)
Ответ сгенерирован нейросетью и может содержать ошибки
Роль UseCase в Clean Architecture
В Clean Architecture (предложенной Робертом Мартином) UseCase (или Interactor) — это центральный элемент бизнес-логики, который инкапсулирует конкретное правило или сценарий использования приложения. Он представляет собой абстракцию над действием, которое может выполнить пользователь или система, например: «Оформить заказ», «Получить прогноз погоды» или «Аутентифицировать пользователя».
Что размещается в UseCase?
-
Чистая бизнес-логика – правила, уникальные для вашего приложения, без зависимостей от фреймворков, UI или инфраструктуры. Например, проверка условий, вычисления, принятие решений.
class TransferMoneyUseCase( private val repository: AccountRepository ) { suspend operator fun invoke( fromAccountId: String, toAccountId: String, amount: Double ): Result<Transaction> { // 1. Валидация суммы (бизнес-правило) if (amount <= 0) return Result.failure(InvalidAmountError()) // 2. Получение данных через репозиторий (абстракция) val fromAccount = repository.getAccount(fromAccountId) val toAccount = repository.getAccount(toAccountId) // 3. Проверка достаточности средств (бизнес-правило) if (fromAccount.balance < amount) { return Result.failure(InsufficientFundsError()) } // 4. Выполнение перевода (ядро операции) val transaction = repository.transferFunds( fromAccountId, toAccountId, amount ) // 5. Возврат результата return Result.success(transaction) } } -
Оркестрация потоков данных – UseCase управляет последовательностью шагов: получение данных из репозиториев, их преобразование, применение правил, возврат результата.
-
Инварианты и валидации – проверки, обеспечивающие корректность бизнес-операции (например, «сумма перевода должна быть положительной»).
-
Обработка ошибок – преобразование исключений инфраструктуры в доменные ошибки, понятные на уровне бизнес-логики.
Что НЕ размещается в UseCase:
- UI-логика – взаимодействие с View, Activity, Fragment, Compose.
- Детали инфраструктуры – прямой доступ к базе данных, сети, файловой системе.
- Фреймворковые зависимости – Android-контекст, Intent, Bundle.
- Презентационная логика – форматирование данных для отображения.
Структура и зависимости:
UseCase следует правилу зависимостей Clean Architecture: зависимости направлены внутрь, к ядру. UseCase зависит только от внутренних слоёв (Domain), но не от внешних (Data, Presentation).
Presentation → Domain ← Data
↓ ↓
ViewModel Repository
↓ ↓
UseCase ←──┘
Ключевые принципы:
- Single Responsibility – каждый UseCase отвечает за одну бизнес-операцию.
- Testability – благодаря зависимости от интерфейсов (репозиториев), UseCase легко тестировать моками.
- Independence – UseCase не знает, кто его вызывает (ViewModel, Service, другой UseCase).
- Reusability – один UseCase может использоваться в разных сценариях (например, из UI и push-уведомления).
Практический пример в Android:
// Доменный слой
interface UserRepository {
suspend fun getUser(id: String): User?
}
class GetUserProfileUseCase(
private val repository: UserRepository
) {
suspend operator fun invoke(userId: String): UserProfile {
val user = repository.getUser(userId)
?: throw UserNotFoundException()
// Бизнес-правило: проверка активации профиля
if (!user.isActive) {
throw UserNotActiveException()
}
return UserProfile(
id = user.id,
name = user.name,
email = user.email
// Преобразование данных на уровне домена
)
}
}
// Использование во ViewModel (Presentation слой)
class ProfileViewModel(
private val getUserProfile: GetUserProfileUseCase
) : ViewModel() {
fun loadProfile(userId: String) {
viewModelScope.launch {
try {
val profile = getUserProfile(userId)
_state.value = ProfileState.Success(profile)
} catch (e: Exception) {
_state.value = ProfileState.Error(e)
}
}
}
}
Итог: UseCase в Clean Architecture — это чистый, фреймворк-независимый класс, который инкапсулирует конкретное бизнес-правило или операцию. Он получает данные через интерфейсы репозиториев, выполняет логику домена и возвращает результат, оставаясь полностью изолированным от деталей реализации UI и инфраструктуры. Это делает его наиболее стабильным и тестируемым компонентом архитектуры.