UseCase - Feelynx/flutter_clean_architecture GitHub Wiki

The UseCase class represents the business logic of the application within the Clean Architecture pattern. Use Cases define the actions that can be performed in the application, leveraging the repositories to interact with data sources, and ensuring that business rules are applied correctly. In Clean Architecture, the domain layer is where Use Cases operate, decoupling the business logic from the data access layers and presentation logic.

• Orchestrate Business Logic: Use Cases encapsulate business rules and logic, ensuring that domain rules are applied consistently.
• Repository Interaction: Use Cases interact with repositories to fetch and manipulate data, returning entities back to the presentation layer.
• Error Handling: They manage the flow of data and handle potential errors or failures that may arise during repository interactions.

In this example, AuthUseCases defines several methods related to user authentication and session management, such as obtaining or refreshing user sessions and managing local authentication tokens. The use case class interacts with both AuthRepository (for remote operations) and AuthLocalRepository (for local data operations).

class AuthUseCases {
  final AuthRepository _authRepository;
  final AuthLocalRepository _authLocalRepository;

  const AuthUseCases(this._authRepository, this._authLocalRepository);

  Future<ResponseWrapper<UserSessionResponseEntity>> getUserSession(
    UserSessionRequestEntity authRequestEntity,
  ) {
    return _authRepository.getUserSession(authRequestEntity);
  }

  Future<ResponseWrapper<RefreshUserSessionResponseEntity>> refreshUserSession(
    RefreshUserSessionRequestEntity refreshTokenRequestEntity,
  ) {
    return _authRepository.refreshUserSession(refreshTokenRequestEntity);
  }

  Future<void> setLocalAuthToken(UserSessionResponseEntity auth) {
    return _authLocalRepository.setLocalUserSession(auth);
  }

  Future<ResponseWrapper<UserSessionResponseEntity>> getLocalUserSession() {
    return _authLocalRepository.getLocalUserSession();
  }

  Future<void> clearLocalSession() {
    return _authLocalRepository.clearLocalSession();
  }
}

In this implementation:

• The AuthUseCases class coordinates between the AuthRepository and AuthLocalRepository to execute domain-specific logic.
• It handles operations like getting or refreshing user sessions, storing the session locally, and clearing the local session when needed.
• The class centralizes the business logic for authentication, ensuring consistent behavior across the application.

Although not strictly necessary, you may optionally define an abstract UseCase class to standardize the structure of all use cases in the application. This abstract class can define a method for executing a use case, ensuring that all use cases follow a consistent pattern.

abstract class UseCase<Type, Params> {
  Future<Type> execute(Params params);
}

In this abstract class:

• The Type represents the return type of the use case (e.g., an entity or a response wrapper).
• The Params represent the parameters required by the use case to execute.
• Concrete use cases would implement the execute method, ensuring that business logic is encapsulated within each use case.

A specific use case, such as GetUserSessionUseCase, could extend this abstract class to implement its business logic.

class GetUserSessionUseCase extends UseCase<ResponseWrapper<UserSessionResponseEntity>, UserSessionRequestEntity> {
  final AuthRepository _authRepository;

  GetUserSessionUseCase(this._authRepository);

  @override
  Future<ResponseWrapper<UserSessionResponseEntity>> execute(UserSessionRequestEntity params) {
    return _authRepository.getUserSession(params);
  }
}

The UseCase class encapsulates business logic in the domain layer, interacting with repositories to enforce rules and coordinate data operations. While the abstract UseCase class is optional, it provides a consistent structure for managing the execution of business logic across different parts of the application. This pattern ensures that the business rules are kept separate from data and presentation concerns, following the principles of Clean Architecture.