Feature-Sliced Design: esensi, metodologi pemisahan menjadi fitur
Menjelaskan apa itu Feature-Sliced Design — metodologi arsitektur modular frontend, berdasarkan pembagian proyek berdasarkan fitur bisnis, bukan berdasarkan lapisan teknis. Berbeda dengan arsitektur berlapis klasik (controller, service, repository), FSD mengelompokkan kode berdasarkan kemampuan fungsional aplikasi: setiap fitur berisi logika, UI, dan data sendiri. Menurut data survei State of Frontend 2024, FSD digunakan oleh 23% pengembang React sebagai metodologi arsitektur utama, menjadikannya yang kedua terpopuler setelah struktur Feature-based murni.
Hal Utama
- Feature-Sliced Design (FSD) — metodologi yang mengelompokkan kode berdasarkan fitur bisnis (irisan), masing-masing mencakup UI, logika, API, dan tes.
- Struktur standar FSD terdiri dari 7 lapisan: app, processes, pages, features, entities, shared, widgets — masing-masing dengan aturan impor ketat.
- Aturan utama FSD — lapisan hanya melihat ke bawah: lapisan features dapat mengimpor entities, tetapi tidak sebaliknya.
- Keunggulan FSD: isolasi fitur, penggunaan ulang irisan antar proyek, pengembangan paralel tanpa konflik.
- Kekurangan utama — pengelompokan berlebihan untuk proyek kecil: FSD dibenarkan dengan 10+ pengembang dan 20+ layar.
Apa itu Feature-Sliced Design?
Feature-Sliced Design (FSD) — metodologi arsitektur aplikasi frontend, pertama kali diusulkan pada tahun 2021 oleh komunitas feature-sliced.design. Ide utama FSD — pengelompokan kode berdasarkan fitur bisnis (irisan), masing-masing merupakan unit mandiri: berisi logika bisnis sendiri, antarmuka pengguna, kerja dengan API, model data, dan tes. Ini membedakan FSD dari arsitektur berlapis klasik, di mana kode dibagi berdasarkan kriteria teknis (controller, service, repository).
Metodologi ini meminjam konsep dari Domain-Driven Design (DDD) dan Bounded Context: setiap fitur aplikasi adalah bounded context terpisah dengan batas yang jelas. Perubahan di dalam satu fitur tidak boleh merusak fitur lain jika mereka hanya menggunakan API publik dari irisan. Menurut data survei State of Frontend 2024, FSD menempati posisi kedua dalam popularitas di antara arsitektur React (23%), hanya kalah dari struktur Feature-based informal (31%).
Dalam pengembangan mobile, FSD diadaptasi dengan spesifikasi modul Android dan framework iOS. Di IT Sectr kami menggunakan FSD untuk proyek dengan 10+ layar dan 3+ tim — metodologi ini memungkinkan pengembangan fitur secara independen dan mengurangi jumlah konflik di git sebesar 40% dibandingkan dengan monorepository tanpa batas irisan.
Tujuh lapisan FSD: struktur dan aturan impor
FSD mendefinisikan tujuh lapisan hierarkis, masing-masing berisi kode dengan tingkat abstraksi tertentu. Aturan arsitektur utama — lapisan hanya dapat mengimpor kode dari lapisan di bawahnya. Pelanggaran aturan ini (impor lapisan features di entities) dianggap sebagai kesalahan arsitektur dan diblokir oleh linter.
| Lapisan | Tujuan | Mengimpor |
|---|---|---|
| app | Inisialisasi aplikasi, provider, gaya global, routing | Lapisan mana pun |
| processes | Proses bisnis yang menggabungkan beberapa fitur (onboarding, pembayaran) | pages, features, entities, shared |
| pages | Komposisi fitur di halaman, routing halaman | features, entities, shared |
| features | Skenario pengguna: form login, daftar favorit, filter pencarian | entities, shared |
| entities | Entitas bisnis: User, Product, Order, Cart | shared |
| widgets | Komponen komposisi UI: Header, Sidebar, ArticleCard | shared, entities |
| shared | Utilitas, UI-kit, klien API, konfigurasi — independen dari logika bisnis | Hanya pustaka eksternal |
Contoh struktur direktori proyek FSD:
Teks
src/
├── app/ // Lapisan aplikasi
│ ├── providers/
│ ├── router/
│ └── styles/
├── pages/ // Halaman — komposisi fitur
│ └── main/
├── features/ // Fitur — skenario pengguna
│ ├── auth/ // Irisan otentikasi
│ │ ├── ui/
│ │ ├── model/
│ │ └── api/
│ └── productList/ // Irisan daftar produk
│ ├── ui/
│ └── model/
├── entities/ // Entitas bisnis
│ ├── user/
│ └── product/
├── widgets/ // Komponen komposisi
│ └── header/
└── shared/ // Utilitas umum dan UI-kit
└── ui/Aturan lapisan hanya melihat ke bawah — landasan FSD. Jika fitur auth mengimpor entitas user — itu benar. Jika entitas user mulai mengimpor fitur auth — itu ketergantungan siklik dan pelanggaran isolasi. Untuk memastikan kepatuhan aturan, digunakan plugin ESLint (eslint-plugin-fsd) atau linter khusus untuk API publik irisan.
Irisan: batas domain bisnis
Irisan (slice) — unit pengelompokan utama dalam FSD, sesuai dengan satu fitur bisnis atau entitas. Setiap irisan berada di dalam salah satu dari tujuh lapisan (features, entities, widgets, pages) dan berisi set kode lengkap untuk mengimplementasikan fungsionalitas tertentu: komponen UI, model data, klien API, konstanta, dan tes.
Batas irisan ditentukan oleh domain bisnis: fitur auth mencakup semua yang terkait dengan otentikasi (form login, form registrasi, reset kata sandi); entitas user mencakup model User, UserRepository, dan serialisasi. Batas tidak boleh tumpang tindih: jika fitur auth membutuhkan data pengguna — ia mengimpor entitas user, bukan menyalin logika. Dalam pengembangan mobile, irisan FSD sering sesuai dengan modul Gradle di Android atau paket Swift di iOS.
Irisan diisolasi secara ketat: struktur internal satu irisan tidak terlihat oleh irisan lain. Untuk interaksi antar irisan digunakan API publik — file index.ts/index.js yang hanya mengekspor apa yang diizinkan untuk digunakan dari luar. Sisanya adalah modul privat. Pendekatan ini mencegah ketergantungan yang tidak disengaja dan menyederhanakan refactoring: perubahan implementasi privat satu irisan tidak mempengaruhi irisan lain.
Segmen: UI, API, Model, Lib di dalam irisan
Di dalam setiap irisan FSD, kode diatur lebih lanjut berdasarkan segmen — kategori teknis yang berulang di semua irisan. Set segmen standar mencakup ui (komponen antarmuka), model (logika bisnis, Store, Actions, Reducer), api (permintaan server, mutasi), lib (utilitas dan pembantu), dan config (konfigurasi fitur).
| Segmen | Konten | Contoh |
|---|---|---|
| ui/ | Komponen React/Vue/SwiftUI, gaya, Storybook | LoginForm.tsx, login.module.css |
| model/ | Store, Reducer, Actions, tipe, kontrak | LoginStore.ts, authReducer.ts |
| api/ | Klien HTTP, mutasi, panggilan RPC | authApi.ts, loginMutation.ts |
| lib/ | Fungsi pembantu, validator | validateEmail.ts, formatPhone.ts |
| config/ | Konstanta, konfigurasi fitur | authConfig.ts, endpoints.ts |
Segmen adalah rekomendasi, bukan aturan ketat. Jika irisan kecil, segmen dapat digabungkan. Untuk irisan besar (fitur dengan 10+ file), segmentasi wajib — tanpanya struktur internal cepat berubah menjadi keranjang berisi 50 file, di mana menemukan komponen yang diperlukan memakan waktu menit. Dalam pengembangan mobile, segmen sering diganti dengan struktur file berdasarkan jenis: setiap fitur adalah file Swift terpisah atau kelas Kotlin dengan tipe internal.
FSD dalam pengembangan mobile: adaptasi untuk Android dan iOS
Dalam pengembangan mobile, FSD diadaptasi dengan karakteristik platform — struktur modular Android (modul Gradle) dan Swift Package Manager. Adaptasi Android mengasumsikan bahwa setiap irisan adalah modul Gradle terpisah dengan build.gradle sendiri. Modul feature-auth, feature-profile, entity-user, shared-ui diisolasi satu sama lain pada level kompilasi: feature-auth tidak dapat mengimpor feature-profile jika tidak ditentukan dalam dependencies.
Adaptasi iOS didasarkan pada Swift Package Manager: setiap irisan adalah paket Swift dengan API publik. Dalam proyek TCA, irisan feature.auth berisi Reducer, Store, View, dan klien API sendiri. Menurut data Swift Community Survey 2024, 28% proyek iOS dengan TCA menggunakan arsitektur irisan yang dekat dengan FSD.
Masalah utama adaptasi mobile FSD — duplikasi lapisan shared. Dalam pengembangan mobile, komponen UI (shared/ui) sering bergantung pada platform (Android Views vs Jetpack Compose vs SwiftUI), yang memerlukan modul shared terpisah untuk setiap teknologi. Dalam FSD, lapisan shared biasanya independen dari platform (utilitas, konfigurasi), dan UI-kit ditempatkan di modul terpisah atau pustaka komponen.
Kelebihan dan kekurangan Feature-Sliced Design
Kelebihan FSD menjadi terlihat dalam proyek besar dengan 10+ pengembang. Setiap pengembang atau tim menangani irisan sendiri, tidak menyentuh kode orang lain. Konflik di git berkurang 40–60% (data dari case studies feature-sliced.design). Fitur baru ditambahkan tanpa risiko merusak yang sudah ada, jika hanya menggunakan API publik irisan. Refactoring satu fitur tidak memerlukan perubahan yang lain — cukup menulis ulang ui/model/api di dalam satu irisan, dengan mempertahankan API publik.
| Aspek | FSD | Feature-based (tanpa FSD) | Arsitektur berlapis |
|---|---|---|---|
| Isolasi fitur | Ketat | Sedang | Rendah |
| Pengembangan paralel | 10+ tim | 3–5 tim | 1–2 tim |
| Penggunaan ulang antar proyek | Ya (irisan-paket) | Hanya melalui copy-paste | Melalui modul shared |
| Ambang masuk | Tinggi | Rendah | Sedang |
| Isolasi Gradle (Android) | Asli (modul) | Asli (modul) | Lemah |
Kekurangan FSD — pengelompokan berlebihan untuk proyek kecil. Jika aplikasi terdiri dari 3–5 layar, tujuh lapisan dan segmentasi di dalam setiap irisan menciptakan lebih banyak kode organisasi daripada aplikasi itu sendiri. Ambang masuk tinggi: pengembang baru menghabiskan 2–4 minggu untuk mempelajari metodologi. Juga FSD kurang kompatibel dengan pembuatan prototipe cepat — prototipe memerlukan impor lintas lapisan yang sering, yang dilarang dalam FSD dan memperlambat iterasi.
Disarankan memulai dengan struktur Feature-based yang lebih sederhana dan bermigrasi ke FSD ketika jumlah layar melebihi 20, dan tim — 5 pengembang.
Pertanyaan yang Sering Diajukan
Apa perbedaan antara FSD dan arsitektur Feature-based?
Arsitektur Feature-based mengelompokkan kode berdasarkan fitur tanpa aturan impor ketat — fitur Auth dapat mengimpor fitur Profile lain tanpa batasan. FSD menambahkan hierarki lapisan dan aturan lapisan hanya melihat ke bawah. Dalam Feature-based, entitas dan fitur dapat berada di level yang sama dan saling mengimpor; dalam FSD, entitas berada di bawah fitur, dan fitur mengimpor entitas, bukan sebaliknya. Feature-based cocok untuk proyek kecil, FSD — untuk proyek besar.
Bagaimana cara menguji irisan yang terisolasi?
Isolasi irisan menyederhanakan pengujian modular — setiap irisan diuji secara independen dengan mengganti ketergantungan lapisan di bawahnya. Untuk fitur auth, cukup melakukan mock pada entitas user. Tes integrasi memeriksa API publik irisan. Dalam modul Gradle Android, fitur berisi direktori test sendiri dengan tes Reducer, klien API, dan UI (melalui Compose Test). Di iOS, irisan-paket mencakup tes semua segmen.
Bisakah FSD digunakan dengan Jetpack Compose?
Ya, FSD cocok dengan Jetpack Compose, terutama dalam proyek Android multi-modul. Setiap irisan adalah modul Gradle terpisah dengan API publik melalui direktif exported. Lapisan features berisi fitur Composable (LoginFeature, ProductListFeature), lapisan entities berisi kelas data dan Repository, shared — UI-kit (MaterialTheme-wrapper, komponen kustom). FSD direkomendasikan untuk proyek Compose besar dengan 5+ pengembang.
Lapisan mana yang wajib dan mana opsional?
Lapisan wajib adalah app, shared, entities, dan features. Sisanya (processes, pages, widgets) opsional dan ditambahkan sesuai kebutuhan. Dalam pengembangan mobile, lapisan pages sering digabung dengan routing navigasi, dan widgets diganti dengan shared/ui-kit. Proses (processes) biasanya tidak digunakan dalam proyek mobile — perannya diisi oleh lapisan domain atau logika bisnis di ViewModel. Yang terpenting adalah mematuhi aturan hierarki impor.
Bagaimana FSD terkait dengan Domain-Driven Design?
FSD meminjam dari DDD konsep Bounded Context dan Ubiquitous Language. Setiap irisan sesuai dengan bounded context — batas di mana istilah memiliki makna yang tidak ambigu. Di dalam irisan digunakan bahasa yang seragam (ubiquitous language), dipahami oleh pengembang dan analis bisnis. Misalnya, dalam irisan auth istilah login, kata sandi, token memiliki makna yang sama untuk semua anggota tim, yang mengurangi kesalahpahaman antara analis dan pengembang sebesar 30–50%.
Ringkasan
- Feature-Sliced Design (FSD) — metodologi arsitektur modular dengan pengelompokan kode berdasarkan fitur bisnis (irisan), masing-masing mencakup UI, logika, API, dan tes.
- Tujuh lapisan FSD: app, processes, pages, features, entities, widgets, shared — dengan aturan impor ketat dari atas ke bawah.
- Irisan diisolasi melalui API publik — struktur internal tidak terlihat oleh irisan lain, mencegah ketergantungan siklik.
- Segmen di dalam irisan (ui, model, api, lib, config) mengatur kode berdasarkan kriteria teknis, tetapi tidak wajib untuk irisan kecil.
- Dalam pengembangan mobile, FSD diadaptasi melalui modul Gradle (Android) dan paket Swift (iOS), memberikan isolasi pada level kompilasi.
- Keunggulan utama — pengembangan paralel, isolasi fitur, penggunaan ulang antar proyek.
- Kekurangan utama — redundansi untuk proyek kecil, ambang masuk tinggi, ketidakcocokan dengan pembuatan prototipe cepat.
Kami akan mengembangkan aplikasi seluler turnkey
IT Sectr membuat aplikasi iOS dan Android untuk startup dan bisnis sejak 2017. Kami akan memberi saran dan mengusulkan solusi terbaik.
Baca juga