android-architecture

Android Architecture

Overview

Good architecture makes Android apps testable, maintainable, and scalable. This skill guides architectural decisions: module structure, layer separation (UI → Domain → Data), dependency injection with Hilt, state management with Coroutines and Flow, and patterns that survive configuration changes and process death.

When to Use

• Starting a new Android project or module
• Adding a feature module to an existing multi-module project
• Choosing between MVVM and MVI for a screen
• Setting up or refactoring dependency injection
• Defining boundaries between layers
• Debugging lifecycle or state management issues

Skip when: Making a small change within an already-architected feature.

Core Process

Step 1: Module Structure

1. Organize by layer and feature:

:app                          # Application, navigation, DI entry point
:feature:home                 # Home screen (UI + ViewModel)
:feature:profile              # Profile screen (UI + ViewModel)
:feature:settings             # Settings screen (UI + ViewModel)
:core:data                    # Repositories, data sources, API services
:core:domain                  # Use cases, domain models (pure Kotlin)
:core:database                # Room database, entities, DAOs
:core:network                 # Retrofit services, API models, interceptors
:core:ui                      # Shared composables, theme, design tokens
:core:common                  # Utilities, extensions, constants
:core:testing                 # Shared test utilities, fakes

1. Dependency rules:
   • :feature:* depends on :core:domain, :core:ui, :core:common
   • :core:data depends on :core:domain, :core:database, :core:network
   • :core:domain depends on nothing (pure Kotlin module)
   • :app depends on all :feature:* and :core:data (for DI wiring)
   • Never: feature → feature, core → feature, domain → data

Step 2: Layer Separation

1. Three layers, strict boundaries: