2026'da Android Modularizasyonu: Multi-Module Mimari ve Mülakat Soruları

Android modularizasyonu, monolitik kod tabanlarını ekiplerin birbirlerinin koduna müdahale etmeden paralel çalışabildiği sürdürülebilir ve ölçeklenebilir sistemlere dönüştürür. İyi modularize edilmiş bir Android uygulaması daha hızlı derlenir, izole şekilde test edilir ve yeni geliştiricilerin haftalar yerine günler içinde adapte olmasını sağlar.

Android Uygulamaları için Multi-Module Mimari Neden Önemli

Tek modüllü bir Android uygulaması, bir satır değiştiğinde her şeyi yeniden derler. Ağ katmanı modifikasyonu UI yeniden derlemesini tetikler. Farklı özellikleri düzenleyen iki geliştirici, paylaşılan dosyalarda merge çakışmaları oluşturur. Derleme süreleri artımlı derlemelerde 4+ dakikaya uzar.

Çok modüllü mimari bu sorunları doğrudan ele alır:

• Daha hızlı derlemeler: Gradle yalnızca etkilenen modülleri yeniden derler. :feature:checkout'taki bir değişiklik :feature:profile'ı etkilemez.
• Paralel geliştirme: Ekipler tanımlı API'lere sahip ayrı modüllere sahip olur. Merge çakışmaları önemli ölçüde azalır.
• İzole test: Birim testleri tüm uygulamayı yüklemeden tek bir modül üzerinde çalışır.
• Kod yeniden kullanımı: :core:ui tasarım sistemi modülü birden fazla uygulamada kullanılabilir bir kütüphane haline gelir.

Resmi Android modularizasyon rehberi, Tek Sorumluluk İlkesine uygun olarak birlikte değişen özellikler veya katmanlar etrafında modüllerin yapılandırılmasını önerir.

Modül Türleri ve Sorumlulukları

Now in Android deposu, kurumsal uygulamalara ölçeklenen kanıtlanmış bir modül taksonomisi oluşturur.

include(":app")

// Core modules - shared utilities
include(":core:common")
include(":core:data")
include(":core:database")
include(":core:datastore")
include(":core:designsystem")
include(":core:domain")
include(":core:model")
include(":core:network")
include(":core:ui")

// Feature modules - screen-specific logic
include(":feature:home")
include(":feature:search")
include(":feature:bookmarks")
include(":feature:settings")

App modülü: MainActivity, navigasyon kurulumu ve uygulama düzeyinde iskelet içerir. Tüm feature modüllerine ve gerekli core modüllerine bağımlıdır.

Core modülleri: Özellikler arasında paylaşılan işlevsellik sağlar. :core:network API çağrılarını yönetir. :core:database Room entity'lerini yönetir. :core:designsystem uygulamanın görsel bileşenlerini tanımlar.

Feature modülleri: Tek bir ekran veya kullanıcı akışını kapsüller. Her feature modülü yalnızca ihtiyaç duyduğu core modüllerine bağımlıdır, asla diğer feature modüllerine değil.

Bu yapı tek yönlü bağımlılıkları zorlar: feature'lar core'a, app ise feature'lara bağımlıdır.

Bağımlılık Yönetimi için Gradle Version Catalogs

25'ten fazla modülde sürüm çakışmaları olmadan bağımlılık yönetimi merkezi yapılandırma gerektirir. Gradle Version Catalogs bunu tek bir libs.versions.toml dosyasıyla çözer.

# gradle/libs.versions.toml
[versions]
agp = "8.7.0"
kotlin = "2.1.0"
compose-bom = "2026.09.00"
ksp = "2.1.0-1.0.29"
hilt = "2.54"
room = "2.7.0"
retrofit = "2.11.0"

[libraries]
androidx-core-ktx = { group = "androidx.core", name = "core-ktx", version = "1.15.0" }
androidx-compose-bom = { group = "androidx.compose", name = "compose-bom", version.ref = "compose-bom" }
androidx-compose-ui = { group = "androidx.compose.ui", name = "ui" }
androidx-compose-material3 = { group = "androidx.compose.material3", name = "material3" }
hilt-android = { group = "com.google.dagger", name = "hilt-android", version.ref = "hilt" }
hilt-compiler = { group = "com.google.dagger", name = "hilt-android-compiler", version.ref = "hilt" }
room-runtime = { group = "androidx.room", name = "room-runtime", version.ref = "room" }
room-ktx = { group = "androidx.room", name = "room-ktx", version.ref = "room" }
room-compiler = { group = "androidx.room", name = "room-compiler", version.ref = "room" }
retrofit-core = { group = "com.squareup.retrofit2", name = "retrofit", version.ref = "retrofit" }

