Что такое Use Case в контексте архитектуры Flutter-приложения?

«Что такое Use Case в контексте архитектуры Flutter-приложения?» — вопрос из категории Архитектура, который задают на 29% собеседований Flutter Разработчик. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

В архитектуре Flutter-приложения, например, при использовании Clean Architecture, Use Case (или Interactor) — это класс, который инкапсулирует одну конкретную бизнес-правило или действие. Он находится в слое домена и координирует поток данных между репозиториями (данные) и презентерами/блоками (UI).

Пример Use Case для аутентификации пользователя:

// domain/use_cases/login_user_use_case.dart
import '../repositories/auth_repository.dart';

class LoginUserUseCase {
  final AuthRepository _authRepository;

  LoginUserUseCase(this._authRepository);

  // Выполняет конкретное бизнес-действие
  Future<void> execute({required String email, required String password}) async {
    // Валидация может быть здесь или в отдельном ValueObject
    if (email.isEmpty || password.isEmpty) {
      throw const FormatException('Email and password cannot be empty');
    }
    // Делегируем фактическую логику аутентификации репозиторию
    await _authRepository.login(email: email, password: password);
  }
}

Как это используется в слое презентации (например, с Bloc):

// presentation/login/bloc/login_bloc.dart
class LoginBloc extends Bloc<LoginEvent, LoginState> {
  final LoginUserUseCase _loginUserUseCase;

  LoginBloc(this._loginUserUseCase) : super(LoginInitial()) {
    on<LoginButtonPressed>((event, emit) async {
      emit(LoginLoading());
      try {
        await _loginUserUseCase.execute(
          email: event.email,
          password: event.password,
        );
        emit(LoginSuccess());
      } catch (e) {
        emit(LoginFailure(error: e.toString()));
      }
    });
  }
}

Преимущества такого подхода:

  • Чистое разделение ответственности: UI не знает, откуда берутся данные (сеть, локальная БД).
  • Простота тестирования: Use Case можно легко протестировать, подменив AuthRepository моком.
  • Повторное использование: Одна бизнес-логика может быть использована в разных местах приложения (например, в мобильном и веб-интерфейсе).
  • Ясность: Каждый Use Case соответствует одной пользовательской истории.