Clean Architecture & Use Cases Flashcards
ARCHITECTURE › Patterns
- What are the three layers in Android's recommended architecture and how do dependencies flow?
- Presentation/UI, domain, and data. The UI layer depends on the domain layer, which depends on the data layer; dependencies point inward and the data and domain layers never depend on the UI.
- State the dependency rule of Clean Architecture.
- Inner layers must know nothing about outer layers. The domain (inner) has no reference to the UI or framework; outer layers depend on inner ones, never the reverse. Stable business logic stays independent of volatile details.
- What is a use case (interactor) and what is the naming convention?
- A class encapsulating a single business operation. Convention: verb in present tense + noun/what + 'UseCase', e.g. GetLatestNewsWithAuthorsUseCase. It should be stateless, hold no mutable data, and own one responsibility.
- Why does the domain layer have no Android framework dependencies?
- Keeping it pure Kotlin makes business logic reusable across platforms (Wear, TV, KMP), independent of the volatile Android SDK, and unit-testable on the JVM without Robolectric, an emulator, or Android stubs.
- When is adding a use case worth it versus calling the repository directly from the ViewModel?
- Add one when logic is reused across multiple ViewModels, combines several repositories, or encodes complex business rules. For a thin pass-through to one repository it adds ceremony for little benefit; call the repository directly.
- What does it mean that use cases must be main-safe, and whose job is threading?
- They must be safe to call from the main thread. The use case itself moves blocking work off the main thread, typically with withContext(defaultDispatcher), so callers (ViewModels) don't manage that concern.
- How is a use case typically invoked in Kotlin, and why a new instance each time?
- Via operator fun invoke(), so it is called like a function: getLatestNews(). Because use cases hold no mutable state, you create a fresh instance per injection rather than sharing one; they have no lifecycle of their own.
- How do use cases improve testability?
- Business logic becomes a pure Kotlin class with explicit dependencies, testable in isolation with fake repositories and no Android runtime. ViewModels shrink, and one tested use case covers logic reused across many callers.
- Is the domain layer mandatory in Android architecture?
- No. The UI and data layers are strongly recommended; the domain layer is optional and recommended mainly in big apps when you need to reuse data-layer logic across ViewModels or simplify a complex ViewModel.