[bundles]
compose = ["androidx-compose-ui", "androidx-compose-material3"]
room = ["room-runtime", "room-ktx"]

[plugins]
android-application = { id = "com.android.application", version.ref = "agp" }
android-library = { id = "com.android.library", version.ref = "agp" }
kotlin-android = { id = "org.jetbrains.kotlin.android", version.ref = "kotlin" }
ksp = { id = "com.google.devtools.ksp", version.ref = "ksp" }
hilt = { id = "com.google.dagger.hilt.android", version.ref = "hilt" }

Modüller daha sonra type-safe accessor'lar ile bağımlılıklara referans verir:

dependencies {
    implementation(libs.bundles.compose)
    implementation(libs.hilt.android)
    ksp(libs.hilt.compiler)
}

Gradle bu accessor'ları senkronizasyon sırasında oluşturur, IDE otomatik tamamlama ve derleme zamanı doğrulaması sağlar.

Convention Plugins: DRY Build Yapılandırması

Convention plugins olmadan 25 modüllü bir proje, her build.gradle.kts'de aynı compileSdk, minSdk, composeOptions ve plugin uygulamalarını tekrarlar. Farklı modüller yanlışlıkla farklı yapılandırmalar kullanabilir.

Convention plugins bu mantığı build-logic included build'inde merkezileştirir.

import com.android.build.api.dsl.LibraryExtension
import org.gradle.api.Plugin
import org.gradle.api.Project
import org.gradle.kotlin.dsl.configure

class AndroidLibraryConventionPlugin : Plugin<Project> {
    override fun apply(target: Project) {
        with(target) {
            pluginManager.apply("com.android.library")
            pluginManager.apply("org.jetbrains.kotlin.android")

            extensions.configure<LibraryExtension> {
                compileSdk = 35
                defaultConfig {
                    minSdk = 26
                    testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
                }
                compileOptions {
                    sourceCompatibility = JavaVersion.VERSION_17
                    targetCompatibility = JavaVersion.VERSION_17
                }
            }
        }
    }
}

Plugin'i build-logic/convention/build.gradle.kts'de kaydet:

plugins {
    `kotlin-dsl`
}

dependencies {
    compileOnly(libs.android.gradlePlugin)
    compileOnly(libs.kotlin.gradlePlugin)
}

gradlePlugin {
    plugins {
        register("androidLibrary") {
            id = "myapp.android.library"
            implementationClass = "AndroidLibraryConventionPlugin"
        }
        register("androidFeature") {
            id = "myapp.android.feature"
            implementationClass = "AndroidFeatureConventionPlugin"
        }
        register("androidHilt") {
            id = "myapp.android.hilt"
            implementationClass = "AndroidHiltConventionPlugin"
        }
    }
}

Feature modülleri artık minimal yapılandırma gerektirir:

plugins {
    alias(libs.plugins.myapp.android.feature)
    alias(libs.plugins.myapp.android.hilt)
}

dependencies {
    implementation(projects.core.data)
    implementation(projects.core.designsystem)
}

Google'ın Now in Android build-logic tam olarak bu kalıbı kullanır.

Modül İletişim Kalıpları

Feature modülleri birbirine doğrudan bağımlı olmamalıdır. Bu kısıtlama paralel derlemeyi korur ve döngüsel bağımlılıkları önler. Üç kalıp çapraz özellik iletişimini yönetir.

Paylaşılan Rotalar ile Navigasyon

object Routes {
    const val HOME = "home"
    const val PRODUCT_DETAIL = "product/{productId}"
    const val CHECKOUT = "checkout"
    
    fun productDetail(productId: String) = "product/$productId"
}

Feature modülleri, hangi modülün her hedefi uyguladığını bilmeden :core:navigation'dan rotaları içe aktarır.

Paylaşılan Domain Modelleri

data class Product(
    val id: String,
    val name: String,
    val price: BigDecimal,
    val imageUrl: String
)

Hem :feature:catalog hem de :feature:checkout, Product sınıfı için :core:model'e bağımlıdır.

Event Bus veya Paylaşılan ViewModel

Çalışma zamanı iletişimi için, :core:common'daki paylaşılan event bus veya scoped ViewModel çapraz özellik olaylarını yönetir:

object CartEventBus {
    private val _events = MutableSharedFlow<CartEvent>()
    val events: SharedFlow<CartEvent> = _events.asSharedFlow()
    
