फ्रंटएंड डेवलपर्स को अक्सर एप्लिकेशन आर्किटेक्चर से संबंधित समस्या का सामना करना पड़ता है। इसके लिए एक ऐसे आर्किटेक्चर के उपयोग की आवश्यकता होती है जो आसानी से स्केल कर सके और एप्लिकेशन मॉड्यूल के बीच ढीली युग्मन और उच्च सामंजस्य प्रदान कर सके।
यह आलेख फ़ीचर-स्लाइस्ड डिज़ाइन आर्किटेक्चर पर चर्चा करता है, क्योंकि, मेरी राय में, यह उपलब्ध विकल्पों में से सबसे अच्छा है। यह एफएसडी के विचार और इस वास्तुशिल्प पद्धति द्वारा हल की जाने वाली समस्याओं का भी पता लगाता है।
हम एफएसडी की तुलना शास्त्रीय और मॉड्यूलर आर्किटेक्चर से करेंगे और उनके पेशेवरों और विपक्षों की जांच करेंगे।
सबसे पहले और सबसे महत्वपूर्ण, आइए तीन अवधारणाओं को अलग करें: परत, टुकड़ा और खंड।
परतें शीर्ष-स्तरीय निर्देशिकाएं हैं और अनुप्रयोग अपघटन का पहला स्तर हैं। वे संख्या में सीमित हैं - अधिकतम 7 परतें - और मानकीकृत हैं, हालांकि उनमें से कुछ वैकल्पिक हैं।
वर्तमान में, निम्नलिखित परतें प्रतिष्ठित हैं:
प्रत्येक परत का अपना उत्तरदायित्व क्षेत्र होता है और यह व्यवसाय-उन्मुख होता है। आइए प्रत्येक परत पर अलग से विचार करें।
ये परतें कोडबेस को व्यवस्थित करने और मॉड्यूलर, रखरखाव योग्य और स्केलेबल आर्किटेक्चर को बढ़ावा देने में मदद करती हैं।
फ़ीचर-स्लाइस्ड डिज़ाइन की प्रमुख विशेषताओं में से एक इसकी पदानुक्रमित संरचना है। इस संरचना में, संस्थाएँ सुविधाओं से कार्यक्षमता का उपयोग नहीं कर सकती हैं क्योंकि सुविधाएँ पदानुक्रम में उच्चतर हैं।
इसी तरह, सुविधाएँ विजेट या प्रक्रियाओं से घटकों का उपयोग नहीं कर सकती हैं, क्योंकि ऊपर की परतें केवल नीचे की परतों का उपयोग कर सकती हैं। यह एक रैखिक प्रवाह को बनाए रखने के लिए किया जाता है जो केवल एक दिशा में निर्देशित होता है। पदानुक्रम में एक परत जितनी नीचे स्थित होगी, उसमें परिवर्तन करना उतना ही जोखिम भरा होगा क्योंकि कोड में इसका उपयोग अधिक स्थानों पर होने की संभावना है। उदाहरण के लिए, साझा परत में यूआई किट का उपयोग सुविधाओं, विजेट्स और यहां तक कि पेज परतों में भी किया जाता है।
प्रत्येक परत में, उपनिर्देशिकाएँ होती हैं - स्लाइस - अनुप्रयोग अपघटन का दूसरा स्तर। स्लाइस में, कनेक्शन अमूर्त चीज़ों से नहीं बल्कि विशिष्ट व्यावसायिक संस्थाओं से है। स्लाइस का मुख्य लक्ष्य कोड को उसके मूल्य के आधार पर समूहित करना है।
स्लाइस नाम मानकीकृत नहीं हैं, क्योंकि वे सीधे परियोजना के व्यावसायिक क्षेत्र द्वारा निर्धारित होते हैं। उदाहरण के लिए, एक फोटो गैलरी में फोटो, एल्बम और गैलरी जैसे अनुभाग हो सकते हैं। एक सोशल नेटवर्क को पोस्ट, उपयोगकर्ता और न्यूज़फ़ीड जैसे स्लाइस की आवश्यकता होगी।
निकट से संबंधित टुकड़ों को एक निर्देशिका में संरचनात्मक रूप से समूहीकृत किया जा सकता है, लेकिन उन्हें अन्य स्लाइस के समान अलगाव नियमों का पालन करना होगा - इस निर्देशिका में कोड तक कोई साझा पहुंच नहीं होनी चाहिए।
प्रत्येक स्लाइस में खंड होते हैं। सेगमेंट कोड को उसके उद्देश्य के आधार पर एक स्लाइस में विभाजित करने में मदद करते हैं। टीम के समझौतों के आधार पर, खंड संरचना और नामकरण में बदल सकते हैं। निम्नलिखित खंड अधिक सामान्यतः उपयोग किए जाते हैं:
प्रत्येक स्लाइस और सेगमेंट में एक सार्वजनिक एपीआई है। सार्वजनिक एपीआई को एक इंडेक्स.जेएस या इंडेक्स.टीएस फ़ाइल द्वारा दर्शाया जाता है, जो स्लाइस या सेगमेंट से केवल आवश्यक कार्यक्षमता को बाहर निकालने और अनावश्यक कार्यक्षमता को अलग करने की अनुमति देता है। इंडेक्स फ़ाइल एक प्रवेश बिंदु के रूप में कार्य करती है।
सार्वजनिक एपीआई के लिए नियम:
सार्वजनिक एपीआई आयात और निर्यात के साथ काम करना सरल बनाता है, इसलिए एप्लिकेशन में परिवर्तन करते समय, कोड में हर जगह आयात को बदलने की आवश्यकता नहीं होती है।
परत जितनी ऊंची होगी, वह उतना ही अधिक विशिष्ट व्यावसायिक नोड से बंधी होगी और उसमें उतने ही अधिक व्यावसायिक तर्क होंगे। परत जितनी निचली होगी, परत में उतनी ही अधिक अमूर्तता, पुन: प्रयोज्यता और स्वायत्तता की कमी होगी।
फ़ीचर-स्लाइस्ड डिज़ाइन के कार्यों में से एक ढीला युग्मन और उच्च सामंजस्य प्राप्त करना है। यह समझना महत्वपूर्ण है कि एफएसडी इस परिणाम को कैसे प्राप्त करता है।
OOP में, इन समस्याओं को बहुरूपता , एनकैप्सुलेशन , वंशानुक्रम और अमूर्तता जैसी अवधारणाओं के माध्यम से लंबे समय से हल किया गया है। ये अवधारणाएं कोड के अलगाव, पुन: प्रयोज्यता और बहुमुखी प्रतिभा को सुनिश्चित करती हैं, जहां किसी घटक या कार्यक्षमता का उपयोग कैसे किया जाता है इसके आधार पर विभिन्न परिणाम प्राप्त होते हैं।
फ़ीचर-स्लाइस्ड डिज़ाइन इन सिद्धांतों को फ्रंटएंड में लागू करने में मदद करता है।
अमूर्तता और बहुरूपता परतों के माध्यम से प्राप्त की जाती है। चूँकि निचली परतें अमूर्त होती हैं, इसलिए उन्हें उच्च परतों में पुन: उपयोग किया जा सकता है, और स्थितियों के आधार पर, एक घटक या कार्यक्षमता निर्दिष्ट मापदंडों या प्रॉप्स के आधार पर अलग-अलग तरीके से काम कर सकती है।
इनकैप्सुलेशन को सार्वजनिक एपीआई के माध्यम से प्राप्त किया जाता है, जो स्लाइस और सेगमेंट में बाहर से आवश्यक चीज़ों को अलग करता है। किसी स्लाइस के आंतरिक खंडों तक पहुंच प्रतिबंधित है, और सार्वजनिक एपीआई किसी स्लाइस या सेगमेंट से कार्यक्षमता और घटकों तक पहुंचने का एकमात्र तरीका है।
विरासत भी परतों के माध्यम से प्राप्त की जाती है, क्योंकि उच्च परतें निचली परतों का पुन: उपयोग कर सकती हैं।
मेरा मानना है कि आपने कई बार क्लासिक वास्तुकला देखी होगी। इसकी सरलता के कारण अधिकांश लेखक शैक्षिक लेखों और यूट्यूब वीडियो में इसका उपयोग करते हैं। शास्त्रीय वास्तुकला के लिए कोई विशिष्ट मानक नहीं है। हालाँकि, अक्सर आप निम्न प्रारूप देख सकते हैं:
क्लासिक वास्तुकला में उल्लेखनीय कमियाँ हैं। सबसे बड़ी बात यह है कि घटकों और मॉड्यूल अव्यवस्था के बीच अंतर्निहित कनेक्शन के कारण परियोजना को बनाए रखना मुश्किल हो जाता है। क्लासिक वास्तुकला की कमियाँ समय के साथ और अधिक स्पष्ट हो जाती हैं। प्रोजेक्ट जितना लंबा विकसित होता है, एप्लिकेशन आर्किटेक्चर उतना ही उलझ जाता है जिसे सुलझाना मुश्किल होता है।
क्लासिक वास्तुकला चल रहे रखरखाव या पालतू परियोजनाओं के बिना छोटी परियोजनाओं के लिए उपयुक्त है।
फ़ीचर-स्लाइस्ड डिज़ाइन, इसकी अवधारणाओं और मानकों के लिए धन्यवाद, क्लासिक वास्तुकला की समस्याओं को रोकता है।
हालाँकि, FSD के साथ काम करने वाले डेवलपर्स की समझ और कौशल का स्तर क्लासिक आर्किटेक्चर के साथ काम करने की तुलना में अधिक होना चाहिए। आमतौर पर, 2 साल से कम अनुभव वाले डेवलपर्स ने एफएसडी के बारे में नहीं सुना है।
हालाँकि, फ़ीचर-स्लाइस्ड डिज़ाइन के साथ काम करते समय, समस्याओं को "बाद में" के बजाय "अभी" संबोधित करने की आवश्यकता होती है। कोड में मुद्दे और अवधारणाओं से विचलन तुरंत स्पष्ट हो जाते हैं
सरल मॉड्यूलर वास्तुकला में कई कमियां हैं:
ऐसा लगता है कि किसी भी जटिल या मध्यम जटिल परियोजनाओं में, साधारण मॉड्यूलर आर्किटेक्चर की तुलना में फ़ीचर-स्लाइस्ड डिज़ाइन को प्राथमिकता दी जानी चाहिए। एफएसडी कई बुनियादी वास्तुशिल्प समस्याओं का समाधान करता है और इसमें कुछ कमियां भी हैं।
सादगी और विकास की गति के मामले में, एक साधारण मॉड्यूलर वास्तुकला का एफएसडी पर लाभ हो सकता है। यदि एमवीपी की आवश्यकता है या एक अल्पकालिक परियोजना विकसित की जा रही है, तो एक साधारण मॉड्यूलर आर्किटेक्चर एफएसडी की तुलना में अधिक उपयुक्त हो सकता है। लेकिन किसी भी अन्य मामले में, फीचर-स्लाइस डिज़ाइन बेहतर दिखता है।
एफएसडी एक युवा वास्तुशिल्प पद्धति है। हालाँकि, इसका उपयोग पहले से ही कई बैंकिंग, फिनटेक, बी2बी, ई-कॉमर्स कंपनियों और अन्य द्वारा किया जा रहा है। यहां कंपनियों की सूची के साथ GitHub मुद्दे का एक लिंक दिया गया है: GitHub जारी ।
इस लेख को प्रकाशित करने के समय आधिकारिक FSD दस्तावेज़ के साथ GitHub रिपॉजिटरी में 1.1k से अधिक सितारे थे। दस्तावेज़ीकरण का सक्रिय रूप से विस्तार किया जा रहा है, और टेलीग्राम और डिस्कॉर्ड में एफएसडी विकास टीम और समुदाय वास्तुकला से संबंधित प्रश्नों वाले लोगों की सहायता के लिए 24/7 उपलब्ध हैं।
इस वास्तुकला की क्षमता को अत्यधिक महत्व दिया जाता है, और इसका उपयोग दुनिया भर में बड़ी कंपनियों के बीच व्यापक रूप से फैला हुआ है। उचित रूप से अपनाने के साथ, एफएसडी में फ्रंटएंड विकास के क्षेत्र में प्रमुख वास्तुशिल्प समाधान बनने की क्षमता है।
फ़ीचर-स्लाइस्ड डिज़ाइन एक दिलचस्प और मूल्यवान खोज है जिसे फ्रंटएंड डेवलपर्स को जानना चाहिए और उपयोग करने में सक्षम होना चाहिए। एफएसडी टीमों को एक लचीली, मानकीकृत और स्केलेबल वास्तुकला और विकास संस्कृति प्रदान कर सकता है। हालाँकि, कार्यप्रणाली के सकारात्मक पहलुओं का उपयोग करने के लिए टीम के भीतर ज्ञान, जागरूकता और अनुशासन की आवश्यकता होती है।
एफएसडी अपने स्पष्ट व्यावसायिक अभिविन्यास, इकाई परिभाषा, कार्यात्मक संरचना और एप्लिकेशन के घटकों की संरचना के कारण अन्य आर्किटेक्चर के बीच में खड़ा है।
आप स्वतंत्र रूप से परियोजनाओं में एफएसडी उपयोग के उदाहरण और आधिकारिक फ़ीचर-स्लाइस्ड डिज़ाइन दस्तावेज़ीकरण का भी पता लगा सकते हैं:
उदाहरण। नाइके स्नीकर और जूते की दुकान
यह पोस्ट लंबी हो सकती है, लेकिन मुझे आशा है कि आपने कुछ नया सीखा होगा। मैं सराहना करता हूं कि आपने यह पोस्ट पढ़ ली है।
यदि आपके कोई विचार या प्रश्न हैं, तो बेझिझक एक टिप्पणी छोड़ें!
यहाँ भी प्रकाशित किया गया