Clean Architecture & Use Cases

ARCHITECTURE › Patterns

Layering apps into presentation, domain, and data with use cases enforcing the dependency rule.

Interviewers use this topic to see whether you can structure an app into presentation, domain, and data layers and reason about the dependency rule rather than reciting buzzwords. Expect to defend when a use case earns its keep versus calling a repository directly, why the domain layer carries no Android dependencies, and how this layering improves testability. Strong answers treat use cases as a pragmatic, optional tool, not dogma.

What this covers

• The three layers (presentation/UI, domain, data) and which way dependencies are allowed to point
• The dependency rule: inner layers (domain) know nothing about outer layers (UI, framework)
• What a use case/interactor is: a single business operation, stateless, named verb+noun+UseCase
• Why the domain layer stays free of Android/framework dependencies and what that buys you
• When a use case is justified (reuse across ViewModels, combining repositories, complex rules) vs needless ceremony
• Testability benefits: pure Kotlin, fake repositories, main-safety, and isolating business logic

Study this topic

• Clean Architecture & Use Cases explained: the guided lesson
• 14 practice quiz questions
• 9 revision flashcards
• Clean Architecture & Use Cases interview questions and answers

Further reading

• Domain layer
• Architecture recommendations