android-clean-architecture

Topics in the source

• Android Clean Architecture
• When to Activate
• Module Structure
• Recommended Layout
• Dependency Rules
• Domain Layer
• UseCase Pattern
• Domain Models

Clean Architecture patterns for Android and KMP projects. Covers module boundaries, dependency inversion, UseCase/Repository patterns, and data layer design with Room, SQLDelight, and Ktor. Structuring Android or KMP project modules Implementing UseCases, Repositories, or DataSources Designing data flow between layers (domain, data, presentation) Setting up dependency injection with Koin or Hilt Working with Room, SQLDelight, or Ktor in a layered architecture Critical: domain must NEVER depend on data, presentation, or any framework. It contains pure Kotlin only. Each UseCase represents one business operation. Use operator fun invoke for clean call sites: Domain models are plain Kotlin data classes — no framework annotations: Defined in domain, implemented in data: Coordinates between local and remote data sources: Keep mappers as extension functions near the data models: Use Result or a custom sealed type for error propagation: For KMP projects, use convention plugins to reduce build file duplication: Apply in modules: Importing Android framework classes in domain — keep it pure Kotlin Exposing database entities or DTOs to the UI layer — always map to domain models Putting busines

This is an excerpt. Refer to the complete source and its current requirements.