Feature-Sliced Design: جوہر اور فیچر پر مبنی تقسیم کا طریقہ کار
وضاحت کرتے ہیں کہ Feature-Sliced Design کیا ہے — ایک فرنٹ اینڈ ماڈیولر آرکیٹیکچر طریقہ کار جو پروجیکٹ کو تکنیکی پرتوں کے بجائے کاروباری فیچرز کے مطابق تقسیم کرنے پر مبنی ہے۔ کلاسیکی پرت دار آرکیٹیکچر (کنٹرولرز، سروسز، ریپوزٹریز) کے برعکس، FSD کوڈ کو ایپلیکیشن کی فعال صلاحیتوں کے مطابق گروپ کرتا ہے: ہر فیچر میں اپنی منطق، UI اور ڈیٹا شامل ہوتا ہے۔ State of Frontend 2024 سروے کے مطابق، 23% React ڈویلپر FSD کو اپنی بنیادی آرکیٹیکچر طریقہ کار کے طور پر استعمال کرتے ہیں، جو اسے خالص Feature-based ساخت کے بعد دوسرا سب سے مقبول بناتا ہے۔
اہم نکات
- Feature-Sliced Design (FSD) — ایک طریقہ کار جو کوڈ کو کاروباری فیچرز (سلائسز) کے مطابق گروپ کرتا ہے، ہر ایک میں UI، منطق، API اور ٹیسٹ شامل ہیں۔
- معیاری FSD ساخت 7 پرتوں پر مشتمل ہے: app, processes, pages, features, entities, shared, widgets — ہر ایک سخت درآمدی قواعد کے ساتھ۔
- FSD کا بنیادی اصول — «پرتیں صرف نیچے کی طرف دیکھتی ہیں»: features پرت entities درآمد کر سکتی ہے، لیکن اس کے برعکس نہیں۔
- FSD کے فوائد: فیچر آئسولیشن، پروجیکٹس کے درمیان سلائسز کا دوبارہ استعمال، بغیر تنازع کے متوازی ترقی۔
- بنیادی خامی — چھوٹے پروجیکٹس کے لیے ضرورت سے زیادہ نیسٹنگ: FSD 10+ ڈویلپرز اور 20+ اسکرینز کے ساتھ جائز ہے۔
Feature-Sliced Design کیا ہے؟
Feature-Sliced Design (FSD) ایک فرنٹ اینڈ ایپلیکیشن آرکیٹیکچر طریقہ کار ہے جو پہلی بار 2021 میں feature-sliced.design کمیونٹی کے ذریعہ تجویز کیا گیا تھا۔ FSD کا بنیادی خیال کوڈ کو کاروباری فیچرز (سلائسز) کے مطابق گروپ کرنا ہے، جن میں سے ہر ایک خود کفیل اکائی ہے: اس میں اپنی کاروباری منطق، صارف انٹرفیس، API تعامل، ڈیٹا ماڈلز اور ٹیسٹ شامل ہیں۔ یہ FSD کو کلاسیکی پرت دار آرکیٹیکچر سے ممتاز کرتا ہے جہاں کوڈ تکنیکی معیار (controller, service, repository) کے مطابق تقسیم ہوتا ہے۔
یہ طریقہ کار Domain-Driven Design (DDD) اور Bounded Context سے تصورات ادھار لیتا ہے: ایپلیکیشن کا ہر فیچر واضح حدود کے ساتھ ایک علیحدہ bounded context ہے۔ ایک فیچر کے اندر تبدیلیاں دوسرے فیچرز کو نہیں توڑنی چاہئیں اگر وہ صرف سلائس کے عوامی API کا استعمال کریں۔ State of Frontend 2024 سروے کے مطابق، FSD React آرکیٹیکچرز میں مقبولیت میں دوسرے نمبر پر ہے (23%)، جو صرف غیر رسمی Feature-based ساخت (31%) کے بعد ہے۔
موبائل ڈویلپمنٹ میں، FSD Android ماڈیولز اور iOS فریم ورکس کی خصوصیات کے مطابق ڈھل جاتا ہے۔ IT Sectr میں، ہم 10+ اسکرینز اور 3+ ٹیموں والے پروجیکٹس کے لیے FSD استعمال کرتے ہیں — یہ طریقہ کار آزادانہ طور پر فیچرز تیار کرنے کی اجازت دیتا ہے اور سلائس حدود کے بغیر مونوریپو کے مقابلے میں git تنازعات کو 40% کم کرتا ہے۔
FSD کی سات پرتیں: ساخت اور درآمدی قواعد
FSD سات درجہ بندی کی پرتیں بیان کرتا ہے، ہر ایک میں تجرید کی ایک مخصوص سطح کا کوڈ ہوتا ہے۔ بنیادی آرکیٹیکچر قاعدہ یہ ہے کہ پرتیں صرف نیچے کی پرتوں سے کوڈ درآمد کر سکتی ہیں۔ اس قاعدہ کی خلاف ورزی (entities میں features پرت درآمد کرنا) ایک آرکیٹیکچر غلطی سمجھی جاتی ہے اور لنٹر کے ذریعہ مسدود کر دی جاتی ہے۔
| پرت | مقصد | درآمد کرتی ہے |
|---|---|---|
| app | ایپلیکیشن ابتداء، فراہم کنندگان، عالمی انداز، روٹنگ | کوئی بھی پرت |
| processes | کاروباری عمل جو متعدد فیچرز کو یکجا کرتے ہیں (آن بورڈنگ، ادائیگی) | pages, features, entities, shared |
| pages | صفحہ پر فیچر کمپوزیشن، صفحات کی روٹنگ | features, entities, shared |
| features | صارف کے منظرنامے: لاگ ان فارم، پسندیدہ فہرست، تلاش فلٹر | entities, shared |
| entities | کاروباری ہستیاں: User, Product, Order, Cart | shared |
| widgets | مرکب UI اجزاء: Header, Sidebar, ArticleCard | shared, entities |
| shared | افادیتیں، UI-kit، API کلائنٹ، ترتیبات — کاروباری منطق سے آزاد | صرف بیرونی لائبریریاں |
FSD پروجیکٹ کی ڈائرکٹری ساخت کی مثال:
متن
src/
├── app/ // ایپلیکیشن پرت
│ ├── providers/
│ ├── router/
│ └── styles/
├── pages/ // صفحات — فیچر کمپوزیشن
│ └── main/
├── features/ // فیچرز — صارف کے منظرنامے
│ ├── auth/ // سلائس «تصدیق»
│ │ ├── ui/
│ │ ├── model/
│ │ └── api/
│ └── productList/ // سلائس «مصنوعات کی فہرست»
│ ├── ui/
│ └── model/
├── entities/ // کاروباری ہستیاں
│ ├── user/
│ └── product/
├── widgets/ // مرکب اجزاء
│ └── header/
└── shared/ // مشترکہ افادیتیں اور UI-kit
└── ui/«پرتیں صرف نیچے کی طرف دیکھتی ہیں» قاعدہ FSD کی بنیاد ہے۔ اگر feature auth entity user درآمد کرتا ہے — یہ درست ہے۔ اگر entity user feature auth درآمد کرنا شروع کر دیتا ہے — یہ ایک چکری انحصار اور آئسولیشن کی خلاف ورزی ہے۔ اس قاعدہ کو یقینی بنانے کے لیے ESLint پلگ انز (eslint-plugin-fsd) یا سلائسز کے عوامی API کے حسب ضرورت لنٹر استعمال کیے جاتے ہیں۔
سلائسز: کاروباری ڈومین کی حدود
سلائس (Slice) — FSD میں گروپ بندی کی بنیادی اکائی، جو ایک کاروباری فیچر یا ہستی کے مساوی ہے۔ ہر سلائس سات پرتوں (features, entities, widgets, pages) میں سے ایک کے اندر واقع ہوتا ہے اور مخصوص فعالیت کو لاگو کرنے کے لیے کوڈ کا مکمل سیٹ رکھتا ہے: UI اجزاء، ڈیٹا ماڈل، API کلائنٹ، مستقلات اور ٹیسٹ۔
سلائس حدود کاروباری ڈومین کے ذریعہ بیان کی جاتی ہیں: feature auth میں اجازت سے متعلق ہر چیز شامل ہے (لاگ ان فارم، رجسٹریشن فارم، پاس ورڈ ری سیٹ)؛ entity user میں User ماڈل، UserRepository اور سیریلائزیشن شامل ہے۔ حدود کو آپس میں نہیں ملنا چاہیے: اگر feature auth کو صارف ڈیٹا درکار ہے — تو یہ منطق کو نقل کرنے کے بجائے entity user درآمد کرتا ہے۔ موبائل ڈویلپمنٹ میں، FSD سلائس اکثر Android میں Gradle ماڈیول یا iOS میں Swift پیکیج کے مساوی ہوتا ہے۔
سلائسز سختی سے الگ تھلگ ہیں: ایک سلائس کا اندرونی ڈھانچہ دوسرے سلائسز کے لیے پوشیدہ ہے۔ سلائسز کے درمیان تعامل کے لیے ایک عوامی API استعمال کیا جاتا ہے — ایک index.ts/index.js فائل جو صرف وہی برآمد کرتی ہے جو بیرونی استعمال کے لیے اجازت شدہ ہے۔ باقی سب کچھ نجی ماڈیولز ہیں۔ یہ نقطہ نظر اتفاقی انحصار کو روکتا ہے اور ریفیکٹرنگ کو آسان بناتا ہے: ایک سلائس کی نجی تعمیل کو تبدیل کرنے سے دوسرے سلائسز متاثر نہیں ہوتے۔
سیگمنٹس: سلائس کے اندر UI, API, Model, Lib
ہر FSD سلائس کے اندر، کوڈ مزید سیگمنٹس — تکنیکی زمرے جو تمام سلائسز میں دہرائے جاتے ہیں — کے ذریعہ منظم کیا جاتا ہے۔ سیگمنٹس کے معیاری سیٹ میں ui (انٹرفیس اجزاء)، model (کاروباری منطق، Store, Actions, Reducer)، api (سرور کی درخواستیں، تغیرات)، lib (افادیتیں اور مددگار) اور config (فیچر ترتیب) شامل ہیں۔
| سیگمنٹ | مواد | مثال |
|---|---|---|
| ui/ | React/Vue/SwiftUI اجزاء، انداز، Storybook | LoginForm.tsx, login.module.css |
| model/ | Store, Reducer, Actions, اقسام، معاہدے | LoginStore.ts, authReducer.ts |
| api/ | HTTP کلائنٹس، تغیرات، RPC کالز | authApi.ts, loginMutation.ts |
| lib/ | معاون افعال، توثیق کنندہ | validateEmail.ts, formatPhone.ts |
| config/ | مستقلات، فیچر ترتیب | authConfig.ts, endpoints.ts |
سیگمنٹس ایک سفارش ہیں، سخت قاعدہ نہیں۔ اگر سلائس چھوٹا ہے، تو سیگمنٹس کو ضم کیا جا سکتا ہے۔ بڑے سلائسز (10+ فائلوں والا فیچر) کے لیے، سیگمنٹیشن لازمی ہے — اس کے بغیر اندرونی ڈھانچہ جلدی سے 50 فائلوں کی «ٹوکری» بن جاتا ہے جہاں مطلوبہ جزو تلاش کرنے میں منٹ لگتے ہیں۔ موبائل ڈویلپمنٹ میں، سیگمنٹس کو اکثر قسم کے مطابق فائل ڈھانچے سے بدل دیا جاتا ہے: ہر فیچر اندرونی اقسام کے ساتھ ایک علیحدہ Swift فائل یا Kotlin کلاس ہے۔
موبائل ڈویلپمنٹ میں FSD: Android اور iOS کے لیے موافقت
موبائل ڈویلپمنٹ میں، FSD پلیٹ فارم کی خصوصیات کے مطابق ڈھل جاتا ہے — Android کی ماڈیولر ساخت (Gradle ماڈیولز) اور Swift Package Manager۔ Android موافقت فرض کرتی ہے کہ ہر سلائس اپنی build.gradle کے ساتھ ایک علیحدہ Gradle ماڈیول ہے۔ ماڈیولز feature-auth, feature-profile, entity-user, shared-ui بلڈ لیول پر ایک دوسرے سے الگ تھلگ ہیں: feature-auth feature-profile کو درآمد نہیں کر سکتا جب تک کہ dependencies میں مخصوص نہ کیا گیا ہو۔
iOS موافقت Swift Package Manager پر بنائی گئی ہے: ہر سلائس عوامی API کے ساتھ ایک Swift پیکیج ہے۔ TCA پروجیکٹس میں، feature.auth سلائس میں اپنا Reducer, Store, View اور API کلائنٹ شامل ہے۔ Swift Community Survey 2024 کے مطابق، TCA والے 28% iOS پروجیکٹ FSD کے قریب سلائس آرکیٹیکچر استعمال کرتے ہیں۔
موبائل FSD موافقت کا بنیادی مسئلہ shared پرت کا نقل ہے۔ موبائل ڈویلپمنٹ میں، UI اجزاء (shared/ui) اکثر پلیٹ فارم پر منحصر ہوتے ہیں (Android Views بمقابلہ Jetpack Compose بمقابلہ SwiftUI)، جس کے لیے ہر ٹیکنالوجی کے لیے علیحدہ shared ماڈیولز کی ضرورت ہوتی ہے۔ FSD میں، shared پرت عام طور پر پلیٹ فارم سے آزاد ہوتی ہے (افادیتیں، ترتیبات)، جبکہ UI-kit کو علیحدہ ماڈیول یا اجزاء کی لائبریری میں منتقل کیا جاتا ہے۔
Feature-Sliced Design کے فوائد اور نقصانات
فوائد FSD کے 10+ ڈویلپرز والے بڑے پروجیکٹس میں نمایاں ہو جاتے ہیں۔ ہر ڈویلپر یا ٹیم دوسروں کے کوڈ کو چھوئے بغیر اپنے سلائس پر کام کرتی ہے۔ git میں تنازعات 40–60% کم ہو جاتے ہیں (feature-sliced.design کیس اسٹڈیز سے ڈیٹا)۔ نئے فیچرز موجودہ فیچرز کو توڑنے کے خطرے کے بغیر شامل کیے جاتے ہیں، بشرطیکہ وہ صرف سلائسز کے عوامی API کا استعمال کریں۔ ایک فیچر کی ریفیکٹرنگ کے لیے دوسروں میں تبدیلی کی ضرورت نہیں ہوتی — عوامی API کو برقرار رکھتے ہوئے ایک سلائس کے اندر ui/model/api کو دوبارہ لکھنا کافی ہے۔
| پہلو | FSD | Feature-based (FSD کے بغیر) | پرت دار آرکیٹیکچر |
|---|---|---|---|
| فیچر آئسولیشن | سخت | درمیانی | کم |
| متوازی ترقی | 10+ ٹیمیں | 3–5 ٹیمیں | 1–2 ٹیمیں |
| پروجیکٹس کے درمیان دوبارہ استعمال | ہاں (سلائس پیکیجز) | صرف کاپی پیسٹ کے ذریعے | shared ماڈیولز کے ذریعے |
| داخلی رکاوٹ | بلند | پست | درمیانی |
| Gradle آئسولیشن (Android) | اصلی (ماڈیولز) | اصلی (ماڈیولز) | کمزور |
نقصانات FSD کے — چھوٹے پروجیکٹس کے لیے ضرورت سے زیادہ نیسٹنگ۔ اگر کوئی ایپلیکیشن 3–5 اسکرینز پر مشتمل ہے، تو سات پرتیں اور ہر سلائس کے اندر سیگمنٹیشن خود ایپلیکیشن سے زیادہ تنظیمی کوڈ تخلیق کرتی ہے۔ داخلی رکاوٹ بلند ہے: نئے ڈویلپر طریقہ کار سیکھنے میں 2–4 ہفتے صرف کرتے ہیں۔ نیز، FSD تیز رفتار پروٹوٹائپنگ کے ساتھ ناقص مطابقت رکھتا ہے — پروٹوٹائپنگ کے لیے بار بار کراس لیئر درآمدات کی ضرورت ہوتی ہے، جو FSD میں ممنوع ہیں اور تکرار کو سست کرتی ہیں۔
سفارش کی جاتی ہے کہ آسان Feature-based ساخت سے شروع کریں اور FSD پر منتقل ہوں جب اسکرینوں کی تعداد 20 سے تجاوز کر جائے اور ٹیم 5 ڈویلپرز سے بڑی ہو جائے۔
اکثر پوچھے گئے سوالات
FSD اور Feature-based آرکیٹیکچر میں کیا فرق ہے؟
Feature-based آرکیٹیکچر کوڈ کو سخت درآمدی قواعد کے بغیر فیچرز کے مطابق گروپ کرتا ہے — feature Auth بغیر کسی پابندی کے کسی دوسرے feature Profile کو درآمد کر سکتا ہے۔ FSD ایک پرت کا درجہ بندی اور «پرتیں صرف نیچے کی طرف دیکھتی ہیں» قاعدہ شامل کرتا ہے۔ Feature-based میں، entity اور feature ایک ہی سطح پر ہو سکتے ہیں اور ایک دوسرے کو درآمد کر سکتے ہیں؛ FSD میں، entity feature کے نیچے ہے، اور feature entity درآمد کرتا ہے، اس کے برعکس نہیں۔ Feature-based چھوٹے پروجیکٹس کے لیے موزوں ہے، FSD بڑے پروجیکٹس کے لیے۔
الگ تھلگ سلائس کی جانچ کیسے کریں؟
سلائس آئسولیشن یونٹ ٹیسٹنگ کو آسان بناتا ہے — ہر سلائس نیچے کی پرتوں کے انحصار کو نقلی بنا کر آزادانہ طور پر جانچا جاتا ہے۔ feature auth کے لیے، entity user کو نقلی بنانا کافی ہے۔ انٹیگریشن ٹیسٹ سلائس کے عوامی API کی تصدیق کرتے ہیں۔ Android میں، ایک فیچر کے Gradle ماڈیول میں Reducer, API کلائنٹ اور UI (Compose Test کے ذریعے) کے ٹیسٹ کے ساتھ اپنی ٹیسٹ ڈائرکٹری ہوتی ہے۔ iOS میں، سلائس پیکیج میں تمام سیگمنٹس کے ٹیسٹ شامل ہوتے ہیں۔
کیا FSD کو Jetpack Compose کے ساتھ استعمال کیا جا سکتا ہے؟
ہاں، FSD Jetpack Compose کے ساتھ اچھی طرح کام کرتا ہے، خاص طور پر ملٹی ماڈیول Android پروجیکٹس میں۔ ہر سلائس exported ہدایت کے ذریعے عوامی API کے ساتھ ایک علیحدہ Gradle ماڈیول ہے۔ features پرت میں Composable فیچرز (LoginFeature, ProductListFeature) شامل ہیں، entities پرت میں ڈیٹا کلاسز اور Repository شامل ہیں، اور shared میں UI-kit (MaterialTheme-wrapper, حسب ضرورت اجزاء) شامل ہے۔ FSD کو 5+ ڈویلپرز والے بڑے Compose پروجیکٹس کے لیے سفارش کی جاتی ہے۔
کون سی پرتیں لازمی ہیں اور کون سی اختیاری؟
لازمی پرتیں app, shared, entities اور features ہیں۔ باقی (processes, pages, widgets) اختیاری ہیں اور ضرورت کے مطابق شامل کی جاتی ہیں۔ موبائل ڈویلپمنٹ میں، pages پرت کو اکثر نیویگیشن روٹنگ کے ساتھ ضم کیا جاتا ہے، اور widgets کو shared/ui-kit سے بدل دیا جاتا ہے۔ عمل (processes) عام طور پر موبائل پروجیکٹس میں استعمال نہیں ہوتے — ان کا کردار ڈومین پرت یا ViewModel میں کاروباری منطق پورا کرتی ہے۔ اہم بات درآمدی درجہ بندی کے قاعدہ پر عمل کرنا ہے۔
FSD کا Domain-Driven Design سے کیا تعلق ہے؟
FSD DDD سے Bounded Context اور Ubiquitous Language کے تصورات ادھار لیتا ہے۔ ہر سلائس ایک bounded context سے مساوی ہے — ایک حد جس کے اندر اصطلاحات کا غیر مبہم معنی ہوتا ہے۔ سلائس کے اندر، ایک متحد زبان (ubiquitous language) استعمال کی جاتی ہے، جو ڈویلپرز اور کاروباری تجزیہ کاروں دونوں کے لیے قابل فہم ہے۔ مثال کے طور پر، auth سلائس میں، اصطلاحات «لاگ ان»، «پاس ورڈ»، «ٹوکن» کا ٹیم کے تمام اراکین کے لیے ایک ہی معنی ہے، جو تجزیہ کاروں اور ڈویلپرز کے درمیان غلط فہمیوں کو 30–50% کم کرتا ہے۔
خلاصہ
- Feature-Sliced Design (FSD) — ایک ماڈیولر آرکیٹیکچر طریقہ کار جو کوڈ کو کاروباری فیچرز (سلائسز) کے مطابق گروپ کرتا ہے، ہر ایک میں UI، منطق، API اور ٹیسٹ شامل ہیں۔
- FSD کی سات پرتیں: app, processes, pages, features, entities, widgets, shared — اوپر سے نیچے سخت درآمدی قاعدہ کے ساتھ۔
- سلائسز عوامی API کے ذریعے الگ تھلگ ہیں — اندرونی ڈھانچہ دوسرے سلائسز کے لیے پوشیدہ ہے، چکری انحصار کو روکتا ہے۔
- سلائس کے اندر سیگمنٹس (ui, model, api, lib, config) کوڈ کو تکنیکی معیار کے مطابق منظم کرتے ہیں، لیکن چھوٹے سلائسز کے لیے لازمی نہیں۔
- موبائل ڈویلپمنٹ میں، FSD Gradle ماڈیولز (Android) اور Swift پیکیجز (iOS) کے ذریعے ڈھل جاتا ہے، بلڈ لیول پر آئسولیشن کو یقینی بناتا ہے۔
- بنیادی فوائد — متوازی ترقی، فیچر آئسولیشن، پروجیکٹس کے درمیان دوبارہ استعمال۔
- بنیادی نقصانات — چھوٹے پروجیکٹس کے لیے فالتو پن، بلند داخلی رکاوٹ، تیز رفتار پروٹوٹائپنگ کے ساتھ غیر مطابقت۔
ہم ایک موبائل ایپلیکیشن ٹرنکی تیار کریں گے
IT Sectr 2017 سے اسٹارٹ اپس اور کاروبار کے لیے iOS اور Android ایپلیکیشنز بناتا ہے۔ ہم آپ کو مشورہ دیں گے اور بہترین حل تجویز کریں گے۔
مزید پڑھیں