Your stack is a reasonable starting point. I would make the data flow and dependency boundaries explicit before adding more layers.
For the areas you listed:
- Compose state: expose an immutable screen state from the ViewModel, usually through StateFlow. Collect it with collectAsStateWithLifecycle(), and send user actions back through ViewModel methods. Keep state such as an expanded menu local to the composable when no business logic needs it.
- Offline-first: have the UI read from a local source through the repository. A refresh fetches remote data and updates the local database, which then emits the new state. Decide separately how queued writes, retries, and conflicts work; caching reads alone does not solve those problems.
- Repositories: organize them around data responsibilities rather than creating one per endpoint. Keep Retrofit and Room details behind that boundary. Add use cases when they simplify reused or complex business logic.
- Modules: split around cohesive features and genuinely shared capabilities. A larger backend does not automatically require more Android modules. Consider ownership, dependency direction, and build impact when deciding where a boundary helps.
- Tests: test ViewModels with fake repositories and controlled coroutine dispatchers. Check loading, success, failure, and retry behavior. Test database queries and migrations separately; reserve UI tests for important user journeys.
A useful first slice is one screen that loads cached data, refreshes it, handles a network failure, and is covered by tests. That gives you evidence about the architecture before you repeat it across every feature.
Google’s architecture recommendations and offline-first guide cover these boundaries and trade-offs.