Feature-Sliced Design: mahiyyəti, funksiyalara bölmə metodologiyası

Feature-Sliced Design nədir?

Feature-Sliced Design (FSD) — ilk dəfə 2021-ci ildə feature-sliced.design icması tərəfindən təklif edilən frontend tətbiqlərinin arxitektura metodologiyası. FSD-nin əsas ideyası kodu biznes funksiyalarına (slayslara) görə qruplaşdırmaqdır, hər biri öz-özünə kifayət edən vahiddir: öz biznes məntiqi, istifadəçi interfeysi, API işi, məlumat modelləri və testləri ehtiva edir. Bu, FSD-ni kodu texniki əlamətə görə bölən klassik təbəqəli arxitekturadan (controller, service, repository) fərqləndirir.

Metodologiya Domain-Driven Design (DDD) və Bounded Context konsepsiyalarını mənimsəyir: tətbiqin hər bir funksiyası aydın sərhədləri olan ayrıca bounded context-dir. Bir funksiya daxilindəki dəyişikliklər, yalnız slaysın ictimai API-indən istifadə edirlərsə, digər funksiyaları pozmamalıdır. State of Frontend 2024 sorğusunun məlumatlarına görə, FSD React arxitekturaları arasında populyarlıq baxımından ikinci yerdədir (23%), yalnız qeyri-rəsmi Feature-based strukturundan (31%) geri qalır.

Mobil inkişafda FSD Android modullarının və iOS freymvorklarının xüsusiyyətlərinə uyğunlaşdırılır. IT Sectr-də biz FSD-ni 10+ ekran və 3+ komandası olan layihələr üçün istifadə edirik — metodologiya funksiyaları müstəqil inkişaf etdirməyə imkan verir və slays sərhədləri olmayan monorepozitoriya ilə müqayisədə git-də konfliktlərin sayını 40% azaldır.

FSD-nin yeddi təbəqəsi: struktur və idxal qaydaları

FSD yeddi iyerarxik təbəqə müəyyən edir, hər biri müəyyən abstraksiya səviyyəsində kod ehtiva edir. Əsas arxitektura qaydası — təbəqələr yalnız aşağı təbəqələrdən kodu idxal edə bilər. Bu qaydanın pozulması (features təbəqəsinin entities-də idxalı) arxitektura səhvi hesab olunur və linter tərəfindən bloklanır.

FSD layihəsinin kataloq strukturunun nümunəsi:

src/
├── app/                    // Tətbiq təbəqəsi
│   ├── providers/
│   ├── router/
│   └── styles/
├── pages/                   // Səhifələr — funksiyaların kompozisiyası
│   └── main/
├── features/                // Funksiyalar — istifadəçi ssenariləri
│   ├── auth/                // Slays «Avtorizasiya»
│   │   ├── ui/
│   │   ├── model/
│   │   └── api/
│   └── productList/         // Slays «Məhsul siyahısı»
│       ├── ui/
│       └── model/
├── entities/                // Biznes varlıqları
│   ├── user/
│   └── product/
├── widgets/                 // Kompozisiya komponentləri
│   └── header/
└── shared/                  // Ümumi köməkçi alətlər və UI-kit
    └── ui/

«Təbəqələr yalnız aşağı baxır» qaydası — FSD-nin təməl daşı. Əgər auth funksiyası user varlığını idxal edirsə — bu düzgündür. Əgər user varlığı auth funksiyasını idxal etməyə başlayırsa — bu tsiklik asılılıq və izolyasiyanın pozulmasıdır. Qaydaya riayət olunmasını təmin etmək üçün ESLint plaginlərindən (eslint-plugin-fsd) və ya slaysların ictimai API-si üçün öz linterlərindən istifadə olunur.

Slayslar: biznes domenlərinin sərhədləri

Slays (slice) — FSD-də bir biznes funksiyasına və ya varlığa uyğun gələn əsas qruplaşdırma vahidi. Hər bir slays yeddi təbəqədən birinin (features, entities, widgets, pages) daxilində yerləşir və konkret funksionallığı həyata keçirmək üçün tam kod dəstini ehtiva edir: UI komponentləri, məlumat modeli, API-klient, sabitlər və testlər.

Slaysların sərhədləri biznes domeni ilə müəyyən edilir: auth funksiyası avtorizasiya ilə bağlı hər şeyi əhatə edir (giriş forması, qeydiyyat forması, şifrənin sıfırlanması); user varlığı User modelini, UserRepository və serializasiyanı əhatə edir. Sərhədlər kəsişməməlidir: əgər auth funksiyasına istifadəçi haqqında məlumat lazımdırsa — o, user varlığını idxal edir, məntiqi kopyalamır. Mobil inkişafda FSD slaysı tez-tez Android-də Gradle moduluna və ya iOS-da Swift paketinə uyğun gəlir.

