تكرار السؤال: …
الإجابة المختصرة
التقسيم حسب الميزة (Modularization by Feature) مع استخراج وحدات النواة المشتركة (Core/Domain/UI)، مما يتيح توازي عمليات البناء وتفعيل الـ Build Cache.
الشرح
في التطبيق المكون من وحدة واحدة (Monolith)، فإن أي تعديل بسيط يجبر Gradle على إعادة ترجمة الكود بالكامل. في المعمارية المجزأة، إذا عدلت كود داخل :feature:auth، فإن Gradle يعيد بناء هذه الوحدة فقط ويعيد استخدام مخرجات باقي الوحدات من الـ Cache، مع تقليص وقت البناء التزايدي (Incremental Build) بنسبة هائلة وفرض حدود معمارية صارمة تمنع تشابك التبعيات.
مثال بالكود
// settings.gradle.kts
include(":app", ":feature:login", ":feature:checkout", ":core:ui", ":core:network", ":core:database", ":core:model")
// feature/login/build.gradle.kts — a feature depends on core modules, never on another feature
plugins {
id("com.android.library")
id("org.jetbrains.kotlin.android")
}
dependencies {
implementation(project(":core:model"))
implementation(project(":core:ui"))
}
// app/build.gradle.kts — the only module that knows every feature and wires them together
dependencies {
implementation(project(":feature:login"))
implementation(project(":feature:checkout"))
}أخطاء شائعة
- التقسيم فقط حسب الطبقات (Module for UI, Module for Data) مما يخلق وحدات ضخمة تعتمد على بعضها دائريًا وتفقد ميزة عزل الميزات واستقلالية الفرق.
- إنشاء تبعيات دائرية (Circular Dependencies) بين الوحدات وهو ما يمنعه Gradle بشكل صارم.