Feature-Sliced Design: özü ve özellik tabanlı bölme metodolojisi
Feature-Sliced Design'ın ne olduğunu açıklıyoruz — projeyi teknik katmanlar yerine iş özelliklerine göre bölmeye dayanan bir frontend modüler mimari metodolojisidir. Klasik katmanlı mimarinin (denetleyiciler, servisler, depolar) aksine, FSD kodu uygulamanın işlevsel yeteneklerine göre gruplandırır: her özellik kendi mantığını, UI'ını ve verilerini içerir. State of Frontend 2024 anketine göre, React geliştiricilerinin %23'ü FSD'yi birincil mimari metodoloji olarak kullanmakta ve bu da onu saf Feature-based yapıdan sonra en popüler ikinci metodoloji yapmaktadır.
Ana Noktalar
- Feature-Sliced Design (FSD) — kodu iş özelliklerine (dilimlere) göre gruplandıran bir metodolojidir; her biri UI, mantık, API ve testleri içerir.
- Standart FSD yapısı 7 katmandan oluşur: app, processes, pages, features, entities, shared, widgets — her biri katı içe aktarma kurallarına sahiptir.
- FSD'nin ana kuralı — «katmanlar yalnızca aşağıya bakar»: features katmanı entities'i içe aktarabilir, ancak tersi olamaz.
- FSD'nin avantajları: özellik izolasyonu, projeler arasında dilimlerin yeniden kullanımı, çakışmasız paralel geliştirme.
- Ana dezavantaj — küçük projeler için aşırı iç içe geçme: FSD, 10+ geliştirici ve 20+ ekran ile haklı çıkar.
Feature-Sliced Design Nedir?
Feature-Sliced Design (FSD), ilk olarak 2021'de feature-sliced.design topluluğu tarafından önerilen bir frontend uygulama mimarisi metodolojisidir. FSD'nin temel fikri, kodu iş özelliklerine (dilimlere) göre gruplandırmaktır ve her biri kendi kendine yeten bir birimdir: kendi iş mantığını, kullanıcı arayüzünü, API etkileşimini, veri modellerini ve testlerini içerir. Bu, FSD'yi kodun teknik kriterlere (controller, service, repository) göre bölündüğü klasik katmanlı mimariden ayırır.
Metodoloji, Domain-Driven Design (DDD) ve Bounded Context'ten kavramlar ödünç alır: uygulamanın her özelliği, net sınırları olan ayrı bir bounded context'tir. Bir dilimin yalnızca genel API'sini kullanmaları koşuluyla, bir özellik içindeki değişiklikler diğer özellikleri bozmamalıdır. State of Frontend 2024 anketine göre, FSD, React mimarileri arasında popülerlikte ikinci sırada (%23) yer almakta ve yalnızca gayriresmî Feature-based yapının (%31) ardından gelmektedir.
Mobil geliştirmede, FSD, Android modüllerinin ve iOS çerçevelerinin özelliklerine uyum sağlar. IT Sectr'de, 10+ ekranlı ve 3+ takımlı projeler için FSD kullanıyoruz — metodoloji, bağımsız özellik geliştirmeye olanak tanır ve dilim sınırları olmayan bir monorepoya kıyasla git çakışmalarını %40 oranında azaltır.
FSD'nin Yedi Katmanı: Yapı ve İçe Aktarma Kuralları
FSD, her biri belirli bir soyutlama düzeyinde kod içeren yedi hiyerarşik katman tanımlar. Ana mimari kural, katmanların yalnızca alt katmanlardan kod içe aktarabilmesidir. Bu kuralın ihlali (entities'e features katmanını içe aktarmak) mimari bir hata olarak kabul edilir ve bir linter tarafından engellenir.
| Katman | Amaç | İçe Aktarır |
|---|---|---|
| app | Uygulama başlatma, sağlayıcılar, genel stiller, yönlendirme | Herhangi bir katman |
| processes | Birden çok özelliği birleştiren iş süreçleri (uyarlama, ödeme) | pages, features, entities, shared |
| pages | Bir sayfada özellik kompozisyonu, sayfa yönlendirme | features, entities, shared |
| features | Kullanıcı senaryoları: giriş formu, favori listesi, arama filtresi | entities, shared |
| entities | İş varlıkları: User, Product, Order, Cart | shared |
| widgets | Bileşik UI bileşenleri: Header, Sidebar, ArticleCard | shared, entities |
| shared | Araçlar, UI-kit, API istemcisi, yapılandırmalar — iş mantığından bağımsız | Yalnızca harici kütüphaneler |
Bir FSD projesinin dizin yapısı örneği:
Metin
src/
├── app/ // Uygulama katmanı
│ ├── providers/
│ ├── router/
│ └── styles/
├── pages/ // Sayfalar — özellik kompozisyonu
│ └── main/
├── features/ // Özellikler — kullanıcı senaryoları
│ ├── auth/ // Dilim «Kimlik Doğrulama»
│ │ ├── ui/
│ │ ├── model/
│ │ └── api/
│ └── productList/ // Dilim «Ürün Listesi»
│ ├── ui/
│ └── model/
├── entities/ // İş varlıkları
│ ├── user/
│ └── product/
├── widgets/ // Bileşik bileşenler
│ └── header/
└── shared/ // Paylaşılan araçlar ve UI-kit
└── ui/«Katmanlar yalnızca aşağıya bakar» kuralı FSD'nin temel taşıdır. feature auth, entity user'ı içe aktarırsa — bu doğrudur. entity user, feature auth'u içe aktarmaya başlarsa — bu döngüsel bir bağımlılık ve izolasyon ihlalidir. Bu kuralı sağlamak için ESLint eklentileri (eslint-plugin-fsd) veya dilimlerin genel API'sinin özel linter'ları kullanılır.
Dilimler: İş Alanlarının Sınırları
Dilim (Slice) — FSD'deki ana gruplandırma birimidir ve bir iş özelliğine veya varlığına karşılık gelir. Her dilim, yedi katmandan (features, entities, widgets, pages) birinin içinde bulunur ve belirli bir işlevselliği uygulamak için eksiksiz bir kod kümesi içerir: UI bileşenleri, veri modeli, API istemcisi, sabitler ve testler.
Dilim sınırları iş alanına göre tanımlanır: feature auth, yetkilendirmeyle ilgili her şeyi (giriş formu, kayıt formu, şifre sıfırlama) içerir; entity user, User modelini, UserRepository'yi ve serileştirmeyi içerir. Sınırlar çakışmamalıdır: feature auth, kullanıcı verilerine ihtiyaç duyarsa — mantığı çoğaltmak yerine entity user'ı içe aktarır. Mobil geliştirmede, bir FSD dilimi genellikle Android'de bir Gradle modülüne veya iOS'ta bir Swift paketine karşılık gelir.
Dilimler kesinlikle izole edilmiştir: bir dilimin iç yapısı diğer dilimler için görünmezdir. Dilimler arasındaki etkileşim için genel bir API kullanılır — yalnızca harici kullanıma izin verilenleri dışa aktaran bir index.ts/index.js dosyası. Geri kalan her şey özel modüllerdir. Bu yaklaşım, tesadüfi bağımlılıkları önler ve yeniden düzenlemeyi basitleştirir: bir dilimin özel uygulamasını değiştirmek diğer dilimleri etkilemez.
Segmentler: Bir Dilim İçinde UI, API, Model, Lib
Her FSD dilimi içinde kod ayrıca segmentler — tüm dilimlerde tekrarlanan teknik kategoriler — tarafından düzenlenir. Standart segment seti şunları içerir: ui (arayüz bileşenleri), model (iş mantığı, Store, Actions, Reducer), api (sunucu istekleri, mutasyonlar), lib (araçlar ve yardımcılar) ve config (özellik yapılandırması).
| Segment | İçerik | Örnek |
|---|---|---|
| ui/ | React/Vue/SwiftUI bileşenleri, stiller, Storybook | LoginForm.tsx, login.module.css |
| model/ | Store, Reducer, Actions, tipler, sözleşmeler | LoginStore.ts, authReducer.ts |
| api/ | HTTP istemcileri, mutasyonlar, RPC çağrıları | authApi.ts, loginMutation.ts |
| lib/ | Yardımcı işlevler, doğrulayıcılar | validateEmail.ts, formatPhone.ts |
| config/ | Sabitler, özellik yapılandırması | authConfig.ts, endpoints.ts |
Segmentler bir tavsiyedir, katı bir kural değildir. Bir dilim küçükse, segmentler birleştirilebilir. Büyük dilimler (10+ dosyalı bir özellik) için segmentasyon zorunludur — aksi takdirde iç yapı hızla 50 dosyalık bir «sepete» dönüşür ve gerekli bileşeni bulmak dakikalar alır. Mobil geliştirmede, segmentler genellikle türe göre dosya yapısıyla değiştirilir: her özellik, iç türlere sahip ayrı bir Swift dosyası veya Kotlin sınıfıdır.
Mobil Geliştirmede FSD: Android ve iOS'a Uyarlama
Mobil geliştirmede, FSD platforma özgü özelliklere uyum sağlar — Android'in modüler yapısı (Gradle modülleri) ve Swift Package Manager. Android uyarlaması, her dilimin kendi build.gradle'ı olan ayrı bir Gradle modülü olduğunu varsayar. feature-auth, feature-profile, entity-user, shared-ui modülleri, derleme düzeyinde birbirinden izole edilmiştir: feature-auth, dependencies'te belirtilmedikçe feature-profile'ı içe aktaramaz.
iOS uyarlaması, Swift Package Manager üzerine kurulmuştur: her dilim, genel bir API'ye sahip bir Swift paketidir. TCA projelerinde, feature.auth dilimi kendi Reducer, Store, View ve API istemcisini içerir. Swift Community Survey 2024'e göre, TCA kullanan iOS projelerinin %28'i FSD'ye yakın bir dilim mimarisi kullanmaktadır.
Mobil FSD uyarlamasının ana sorunu, shared katmanının çoğaltılmasıdır. Mobil geliştirmede, UI bileşenleri (shared/ui) genellikle platforma bağlıdır (Android Views vs Jetpack Compose vs SwiftUI), bu da her teknoloji için ayrı shared modülleri gerektirir. FSD'de, shared katmanı genellikle platformdan bağımsızdır (araçlar, yapılandırmalar), UI-kit ise ayrı bir modüle veya bileşen kütüphanesine taşınır.
Feature-Sliced Design'ın Artıları ve Eksileri
Avantajları FSD'nin, 10+ geliştiricili büyük projelerde belirgin hale gelir. Her geliştirici veya takım, başkalarının koduna dokunmadan kendi dilimi üzerinde çalışır. Git çakışmaları %40–60 oranında azalır (feature-sliced.design vaka çalışmalarından veriler). Yeni özellikler, yalnızca dilimlerin genel API'sini kullanmaları koşuluyla, mevcut olanları bozma riski olmadan eklenir. Bir özelliği yeniden düzenlemek, diğerlerinde değişiklik gerektirmez — genel API'yi koruyarak bir dilim içinde ui/model/api'yi yeniden yazmak yeterlidir.
| Yön | FSD | Feature-based (FSD'siz) | Katmanlı Mimari |
|---|---|---|---|
| Özellik izolasyonu | Katı | Orta | Düşük |
| Paralel geliştirme | 10+ takım | 3–5 takım | 1–2 takım |
| Projeler arası yeniden kullanım | Evet (dilim paketleri) | Yalnızca kopyala-yapıştır ile | Shared modüller aracılığıyla |
| Giriş engeli | Yüksek | Düşük | Orta |
| Gradle izolasyonu (Android) | Yerel (modüller) | Yerel (modüller) | Zayıf |
Dezavantajları FSD'nin — küçük projeler için aşırı iç içe geçme. Bir uygulama 3–5 ekrandan oluşuyorsa, yedi katman ve her dilim içinde segmentasyon, uygulamanın kendisinden daha fazla organizasyon kodu oluşturur. Giriş engeli yüksektir: yeni geliştiriciler metodolojiyi öğrenmek için 2–4 hafta harcar. Ayrıca, FSD hızlı prototipleme ile zayıf uyumludur — prototipleme, FSD'de yasak olan ve yinelemeleri yavaşlatan sık katmanlar arası içe aktarmalar gerektirir.
Daha basit bir Feature-based yapıyla başlamanız ve ekran sayısı 20'yi, takım 5 geliştiriciyi aştığında FSD'ye geçmeniz önerilir.
Sıkça Sorulan Sorular
FSD ve Feature-based mimari arasındaki fark nedir?
Feature-based mimari, kodu katı içe aktarma kuralları olmadan özelliklere göre gruplandırır — feature Auth, kısıtlama olmaksızın başka bir feature Profile'ı içe aktarabilir. FSD, bir katman hiyerarşisi ve «katmanlar yalnızca aşağıya bakar» kuralını ekler. Feature-based'de, entity ve feature aynı düzeyde olabilir ve birbirlerini içe aktarabilir; FSD'de, entity feature'ın altındadır ve feature, entity'yi içe aktarır, tersi değil. Feature-based küçük projeler için uygundur, FSD büyük projeler için.
İzole edilmiş bir dilim nasıl test edilir?
Dilim izolasyonu, birim testini basitleştirir — her dilim, alt katmanların bağımlılıklarını taklit ederek bağımsız olarak test edilir. feature auth için, entity user'ı taklit etmek yeterlidir. Entegrasyon testleri, dilimin genel API'sini doğrular. Android'de, bir özelliğin Gradle modülü, Reducer, API istemcisi ve UI (Compose Test aracılığıyla) testleriyle kendi test dizinini içerir. iOS'ta, bir dilim paketi tüm segmentlerin testlerini içerir.
FSD, Jetpack Compose ile kullanılabilir mi?
Evet, FSD, özellikle çok modüllü Android projelerinde Jetpack Compose ile iyi çalışır. Her dilim, exported yönergesi aracılığıyla genel API'ye sahip ayrı bir Gradle modülüdür. features katmanı Composable özellikler (LoginFeature, ProductListFeature) içerir, entities katmanı veri sınıflarını ve Repository'yi içerir ve shared, UI-kit'i (MaterialTheme-wrapper, özel bileşenler) içerir. FSD, 5+ geliştiricili büyük Compose projeleri için önerilir.
Hangi katmanlar zorunlu, hangileri isteğe bağlıdır?
Zorunlu katmanlar app, shared, entities ve features'dır. Diğerleri (processes, pages, widgets) isteğe bağlıdır ve ihtiyaç duyuldukça eklenir. Mobil geliştirmede, pages katmanı genellikle navigasyon yönlendirmesiyle birleştirilir ve widgets, shared/ui-kit ile değiştirilir. Süreçler (processes) genellikle mobil projelerde kullanılmaz — rollerini alan katmanı veya ViewModel'deki iş mantığı üstlenir. Önemli olan, içe aktarma hiyerarşisi kuralına uymaktır.
FSD, Domain-Driven Design ile nasıl ilişkilidir?
FSD, DDD'den Bounded Context ve Ubiquitous Language kavramlarını ödünç alır. Her dilim bir bounded context'e karşılık gelir — terimlerin net bir anlama sahip olduğu bir sınır. Dilim içinde, hem geliştiriciler hem de iş analistleri tarafından anlaşılabilir birleşik bir dil (ubiquitous language) kullanılır. Örneğin, auth diliminde «giriş», «şifre», «token» terimleri tüm ekip üyeleri için aynı anlama sahiptir ve bu da analistler ve geliştiriciler arasındaki yanlış anlamaları %30–50 oranında azaltır.
Özet
- Feature-Sliced Design (FSD) — kodu iş özelliklerine (dilimlere) göre gruplandıran modüler bir mimari metodolojisidir; her biri UI, mantık, API ve testleri içerir.
- FSD'nin yedi katmanı: app, processes, pages, features, entities, widgets, shared — yukarıdan aşağıya katı içe aktarma kuralıyla.
- Dilimler genel API aracılığıyla izole edilir — iç yapı diğer dilimler için görünmezdir, döngüsel bağımlılıkları önler.
- Bir dilim içindeki segmentler (ui, model, api, lib, config) kodu teknik kriterlere göre düzenler, ancak küçük dilimler için zorunlu değildir.
- Mobil geliştirmede, FSD, Gradle modülleri (Android) ve Swift paketleri (iOS) aracılığıyla uyum sağlayarak derleme düzeyinde izolasyonu garanti eder.
- Ana avantajlar — paralel geliştirme, özellik izolasyonu, projeler arası yeniden kullanım.
- Ana dezavantajlar — küçük projeler için gereksizlik, yüksek giriş engeli, hızlı prototipleme ile uyumsuzluk.
Anahtar teslim bir mobil uygulama geliştireceğiz
IT Sectr, 2017'den beri girişimler ve işletmeler için iOS ve Android uygulamaları oluşturmaktadır. Size danışmanlık yapacak ve en iyi çözümü önereceğiz.
Ayrıca okuyun