Slayslar ciddi şəkildə izolyasiya olunub: bir slaysın daxili strukturu digər slayslar üçün görünməzdir. Slayslar arasında qarşılıqlı əlaqə üçün ictimai API istifadə olunur — yalnız kənardan istifadəyə icazə veriləni ixrac edən index.ts/index.js faylı. Qalan hər şey özəl modullardır. Bu yanaşma təsadüfi asılılıqların qarşısını alır və refaktorinqi asanlaşdırır: bir slaysın özəl tətbiqinin dəyişdirilməsi digər slayslara təsir göstərmir.

Seqmentlər: slays daxilində UI, API, Model, Lib

Hər bir FSD slaysı daxilində kod əlavə olaraq seqmentlər üzrə təşkil olunur — bütün slayslarda təkrarlanan texniki kateqoriyalar. Standart seqment dəsti ui (interfeys komponentləri), model (biznes məntiqi, Store, Actions, Reducer), api (server sorğuları, mutasiyalar), lib (köməkçi alətlər və helperlər) və config (funksiya konfiqurasiyası) daxildir.

Seqmentlər tövsiyədir, ciddi qayda deyil. Slays kiçikdirsə, seqmentlər birləşdirilə bilər. Böyük slayslar üçün (10+ faylı olan funksiya) seqmentasiya məcburidir — onsuz daxili struktur tez bir zamanda 50 fayllı «səbət»ə çevrilir, burada lazımi komponenti tapmaq dəqiqələr çəkir. Mobil inkişafda seqmentlər tez-tez fayl strukturunun növə görə təşkili ilə əvəz olunur: hər bir funksiya ayrıca Swift faylı və ya daxili tipləri olan Kotlin sinfi.

Mobil inkişafda FSD: Android və iOS-a uyğunlaşma

Mobil inkişafda FSD platforma xüsusiyyətlərinə — Android-in modul strukturuna (Gradle modulları) və Swift Package Manager-ə uyğunlaşdırılır. Android uyğunlaşması hər bir slaysın öz build.gradle faylı olan ayrıca Gradle modulu olduğunu nəzərdə tutur. feature-auth, feature-profile, entity-user, shared-ui modulları kompilyasiya səviyyəsində bir-birindən izolyasiya olunub: əgər dependencies-də göstərilməyibsə, feature-auth feature-profile-i idxal edə bilməz.

iOS uyğunlaşması Swift Package Manager-ə əsaslanır: hər bir slays ictimai API-si olan Swift paketidir. TCA layihələrində feature.auth slaysı öz Reducer, Store, View və API-klientini ehtiva edir. Swift Community Survey 2024 məlumatlarına görə, TCA ilə iOS layihələrinin 28%-i FSD-yə yaxın olan slays arxitekturasından istifadə edir.

Mobil FSD uyğunlaşmasının əsas problemi — shared təbəqəsinin təkrarlanmasıdır. Mobil inkişafda UI komponentləri (shared/ui) tez-tez platformadan asılıdır (Android Views vs Jetpack Compose vs SwiftUI), bu da hər bir texnologiya üçün ayrıca shared modulları tələb edir. FSD-də shared təbəqəsi adətən platformadan asılı deyil (köməkçi alətlər, konfiqlər), UI-kit isə ayrıca modula və ya komponentlər kitabxanasına çıxarılır.

Feature-Sliced Design-ın müsbət və mənfi cəhətləri

Üstünlüklər FSD 10+ tərtibatçısı olan böyük layihələrdə nəzərə çarpır. Hər bir tərtibatçı və ya komanda öz slaysı ilə məşğul olur, başqalarının koduna toxunmadan. Git-də konfliktlər 40–60% azalır (feature-sliced.design case studies məlumatları). Yeni funksiyalar, yalnız slaysların ictimai API-indən istifadə edərlərsə, mövcud olanları sındırmaq riski olmadan əlavə edilir. Bir funksiyanın refaktorinqi digərlərinin dəyişdirilməsini tələb etmir — ictimai API-ni saxlayaraq bir slays daxilində ui/model/api-ni yenidən yazmaq kifayətdir.

Çatışmazlıqlar FSD — kiçik layihələr üçün həddindən artıq iç-içəlik. Tətbiq 3–5 ekrandan ibarətdirsə, yeddi təbəqə və hər bir slays daxilində seqmentasiya tətbiqin özündən daha çox təşkilati kod yaradır. Giriş həddi yüksəkdir: yeni tərtibatçılar metodologiyanı mənimsəmək üçün 2–4 həftə sərf edirlər. Həmçinin FSD sürətli prototipləşdirmə ilə zəif uyğunlaşır — prototip FSD-də qadağan olunan və iterasiyaları yavaşladan tez-tez cross-layer idxalları tələb edir.

Daha sadə Feature-based strukturu ilə başlamaq və ekranların sayı 20-ni, komanda isə 5 tərtibatçını keçdikdə FSD-yə miqrasiya etmək tövsiyə olunur.