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 को तब तक आयात नहीं कर सकता जब तक कि निर्भरताओं में निर्दिष्ट न किया गया हो।
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 में, एक स्लाइस पैकेज में सभी सेगमेंट के परीक्षण शामिल होते हैं।
क्या Jetpack Compose के साथ FSD का उपयोग किया जा सकता है?
हाँ, 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 एप्लिकेशन बनाता है। हम आपको सलाह देंगे और सर्वोत्तम समाधान प्रस्तावित करेंगे।
यह भी पढ़ें