Use Cases and Domain Layers: Are They Necessary?

A use case (also called an interactor) is a class that performs one business operation, such as "place order" or "get visible articles", typically by combining repositories and applying rules. Use cases can make code clearer and more reusable, or they can be empty wrappers that double the number of files without adding meaning.

The three-question test

Create a use case when at least one of these is true:

1. Real business logic exists beyond fetching data: rules, calculations or validation that the product team would describe ("orders over ₹500 get free delivery unless…").
2. Reuse: the same logic is needed by several ViewModels, a widget, a notification handler or a worker.
3. Combination: the operation coordinates several repositories, such as user + cart + pricing.

If none apply, call the repository directly from the ViewModel.

Writing a good use case

data class DeliveryQuote(val feePaise: Long, val freeDeliveryShortfallPaise: Long)

class CalculateDeliveryFeeUseCase @Inject constructor(
    private val cartRepository: CartRepository,
    private val userRepository: UserRepository,
) {
    /** Free delivery above ₹500 for regular users; always free for members. */
    operator fun invoke(): Flow<DeliveryQuote> =
        combine(cartRepository.observeCart(), userRepository.observeUser()) { cart, user ->
            val subtotal = cart.items.sumOf { it.unitPaise * it.qty }
            when {
                user.isMember || subtotal >= FREE_THRESHOLD -> DeliveryQuote(0, 0)
                else -> DeliveryQuote(STANDARD_FEE, FREE_THRESHOLD - subtotal)
            }
        }

    private companion object {
        const val FREE_THRESHOLD = 50_000L    // ₹500 in paise
        const val STANDARD_FEE = 4_000L       // ₹40
    }
}

// In a ViewModel: val quote = calculateDeliveryFee().stateIn(viewModelScope, WhileSubscribed(5000), null)

• One public operation, often exposed via operator fun invoke so callers write calculateDeliveryFee().
• Named as verb + noun: PlaceOrderUseCase, GetVisibleArticlesUseCase.
• Pure Kotlin, with no Android types. Main-safe, because threading is handled in repositories.
• Returns domain models or typed results, never UI strings or colours.

Testing

@Test
fun `members always get free delivery`() = runTest {
    val useCase = CalculateDeliveryFeeUseCase(
        FakeCartRepository(items = listOf(CartItem("a", unitPaise = 10_000, qty = 1))),
        FakeUserRepository(User(isMember = true)),
    )
    assertEquals(DeliveryQuote(0, 0), useCase().first())
}

The pass-through problem

class GetUserUseCase @Inject constructor(private val repo: UserRepository) {
    operator fun invoke(id: String) = repo.getUser(id)    // just forwards: delete it
}

Some teams mandate use cases everywhere for consistency, so ViewModels never touch repositories. That's a legitimate team choice in very large codebases, but weigh the cost: more files, more indirection, slower navigation. Google's guidance treats the domain layer as optional.

Where use cases live

• Small app: a domain package inside the feature.
• Modular app: a pure-Kotlin :core:domain or :feature:x:domain module, where the compiler enforces "no Android" automatically.

Good candidates in real apps

Frequently asked questions

Conclusion

Use cases are valuable for real, reusable or cross-repository business logic, and noise when they only forward calls. Keep them single-purpose, pure Kotlin and easy to test, and let simple screens talk to repositories directly.

Next step: expose the results cleanly to the UI with Managing UI State with ViewModel and StateFlow.