Clean Architecture: Use Cases in Android

🎯 The Role of the Use Case

In Clean Architecture, the Use Case (Interactor) encapsulates a single, specific business rule. It sits between the ViewModel (Presentation) and the Repository (Data).

Why Do We Need It?

1. Reusability: GetUserProfile can be called from ProfileViewModel, SettingsViewModel, and OrderViewModel.
2. Testability: Testing pure business logic without mocking ViewModels or Repositories.
3. Encapsulation: Hides complex data fetching logic (e.g., fetch from API, save to DB, transform data) from the UI.

🏗️ Implementation Structure

A Use Case should do one thing and do it well.

1. Functional Interface (Invoke Operator)

By overriding operator fun invoke, the Use Case can be called like a function.

class GetUserUseCase @Inject constructor(
    private val userRepository: UserRepository
) {
    operator fun invoke(userId: String): Flow<Result<User>> {
        return userRepository.getUser(userId)
            .map { ... } // Transform data for UI if needed
    }
}

2. ViewModel Usage

The ViewModel injects the Use Case, not the Repository.

@HiltViewModel
class ProfileViewModel @Inject constructor(
    private val getUserUseCase: GetUserUseCase
) : ViewModel() {

    fun loadProfile() {
        getUserUseCase("123").collect { ... }
    }
}

⚠️ Common Pitfalls

1. Anemic Use Cases: A Use Case that just forwards the call to Repository.
   • Is it bad? Not necessarily. It maintains consistency. But if 90% are anemic, consider skipping Use Cases for simple CRUD.
2. God Use Cases: UserManagerUseCase handling login, logout, profile, settings. Split it up!

🏁 Conclusion

Use Cases are the “verbs” of your application (Login, GetProfile, BuyItem). They define what your app does, independent of how it shows it or where it stores data.