Modularitas dalam pengembangan seluler — esensi, prinsip, dan pengaturan

Apa itu modularitas dalam pengembangan seluler

Modularitas adalah cara mengatur kode di mana aplikasi terdiri dari modul-modul yang saling terhubung secara longgar, masing-masing menyediakan fungsionalitas yang ditentukan secara ketat melalui antarmuka publik. Berbeda dengan arsitektur monolitik, di mana semua kelas berada dalam satu proyek, pendekatan modular membagi kode menjadi unit-unit kompilasi yang independen secara fisik.

Tujuan utama modularitas adalah mengelola kompleksitas. Pengembang dapat fokus pada satu modul tanpa harus mengingat seluruh basis kode. Setiap modul memiliki zona tanggung jawabnya sendiri dan dapat dikembangkan, diuji, dan digunakan secara independen dari yang lain. Ini sangat berharga dalam proyek dengan 10+ pengembang, di mana pekerjaan paralel pada monolit menyebabkan seringnya konflik penggabungan.

Penting untuk membedakan modularitas dari arsitektur berlapis. Lapisan (Presentation, Domain, Data) membagi kode berdasarkan kriteria teknis, sedangkan modul — berdasarkan kriteria fungsional. Modul “Profil Pengguna” dapat berisi lapisannya sendiri di dalamnya. Dalam praktiknya, pendekatan modular dan arsitektur berlapis digabungkan: setiap modul memiliki struktur tiga lapisnya sendiri.

Jenis modul dan fungsinya

Modul Feature — jenis modul yang paling populer. Setiap layar atau grup layar terkait ditempatkan dalam modul terpisah: Onboarding, Profile, Settings, Feed. Modul Feature berisi semua yang diperlukan untuk fungsi tersebut: UI, logika bisnis, lapisan data. Batas modul dilindungi — fungsi lain tidak dapat mengakses kelas internalnya.

Modul Core berisi infrastruktur bersama: kerja jaringan, basis data, analitik, sistem desain. Mereka tidak bergantung pada modul Feature, tetapi modul Feature bergantung pada mereka. Pembagian ini menjamin bahwa perubahan SDK analitik tidak akan memengaruhi lapisan jaringan dan sebaliknya. Modul Core digunakan kembali antar fungsi tanpa duplikasi kode.

Modul Shared untuk logika bersama

Modul Shared berisi kode yang digunakan oleh beberapa fungsi: model data, utilitas, konstanta, View kustom. Masalah utama modul Shared adalah risiko menjadi tempat pembuangan (“misc module”), di mana kode yang beragam menumpuk seiring waktu. Aturan: modul Shared harus memiliki tema yang jelas, misalnya “shared-ui” atau “shared-models”.

Di Android, modul Shared sering dipisahkan menjadi pustaka dengan awalan lib: lib-network, lib-database, lib-ui-components. Di iOS, fungsi yang sama dilakukan oleh Swift Packages internal di dalam Workspace. Dalam praktiknya, tim membatasi jumlah modul Shared hingga 3–5 untuk menghindari jaringan ketergantungan yang berlebihan yang mempersulit pembangunan.

Modul uji dan isolasi pengujian

Modul uji terpisah memungkinkan menjalankan pengujian hanya untuk modul yang dimodifikasi, tanpa menjalankan seluruh basis pengujian. Ini mempersingkat pipeline CI/CD dari jam menjadi menit. Modul memastikan pemisahan pada tingkat pembangunan: modul lapisan jaringan tidak dapat secara tidak sengaja mengimpor pustaka UI dalam pengujian.

Setiap modul harus memiliki API publik yang didefinisikan dengan jelas. Di Android, ini dicapai melalui pengubah akses dan api vs implementation di Gradle. Di iOS — melalui pengubah akses public/internal dan ketergantungan yang dikelola melalui Package.swift. Mengurangi visibilitas hingga minimum yang diperlukan adalah praktik kunci desain modular.

Modularitas di Android: modul Gradle

Gradle mendukung arsitektur modular secara native: setiap modul adalah unit kompilasi terpisah dengan file build.gradle-nya sendiri. Proyek Android menggunakan kombinasi modul application (app) dan beberapa modul library. Modul pustaka tidak dapat dijalankan sebagai aplikasi, tetapi dapat dipublikasikan sebagai AAR di repositori.

Fitur utama Gradle adalah pembangunan paralel modul independen. Jika modul A, B, dan C tidak saling bergantung, Gradle mengompilasinya secara bersamaan, menggunakan semua inti prosesor. Dalam proyek dengan 20+ modul, ini mempersingkat pembangunan penuh dari 15 menjadi 3–5 menit. Pembangunan inkremental dari modul yang dimodifikasi membutuhkan waktu detik.

Gradle menyediakan dua jenis ketergantungan antar modul: api (transitif) dan implementation (non-transitif). Perbedaannya sangat penting untuk modularitas: implementation menyembunyikan ketergantungan transitif dari konsumen modul. Jika modul :profile menggunakan :networking melalui implementation, konsumen :profile tidak tahu tentang :networking dan tidak dapat merujuknya.

// settings.gradle — deklarasi modul
include ':app'
include ':feature:profile'
include ':feature:settings'
include ':core:network'
include ':core:database'

// build.gradle feature/profile — ketergantungan modul
dependencies {
    implementation project(':core:network')
    implementation project(':core:database')
    implementation 'androidx.lifecycle:lifecycle-viewmodel-ktx:2.8.0'
}

