android-domain-layerlisted

# Android Domain Layer Sources of truth: [Domain layer](https://developer.android.com/topic/architecture/domain-layer). Rules marked **(stricter than Google)** are deliberate choices. ## 1. Decide whether a use case is needed The domain layer is **optional**. Add a use case only when at least one is true: - The same business logic is needed by **more than one ViewModel**. - The logic makes a ViewModel **hard to read or test** (combining several repositories, multi-step rules). Otherwise the ViewModel calls the repository directly. A use case that only forwards one repository call adds a class without adding value. Complex computations that benefit from caching usually belong in the **data layer**, not in a use case. ## 2. Shape of a use case - One use case, one responsibility. - Name: **verb in present tense + noun + `UseCase`**: `FormatDateUseCase`, `LogOutUserUseCase`, `GetLatestNewsWithAuthorsUseCase`. - Expose `operator fun invoke` so callers use it like a function; overloads may support different inputs to the same responsibility. - Suspending one-shot work uses `suspend operator fun invoke(...)`; synchronous work can use a regular `invoke`, and observable results return `Flow`. - **Main-safe**: if the use case does blocking or CPU-heavy work, it moves that work to an **injected** dispatcher. - **No mutable state.** Keep mutable data in the UI or data layer. - **(Stricter than Google)** Pure Kotlin: no `android.*` imports. ```kotlin class GetLatestNewsWithAuthor