Feature-Sliced Design: mohiyati, funksiyalarga bo'lish metodologiyasi
Feature-Sliced Design nima ekanligini tushuntiramiz — loyihani texnik qatlamlarga emas, balki biznes funksiyalari bo'yicha ajratishga asoslangan modul frontend arxitektura metodologiyasi. Klassik qatlamli arxitekturadan (kontrollerlar, xizmatlar, repozitoriyalar) farqli o'laroq, FSD kodni ilovaning funksional imkoniyatlari bo'yicha guruhlaydi: har bir funksiya o'z mantiqi, interfeysi va ma'lumotlarini o'z ichiga oladi. State of Frontend 2024 so'rovi ma'lumotlariga ko'ra, FSD React dasturchilarining 23% tomonidan asosiy arxitektura metodologiyasi sifatida qo'llaniladi, bu uni sof Feature-based strukturasidan keyin ikkinchi eng mashhur qiladi.
Asosiy fikrlar
- Feature-Sliced Design (FSD) — kodni biznes funksiyalari (slayslar) bo'yicha guruhlaydigan metodologiya, har biri UI, mantiq, API va testlarni o'z ichiga oladi.
- FSD ning standart strukturasi 7 qatlamdan iborat: app, processes, pages, features, entities, shared, widgets — har biri qat'iy import qoidalari bilan.
- FSD ning asosiy qoidasi — «qatlamlar faqat pastga qaraydi»: features qatlami entities ni import qilishi mumkin, aksincha emas.
- FSD ning afzalliklari: funksiyalarning izolyatsiyasi, slayslarning loyihalar o'rtasida qayta ishlatilishi, konfliktsiz parallel rivojlanish.
- Asosiy kamchilik — kichik loyihalar uchun haddan tashqari ichki joylashish: FSD 10+ dasturchi va 20+ ekran bo'lganda asoslanadi.
Feature-Sliced Design nima?
Feature-Sliced Design (FSD) — birinchi marta 2021 yilda feature-sliced.design jamoasi tomonidan taklif qilingan frontend ilovalarining arxitektura metodologiyasi. FSD ning asosiy g'oyasi — kodni biznes funksiyalari (slayslar) bo'yicha guruhlash, har biri o'z-o'zini ta'minlaydigan birlikdir: o'z biznes mantiqi, foydalanuvchi interfeysi, API bilan ishlash, ma'lumot modellari va testlarini o'z ichiga oladi. Bu FSD ni kodni texnik belgiga ko'ra (controller, service, repository) ajratadigan klassik qatlamli arxitekturadan farqlaydi.
Metodologiya Domain-Driven Design (DDD) va Bounded Context tushunchalarini o'zlashtiradi: ilovaning har bir funksiyasi aniq chegaralarga ega alohida bounded context dir. Bir funksiya ichidagi o'zgarishlar, agar ular faqat slaysning umumiy API sidan foydalansa, boshqa funksiyalarni buzmasligi kerak. State of Frontend 2024 so'rovi ma'lumotlariga ko'ra, FSD React arxitekturalari orasida mashhurlik bo'yicha ikkinchi o'rinda (23%), faqat norasmiy Feature-based strukturasidan (31%) ortda qoladi.
Mobil ishlab chiqishda FSD Android modullari va iOS freymvorklarining xususiyatlariga moslashtiriladi. IT Sectr da biz FSD ni 10+ ekran va 3+ jamoasi bo'lgan loyihalar uchun ishlatamiz — metodologiya funksiyalarni mustaqil rivojlantirishga imkon beradi va slays chegaralari bo'lmagan monorepozitoriy bilan solishtirganda git dagi konfliktlar sonini 40% ga kamaytiradi.
FSD ning yetti qatlami: strukturasi va import qoidalari
FSD yetti ierarxik qatlamni belgilaydi, har biri ma'lum abstraksiya darajasidagi kodni o'z ichiga oladi. Asosiy arxitektura qoidasi — qatlamlar faqat pastki qatlamlardan kodni import qilishi mumkin. Bu qoidaning buzilishi (features qatlamining entities da importi) arxitektura xatosi hisoblanadi va linter tomonidan bloklanadi.
| Qatlam | Maqsad | Import qiladi |
|---|---|---|
| app | Ilovani ishga tushirish, provayderlar, global stillar, marshrutlash | Istalgan qatlamlar |
| processes | Bir necha funksiyani birlashtiruvchi biznes jarayonlar (onboarding, to'lov) | pages, features, entities, shared |
| pages | Sahifadagi funksiyalar kompozitsiyasi, sahifa marshrutlashi | features, entities, shared |
| features | Foydalanuvchi stsenariylari: kirish formasi, sevimlilar ro'yxati, qidiruv filtri | entities, shared |
| entities | Biznes ob'ektlari: User, Product, Order, Cart | shared |
| widgets | UI kompozitsion komponentlari: Header, Sidebar, ArticleCard | shared, entities |
| shared | Yordamchi vositalar, UI-kit, API-klient, konfiglar — biznes mantiqidan mustaqil | Faqat tashqi kutubxonalar |
FSD loyihasining katalog strukturasi namunasi:
Matnli
src/
├── app/ // Ilova qatlami
│ ├── providers/
│ ├── router/
│ └── styles/
├── pages/ // Sahifalar — funksiyalar kompozitsiyasi
│ └── main/
├── features/ // Funksiyalar — foydalanuvchi stsenariylari
│ ├── auth/ // Slays «Avtorizatsiya»
│ │ ├── ui/
│ │ ├── model/
│ │ └── api/
│ └── productList/ // Slays «Mahsulotlar ro'yxati»
│ ├── ui/
│ └── model/
├── entities/ // Biznes ob'ektlari
│ ├── user/
│ └── product/
├── widgets/ // Kompozitsion komponentlar
│ └── header/
└── shared/ // Umumiy yordamchi vositalar va UI-kit
└── ui/«Qatlamlar faqat pastga qaraydi» qoidasi — FSD ning asosiy tamali. Agar auth funksiyasi user ob'ektini import qilsa — bu to'g'ri. Agar user ob'ekti auth funksiyasini import qila boshlasa — bu tsiklik bog'liqlik va izolyatsiyaning buzilishidir. Qoidaga rioya qilishni ta'minlash uchun ESLint plaginlari (eslint-plugin-fsd) yoki slayslarning umumiy API si uchun o'z linterlaridan foydalaniladi.
Slayslar: biznes domenlarining chegaralari
Slays (slice) — FSD da bir biznes funksiyasi yoki ob'ektiga mos keladigan asosiy guruhlash birligi. Har bir slays yetti qatlamdan birining (features, entities, widgets, pages) ichida joylashgan va aniq funksionallikni amalga oshirish uchun to'liq kod to'plamini o'z ichiga oladi: UI komponentlari, ma'lumot modeli, API-klient, konstantalar va testlar.
Slayslarning chegaralari biznes domeni bilan belgilanadi: auth funksiyasi avtorizatsiya bilan bog'liq hamma narsani o'z ichiga oladi (kirish formasi, ro'yxatdan o'tish formasi, parolni tiklash); user ob'ekti User modeli, UserRepository va seriyalashni o'z ichiga oladi. Chegaralar kesishmasligi kerak: agar auth funksiyasiga foydalanuvchi haqida ma'lumot kerak bo'lsa — u user ob'ektini import qiladi, mantiqni nusxalamaydi. Mobil ishlab chiqishda FSD slaysi ko'pincha Android da Gradle moduliga yoki iOS da Swift paketiga mos keladi.
Slayslar qat'iy izolyatsiya qilingan: bir slaysning ichki tuzilishi boshqa slayslar uchun ko'rinmasdir. Slayslar o'rtasidagi o'zaro ta'sir uchun umumiy API ishlatiladi — tashqaridan foydalanishga ruxsat berilgan narsalarni eksport qiluvchi index.ts/index.js fayli. Qolgan hamma narsa xususiy modullardir. Bu yondashuv tasodifiy bog'liqliklarning oldini oladi va refaktoringni soddalashtiradi: bir slaysning xususiy amalga oshirilishini o'zgartirish boshqa slayslarga ta'sir qilmaydi.
Segmentlar: slays ichida UI, API, Model, Lib
Har bir FSD slaysi ichida kod qo'shimcha ravishda segmentlar bo'yicha tashkil etiladi — barcha slayslarda takrorlanadigan texnik toifalar. Standart segmentlar to'plami ui (interfeys komponentlari), model (biznes mantiqi, Store, Actions, Reducer), api (server so'rovlari, mutatsiyalar), lib (yordamchi vositalar va helperlar) va config (funksiya konfiguratsiyasi) ni o'z ichiga oladi.
| Segment | Mazmuni | Misol |
|---|---|---|
| ui/ | React/Vue/SwiftUI komponentlari, stillar, Storybook | LoginForm.tsx, login.module.css |
| model/ | Store, Reducer, Actions, tiplar, kontraktlar | LoginStore.ts, authReducer.ts |
| api/ | HTTP-klientlar, mutatsiyalar, RPC chaqiruvlari | authApi.ts, loginMutation.ts |
| lib/ | Yordamchi funksiyalar, validatorlar | validateEmail.ts, formatPhone.ts |
| config/ | Konstantalar, funksiya konfiguratsiyasi | authConfig.ts, endpoints.ts |
Segmentlar tavsiya, qat'iy qoida emas. Slays kichik bo'lsa, segmentlar birlashtirilishi mumkin. Katta slayslar uchun (10+ faylli funksiya) segmentatsiya majburiy — usiz ichki tuzilma tezda 50 faylli «savat»ga aylanadi, unda kerakli komponentni topish daqiqalar oladi. Mobil ishlab chiqishda segmentlar ko'pincha fayl tuzilmasining turi bo'yicha tashkil etilishi bilan almashtiriladi: har bir funksiya alohida Swift fayli yoki ichki tiplarga ega Kotlin klassi.
Mobil ishlab chiqishda FSD: Android va iOS ga moslashish
Mobil ishlab chiqishda FSD platforma xususiyatlariga — Android ning modul tuzilmasiga (Gradle modullari) va Swift Package Manager ga moslashtiriladi. Android moslashuvi har bir slaysning o'z build.gradle fayliga ega alohida Gradle moduli ekanligini nazarda tutadi. feature-auth, feature-profile, entity-user, shared-ui modullari kompilyatsiya darajasida bir-biridan izolyatsiya qilingan: agar dependencies da ko'rsatilmagan bo'lsa, feature-auth feature-profile ni import qila olmaydi.
iOS moslashuvi Swift Package Manager ga asoslanadi: har bir slays umumiy API ga ega Swift paketidir. TCA loyihalarida feature.auth slaysi o'z Reducer, Store, View va API-klientini o'z ichiga oladi. Swift Community Survey 2024 ma'lumotlariga ko'ra, TCA bilan iOS loyihalarining 28% FSD ga yaqin bo'lgan slays arxitekturasidan foydalanadi.
Mobil FSD moslashuvining asosiy muammosi — shared qatlamining takrorlanishi. Mobil ishlab chiqishda UI komponentlari (shared/ui) ko'pincha platformaga bog'liq (Android Views vs Jetpack Compose vs SwiftUI), bu har bir texnologiya uchun alohida shared modullarini talab qiladi. FSD da shared qatlami odatda platformadan mustaqil (yordamchi vositalar, konfiglar), UI-kit esa alohida modulga yoki komponentlar kutubxonasiga chiqariladi.
Feature-Sliced Design ning ijobiy va salbiy tomonlari
Afzalliklari FSD 10+ dasturchisi bo'lgan katta loyihalarda sezilarli bo'ladi. Har bir dasturchi yoki jamoa o'z slaysi bilan shug'ullanadi, boshqalarning kodiga tegmaydi. Git dagi konfliktlar 40–60% ga kamayadi (feature-sliced.design case studies ma'lumotlari). Yangi funksiyalar, agar ular faqat slayslarning umumiy API sidan foydalansa, mavjudlarini buzish xavfisiz qo'shiladi. Bir funksiyaning refaktoringi boshqalarni o'zgartirishni talab qilmaydi — umumiy API ni saqlab, bir slays ichida ui/model/api ni qayta yozish kifoya.
| Aspekt | FSD | Feature-based (FSD siz) | Qatlamli arxitektura |
|---|---|---|---|
| Funksiyalarning izolyatsiyasi | Qat'iy | O'rtacha | Past |
| Parallel rivojlanish | 10+ jamoa | 3–5 jamoa | 1–2 jamoa |
| Loyihalar o'rtasida qayta ishlatish | Ha (slays-paketlar) | Faqat copy-paste orqali | Shared modullar orqali |
| Kirish chegarasi | Yuqori | Past | O'rtacha |
| Gradle izolyatsiyasi (Android) | Tabiiy (modullar) | Tabiiy (modullar) | Zaif |
Kamchiliklari FSD — kichik loyihalar uchun haddan tashqari ichki joylashish. Ilova 3–5 ekrandan iborat bo'lsa, yetti qatlam va har bir slays ichida segmentatsiya ilovaning o'zidan ko'ra ko'proq tashkiliy kod yaratadi. Kirish chegarasi yuqori: yangi dasturchilar metodologiyani o'zlashtirish uchun 2–4 hafta sarflaydi. Shuningdek, FSD tez prototiplash bilan yomon mos keladi — prototip FSD da taqiqlangan va iteratsiyalarni sekinlashtiradigan tez-tez cross-layer importlarni talab qiladi.
Soddaroq Feature-based strukturasi bilan boshlash va ekranlar soni 20 dan, jamoa esa 5 dasturchidan oshganda FSD ga migratsiya qilish tavsiya etiladi.
Tez-tez beriladigan savollar
FSD va Feature-based arxitekturasi o'rtasidagi farq nima?
Feature-based arxitekturasi kodni funksiyalar bo'yicha qat'iy import qoidalarisiz guruhlaydi — Auth funksiyasi cheklovlarsiz boshqa Profile funksiyasini import qilishi mumkin. FSD qatlamlar ierarxiyasi va «qatlamlar faqat pastga qaraydi» qoidasini qo'shadi. Feature-based da entity va feature bir xil darajada bo'lishi va bir-birini import qilishi mumkin; FSD da entity feature dan pastda joylashgan va feature entity ni import qiladi, aksincha emas. Feature-based kichik loyihalar uchun mos, FSD — katta loyihalar uchun.
Izolyatsiya qilingan slaysni qanday test qilish kerak?
Slayslarning izolyatsiyasi modul testini soddalashtiradi — har bir slays pastki qatlamlarning bog'liqliklarini almashtirish orqali mustaqil test qilinadi. Auth funksiyasi uchun user ob'ektini mock qilish kifoya. Integratsiya testlari slaysning umumiy API sini tekshiradi. Android Gradle modulida funksiya Reducer, API-klient va UI testlari (Compose Test orqali) bilan o'z test katalogiga ega. iOS da slays-paket barcha segmentlarning testlarini o'z ichiga oladi.
FSD ni Jetpack Compose bilan ishlatish mumkinmi?
Ha, FSD Jetpack Compose bilan yaxshi mos keladi, ayniqsa ko'p modulli Android loyihalarida. Har bir slays exported direktivasi orqali umumiy API ga ega alohida Gradle modulidir. Features qatlami Composable funksiyalar (LoginFeature, ProductListFeature), entities qatlami — data sinflari va Repository, shared — UI-kit (MaterialTheme-wrapper, shaxsiy komponentlar) ni o'z ichiga oladi. FSD 5+ dasturchisi bo'lgan katta Compose loyihalari uchun tavsiya etiladi.
Qaysi qatlamlar majburiy va qaysilari ixtiyoriy?
Majburiy qatlamlar — app, shared, entities va features. Qolganlari (processes, pages, widgets) ixtiyoriy va zarurat bo'lganda qo'shiladi. Mobil ishlab chiqishda pages qatlami ko'pincha navigatsiya marshrutlashi bilan birlashtiriladi, widgets esa shared/ui-kit bilan almashtiriladi. Jarayonlar (processes) odatda mobil loyihalarda ishlatilmaydi — ularning rolini domain qatlami yoki ViewModel dagi biznes mantiqi bajaradi. Asosiysi, import ierarxiyasi qoidasiga rioya qilishdir.
FSD Domain-Driven Design bilan qanday bog'liq?
FSD DDD dan Bounded Context va Ubiquitous Language tushunchalarini o'zlashtiradi. Har bir slays bounded context ga mos keladi — ichida atamalar bir ma'noga ega bo'lgan chegara. Slays ichida dasturchilar va biznes tahlilchilar uchun tushunarli bo'lgan yagona til (ubiquitous language) ishlatiladi. Masalan, auth slaysida «login», «parol», «token» atamalari jamoa barcha a'zolari uchun bir xil ma'noga ega, bu tahlilchilar va dasturchilar o'rtasidagi tushunmovchiliklar sonini 30–50% ga kamaytiradi.
Xulosa
- Feature-Sliced Design (FSD) — kodni biznes funksiyalari (slayslar) bo'yicha guruhlaydigan modul arxitektura metodologiyasi, har biri UI, mantiq, API va testlarni o'z ichiga oladi.
- FSD ning yetti qatlami: app, processes, pages, features, entities, widgets, shared — yuqoridan pastga qat'iy import qoidasi bilan.
- Slayslar umumiy API orqali izolyatsiya qilingan — ichki tuzilma boshqa slayslar uchun ko'rinmas, bu tsiklik bog'liqliklarning oldini oladi.
- Slays ichidagi segmentlar (ui, model, api, lib, config) kodni texnik belgiga ko'ra tashkil qiladi, lekin kichik slayslar uchun majburiy emas.
- Mobil ishlab chiqishda FSD Gradle modullari (Android) va Swift paketlari (iOS) orqali moslashtiriladi, kompilyatsiya darajasida izolyatsiyani ta'minlaydi.
- Asosiy afzalliklari — parallel rivojlanish, funksiyalarning izolyatsiyasi, loyihalar o'rtasida qayta ishlatish.
- Asosiy kamchiliklari — kichik loyihalar uchun haddan tashqari ko'plik, yuqori kirish chegarasi, tez prototiplash bilan mos kelmaslik.
Biz kalit topshirig'i bilan mobil ilovani ishlab chiqamiz
IT Sectr 2017-yildan beri startaplar va korxonalar uchun iOS va Android ilovalarini yaratadi. Biz sizga maslahat beramiz va eng yaxshi yechimni taklif qilamiz.
Shuningdek o'qing