    suspend fun emit(event: CartEvent) {
        _events.emit(event)
    }
}

sealed interface CartEvent {
    data class ItemAdded(val productId: String) : CartEvent
    data class ItemRemoved(val productId: String) : CartEvent
}

Android Modularizasyonu Hakkında Mülakat Soruları

Modularizasyon, senior Android mülakatlarında sıkça karşılaşılan bir konudur. Mülakatçılar build sistemleri anlayışını, mimari kararları ve pratik ödünleşimleri değerlendirir.

S: Gradle'da api ve implementation bağımlılıkları arasındaki fark nedir?

implementation bağımlılıkları modüle özeldir. Modülün tüketicileri bunlara erişemez. api bağımlılıkları geçişli olarak açığa çıkarılır: A modülü api(libs.retrofit) kullanırsa, A'ya bağımlı B modülü Retrofit sınıflarını doğrudan kullanabilir.

Temel kural: varsayılan olarak implementation kullanılmalıdır. api yalnızca bağımlılık modülün public API'sinin bir parçası olduğunda kullanılmalıdır. api'nin aşırı kullanımı kapsüllemeyi bozar ve derlemeleri yavaşlatır.

S: Birbirine bağımlı olmayan feature modülleri arasında navigasyon nasıl yönetilir?

Rota tanımları ve navigasyon arayüzleri içeren bir :core:navigation modülü oluşturulmalıdır. Feature modülleri bu paylaşılan modüle bağımlıdır. App modülü hedefleri implementasyonlara bağlar. Bu, bağımlılık tersine çevirme ilkesini izler: özellikler somut implementasyonlara değil soyutlamalara bağımlıdır.

S: Çok fazla modüle sahip olmanın ödünleşimleri nelerdir?

Her modül Gradle yapılandırma yükü ekler: build dosyaları, kaynak işleme, manifest birleştirme. İlk senkronizasyon süreleri artar. Kritik nokta projeye göre değişir, ancak büyük uygulamalarda 50+ modül yaygındır. Faydalar (paralel derlemeler, izole testler, net sahiplik) genellikle 5+ geliştirici ekipler için yükü aşar.

S: Convention plugins buildSrc'den nasıl farklıdır?

buildSrc değişiklikleri tam proje yeniden derlemesi tetikler. Included build'deki convention plugins yalnızca plugin kodu değiştiğinde yeniden derlenir, tüketen modüller değiştiğinde değil. Bu, convention plugins'i iteratif geliştirme için daha hızlı yapar. Ayrıca convention plugins, depolar arasında yeniden kullanım için ayrı bir artifact olarak yayınlanabilir.

S: Bir feature modülü izole olarak nasıl test edilir?

Feature modülleri arayüzler aracılığıyla core modüllere bağımlıdır. Test fixture'larında sahte implementasyonlar oluşturulur:

class FakeProductRepository : ProductRepository {
    private val products = mutableListOf<Product>()
    
    override suspend fun getProducts(): List<Product> = products
    
    fun addProduct(product: Product) {
        products.add(product)
    }
}

Feature modülü testleri, Hilt'in test API'leri veya manuel constructor injection aracılığıyla fake'leri enjekte eder.

Android mimarisi hakkında daha fazla pratik soru için MVVM mimari mülakat soruları ve dependency injection modülüne bakılabilir.

Multi-Module Android Projeleri için Temel Çıkarımlar

• Modülleri özellik (:feature:home, :feature:checkout) ve katman (:core:data, :core:ui) bazında yapılandırın. Özellikler core'a bağımlıdır, asla birbirlerine değil.
• Bağımlılık sürümlerini merkezileştirmek için Gradle Version Catalogs (libs.versions.toml) kullanın. Bundle'lar daha temiz build dosyaları için ilgili bağımlılıkları gruplar.
• Modüller arasında yinelenen yapılandırmayı ortadan kaldırmak için build-logic'te convention plugins uygulayın. Bir plugin değişikliği tüm tüketen modülleri günceller.
• Tek yönlü bağımlılıkları zorlayın: app feature'lara, feature'lar core'a bağımlıdır. Dependency Guard gibi araçlar zorlamayı otomatikleştirebilir.
• Modularizasyon öncesi ve sonrası build performansını ölçün. İyileştirmeleri doğrulamak için yalnızca clean build'leri değil, artımlı derleme sürelerini takip edin.
• Modül sınırlarını kararlı tutun. Sık yeniden yapılandırma modularizasyonun faydalarını ortadan kaldırır.