Kode menunjukkan struktur proyek Android modular. Settings.gradle mendaftar semua modul, dan build.gradle setiap modul Feature hanya menunjukkan modul Core yang dibutuhkannya. Sistem pembangunan secara otomatis menyelesaikan ketergantungan transitif dan mengompilasi modul dalam urutan yang benar.

Modularitas di iOS: Swift Package Manager dan CocoaPods

Swift Package Manager (SPM) — alat standar untuk modularitas di iOS sejak 2019. SPM memungkinkan membagi aplikasi menjadi Swift Packages, yang masing-masing dapat berupa library atau executable. Package mendefinisikan modul (targets) dan ketergantungannya melalui Package.swift. SPM terintegrasi dengan Xcode dan tidak memerlukan alat tambahan.

CocoaPods tetap menjadi manajer ketergantungan utama untuk pustaka pihak ketiga. Podfile dan Podspec mendefinisikan struktur modular, dan CocoaPods menghasilkan workspace dengan proyek pod terpisah. Untuk modularitas proyek itu sendiri, tim semakin memilih SPM karena terintegrasi dalam Xcode dan tidak memerlukan instalasi.

Dalam modularitas iOS, kontrol akses memainkan peran penting: public, package, internal, fileprivate, dan private. Modul hanya memublikasikan tipe yang harus dapat diakses oleh modul lain. Detail implementasi internal disembunyikan di balik pengubah internal dan private. Ini mencegah munculnya ketergantungan tersembunyi antar modul.

// Package.swift — struktur modular proyek iOS
let package = Package(
    name: "MyApp",
    platforms: [.iOS(SupportedPlatform.iOSVersion.v17)],
    products: [
        .library(name: "ProfileFeature", targets: ["ProfileFeature"]),
        .library(name: "NetworkCore", targets: ["NetworkCore"]),
    ],
    dependencies: [
        .package(url: "https://github.com/Alamofire/Alamofire.git", from: "5.9.0")
    ],
    targets: [
        .target(name: "ProfileFeature", dependencies: ["NetworkCore"]),
        .target(name: "NetworkCore", dependencies: ["Alamofire"]),
    ]
)

Package.swift mendeklarasikan dua produk library: ProfileFeature dan NetworkCore. ProfileFeature bergantung pada NetworkCore, tetapi tidak tahu tentang keberadaan Alamofire — itu disembunyikan di dalam NetworkCore. Isolasi semacam itu adalah penerapan langsung pemisahan pada tingkat modul: perubahan pada klien HTTP tidak memerlukan kompilasi ulang ProfileFeature.

Keuntungan dan tantangan arsitektur modular

Keuntungan utama modularitas adalah kecepatan pengembangan. Tim bekerja secara paralel pada modul yang berbeda tanpa konflik kode. Pipeline CI/CD hanya membangun modul yang dimodifikasi dan hanya menjalankan pengujiannya. Waktu umpan balik berkurang, dan frekuensi rilis meningkat. Spotify, Uber, dan Airbnb telah memublikasikan kasus migrasi ke arsitektur modular dengan peningkatan metrik 2–3 kali lipat.

Keuntungan kedua — isolasi kesalahan. Bug di modul Profile tidak memengaruhi modul Payments, jika tidak ada ketergantungan langsung di antara mereka. Ini sangat penting dalam aplikasi dengan fungsi berisiko tinggi (pembayaran, data medis), di mana kesalahan di layar yang tidak terkait tidak boleh memblokir rilis fungsionalitas penting.

Tantangan utama — manajemen ketergantungan. Dengan desain yang salah, muncul grafik modul di mana perubahan satu modul secara kaskade membangun ulang puluhan modul lainnya. Solusi — patuhi aturan asiklisitas: grafik ketergantungan modul harus berupa grafik asiklik terarah (DAG). Alat seperti Gradle Module Graph Assert membantu mendeteksi siklus pada tahap pembangunan.

Tantangan kedua — peningkatan waktu konfigurasi awal. Membuat arsitektur modular membutuhkan lebih banyak waktu pada tahap inisialisasi proyek. Proyek kecil dengan 1–3 pengembang mungkin tidak mendapatkan manfaat dari modularitas, menghabiskan waktu untuk mempertahankan batas modul tanpa kebutuhan nyata akan paralelisasi. Solusi — mulailah dengan monolit dan ekstrak modul seiring pertumbuhan tim.

Pendekatan Feature-first vs layer-first

Pendekatan Feature-first mengelompokkan modul berdasarkan fungsionalitas: setiap layar atau grup layar menjadi modul terpisah. Pendekatan Layer-first membagi kode berdasarkan kriteria teknis: modul terpisah untuk UI, logika bisnis, dan data. Dalam praktiknya, sebagian besar tim memilih feature-first dengan modul Core — ini memberikan isolasi yang lebih baik dan navigasi yang jelas melalui proyek.

Pilihan antara pendekatan tergantung pada ukuran tim dan prediktabilitas fungsionalitas. Jika Anda tahu persis layar apa yang akan ada dalam proyek, feature-first memungkinkan setiap pengembang bertanggung jawab atas modulnya sendiri. Jika fungsionalitas sering berubah dan tumpang tindih antar layar, layer-first memberikan lebih banyak fleksibilitas dalam penggunaan kembali kode antar fungsi yang berbeda.