C4 मॉडल के साथ आर्किटेक्चर भ्रम को हल करना

सॉफ्टवेयर प्रणालियाँ जटिलता में बढ़ती हैं। जो एक सरल मोनोलिथ के रूप में शुरू होता है, वह अक्सर सेवाओं, डेटाबेस और इंटरफेस के वितरित नेटवर्क में बदल जाता है। इस वृद्धि के साथ एक महत्वपूर्ण चुनौती आती है: संचार। आर्किटेक्ट्स, डेवलपर्स और स्टेकहोल्डर्स अक्सर एक ही प्रणाली को समझने में कठिनाई महसूस करते हैं क्योंकि वे उसे अलग-अलग लेंसों से देख रहे होते हैं। कुछ उच्च स्तरीय व्यापार प्रवाह देखते हैं, जबकि अन्य विशिष्ट डेटाबेस स्कीमा पर ध्यान केंद्रित करते हैं। इस अंतर के कारण आर्किटेक्चर भ्रम उत्पन्न होता है, जिसके परिणामस्वरूप कार्यान्वयन त्रुटियाँ, तकनीकी देनदारी और विकास चक्र में धीमापन आता है।

C4 मॉडल सॉफ्टवेयर आर्किटेक्चर दस्तावेजीकरण के लिए एक संरचित दृष्टिकोण प्रदान करता है। यह एक विशिष्ट उपकरण या सॉफ्टवेयर का हिस्सा नहीं है, बल्कि एक अवधारणात्मक ढांचा है। यह टीमों को ऐसे आरेख बनाने में मदद करता है जो विभिन्न स्तरों के सामान्यीकरण पर स्पष्ट, संगत और उपयोगी हों। इस मॉडल को अपनाने से संगठन अस्पष्टता को कम कर सकते हैं और यह सुनिश्चित कर सकते हैं कि सभी लोग प्रणाली के काम करने के तरीके के बारे में एक सामान्य समझ रखते हैं। यह मार्गदर्शिका जटिल प्रणालियों को स्पष्ट करने के लिए C4 मॉडल के प्रभावी अनुप्रयोग के बारे में अध्ययन करती है।

🧩 सामान्यीकरण का मूल सिद्धांत

आर्किटेक्चर में भ्रम के प्राथमिक कारणों में से एक उपयुक्त सामान्यीकरण की कमी है। जब एक आरेख में प्रत्येक क्लास और मेथड दिखाया जाता है, तो यह विकास टीम के बाहर के किसी भी व्यक्ति के लिए पढ़ने योग्य नहीं बन जाता है। दूसरी ओर, एक आरेख जो केवल बॉक्स और तीर दिखाता है और संदर्भ नहीं देता, वास्तविक डेटा प्रवाह या जिम्मेदारियों को समझाने में विफल रहता है। C4 मॉडल इस समस्या को चार अलग-अलग विवरण स्तरों को परिभाषित करके हल करता है।

प्रत्येक स्तर एक विशिष्ट दर्शक जनसंख्या के लिए होता है और एक विशिष्ट प्रश्नों के सेट का उत्तर देता है। मॉडल टीमों को उच्च स्तर से शुरू करने और केवल आवश्यकता पड़ने पर नीचे तक जाने के लिए प्रोत्साहित करता है। इससे यह सुनिश्चित होता है कि दस्तावेजीकरण संबंधित रहता है और कोड में परिवर्तन होने पर पुराना नहीं हो जाता है। मूल सिद्धांत यह विचार पर आधारित है कि विभिन्न स्टेकहोल्डर्स को अलग-अलग दृष्टिकोण की आवश्यकता होती है।

• एक्जीक्यूटिव्स को व्यापार मूल्य और उच्च स्तरीय बातचीत के बारे में जानने की आवश्यकता होती है।
• डेवलपर्स को घटकों के लिए विशेषताएं बनाने के लिए कैसे बातचीत करते हैं, इसकी समझ होनी चाहिए।
• DevOps � ingineers को डेप्लॉयमेंट और इंफ्रास्ट्रक्चर के बारे में जानने की आवश्यकता होती है।

इन चिंताओं को अलग करके, C4 मॉडल उस ‘एक आकार सभी के लिए फिट’ समस्या से बचाता है जो बहुत सी दस्तावेजीकरण प्रयासों को प्रभावित करती है।

🌍 स्तर 1: सिस्टम संदर्भ

सिस्टम संदर्भ आरेख एक सॉफ्टवेयर प्रणाली को समझने का आरंभ बिंदु है। यह संभव के सबसे व्यापक दृश्य को प्रदान करता है। यह आरेख प्रश्न का उत्तर देता है: ‘प्रणाली क्या है, और इससे कौन बातचीत करता है?’ यह आपकी प्रणाली और बाहरी दुनिया के बीच की सीमा को परिभाषित करता है।

इस स्तर पर, प्रणाली को एक एकल बॉक्स के रूप में दर्शाया जाता है। इस बॉक्स में सॉफ्टवेयर उत्पाद या सेवा का नाम होता है। इस बॉक्स के चारों ओर वे लोग और प्रणालियाँ होती हैं जो इससे बातचीत करती हैं। इन बाहरी एकाधिकारों को ‘लोग’ या ‘सॉफ्टवेयर प्रणालियाँ’ के रूप में जाना जाता है। उन्हें जोड़ने वाली रेखाएँ डेटा प्रवाह या संचार मार्गों का प्रतिनिधित्व करती हैं।

स्तर 1 के मुख्य तत्व

• सिस्टम बॉक्स: आपके सॉफ्टवेयर की सीमा का प्रतिनिधित्व करता है। इसमें आंतरिक विवरण नहीं दिखाए जाते हैं।
• लोग: उपयोगकर्ता, प्रशासक या प्रणाली से बातचीत करने वाले बाहरी भूमिकाएँ।
• सॉफ्टवेयर प्रणालियाँ: तृतीय पक्ष के API, अन्य आंतरिक सेवाएँ या सीमा के बाहर स्थित डेटाबेस।
• संबंध: डेटा प्रवाह की दिशा को दर्शाने वाले तीर।

उदाहरण के लिए, एक रिटेल एप्लिकेशन में, सिस्टम संदर्भ में ‘ऑनलाइन स्टोर’ बॉक्स को ‘ग्राहकों’, ‘पेमेंट गेटवे’ और ‘इन्वेंटरी सिस्टम’ से जोड़ा जाएगा। यह दृष्टिकोण नए टीम सदस्यों के एकीकरण के लिए महत्वपूर्ण है। यह यह निर्धारित करके सब कुछ के लिए आधार तैयार करता है कि क्या अंदर है और क्या बाहर है।

जब सिस्टम संदर्भ आरेख बनाते समय, आंतरिक घटकों की सूची बनाने से बचें। सीमा पर ही ध्यान केंद्रित रखें। यदि इस स्तर पर आरेख भारी हो जाता है, तो आमतौर पर इसका मतलब है कि सिस्टम सीमा बहुत बड़ी या बहुत छोटी है। स्कोप को समायोजित करना आर्किटेक्चरल डिजाइन में एक महत्वपूर्ण कौशल है।

📦 स्तर 2: कंटेनर

जब सीमा निर्धारित कर ली जाती है, तो अगला चरण प्रणाली बॉक्स के अंदर देखना है। कंटेनर स्तर सॉफ्टवेयर के निर्माण के लिए उच्च स्तरीय निर्माण तत्वों को उजागर करता है। एक कंटेनर सॉफ्टवेयर की डिप्लॉय करने योग्य इकाई है। यह एक भौतिक या तार्किक संरचना है जो कोड और डेटा को रखती है।

कंटेनर के सामान्य उदाहरणों में वेब एप्लिकेशन, मोबाइल एप्लिकेशन, माइक्रोसर्विसेज और डेटाबेस शामिल हैं। यह स्तर अक्सर डेवलपर्स के लिए सबसे उपयोगी होता है। यह उन्हें यह समझने में मदद करता है कि कोड कहाँ लिखना है और पहेली के टुकड़े एक-दूसरे से कैसे फिट होते हैं।

कंटेनर को परिभाषित करना

• वेब एप्लिकेशन: एक सर्वर-साइड एप्लिकेशन जो एक वेब सर्वर पर चल रही है।
• मोबाइल एप्लिकेशन: एक नेटिव या हाइब्रिड एप्लिकेशन जो एक उपकरण पर स्थापित है।
• माइक्रोसर्विस: एक छोटी, स्वतंत्र सेवा जो एक प्रक्रिया में चल रही है।
• डेटाबेस: स्थायी डेटा के लिए एक भंडारण प्रणाली।
• फ़ाइल स्टोरेज: चित्रों या दस्तावेजों जैसे स्थिर संपत्तियों के लिए एक भंडारण स्थल।

कंटेनरों के बीच के संबंध महत्वपूर्ण हैं। वे दिखाते हैं कि डेटा प्रणाली के एक भाग से दूसरे भाग में कैसे आता है। उदाहरण के लिए, एक मोबाइल एप्लिकेशन एक वेब एप्लिकेशन से संचार कर सकता है, जो बाद में एक डेटाबेस को प्रश्न करता है। इन प्रवाहों को समझना प्रदर्शन समस्याओं और सुरक्षा के खतरों के निराकरण के लिए आवश्यक है।

स्तर 2 को दृश्याकृत करना

इस स्तर को बनाते समय, कार्यान्वयन विवरणों में फंसे बिना तकनीकी स्टैक पर ध्यान केंद्रित करें। एक कंटेनर बॉक्स को उपयोग की गई तकनीक के साथ लेबल किया जाना चाहिए, जैसे कि “रिएक्ट एप्लिकेशन” या “पोस्टग्रेसक्वल”। इससे टीम को तुरंत संदर्भ मिलता है बिना कोड कमेंट्स पढ़ने के लिए मजबूर होने के बिना।

एक कंटेनर और एक कंपोनेंट के बीच अंतर करना महत्वपूर्ण है। एक कंटेनर एक डिप्लॉयमेंट इकाई है, जबकि एक कंपोनेंट उस कंटेनर के भीतर एक तार्किक इकाई है। इन दोनों को गलती से मिलाने से ऐसे आरेख बनते हैं जो उच्च स्तर के दृष्टिकोण के लिए बहुत विस्तृत होते हैं।

🧩 स्तर 3: कंपोनेंट्स

एक कंटेनर के भीतर आमतौर पर कई चल रहे हिस्से होते हैं। कंपोनेंट्स स्तर एक कंटेनर को उसके कार्यात्मक हिस्सों में बांटता है। यह स्तर एप्लिकेशन के तर्क के रहने का स्थान है। यह डिजाइन और कार्यान्वयन चरण के दौरान डेवलपर्स द्वारा सबसे अधिक उपयोग किया जाने वाला स्तर है।

एक कंपोनेंट कोड की एक तार्किक इकाई का प्रतिनिधित्व करता है। यह एक क्लास, मॉड्यूल, पैकेज या फ़ंक्शन हो सकता है। लक्ष्य संबंधित कार्यक्षमता को एक साथ जोड़ना है। उदाहरण के लिए, एक उपयोगकर्ता प्रबंधन कंटेनर में, आपको “प्रमाणीकरण”, “उपयोगकर्ता प्रोफ़ाइल” और “अनुमतियां” के लिए कंपोनेंट्स हो सकते हैं।

कंपोनेंट आरेखों के लाभ

• स्पष्टता:दिखाता है कि जिम्मेदारियां कैसे विभाजित हैं।
• स्वतंत्रता:कोड के हिस्सों के बीच निर्भरताओं को उजागर करता है।
• ओनबोर्डिंग:नए डेवलपर्स को कोड संरचना को तेजी से समझने में मदद करता है।

इस स्तर पर, संबंध और भी विस्तृत होते हैं। आप देख सकते हैं कि कौन सा कंपोनेंट किस अन्य कंपोनेंट को कॉल करता है। इससे सर्कुलर निर्भरताओं की पहचान करने में मदद मिलती है, जो बग्स और रखरखाव की समस्याओं का एक सामान्य स्रोत है। इन कनेक्शनों को दृश्याकृत करके टीमें कोड को पुनर्गठित कर सकती हैं ताकि मॉड्यूलरिटी में सुधार किया जा सके।

स्तर 3 कब उपयोग करें

हर कंटेनर को कंपोनेंट आरेख की आवश्यकता नहीं होती है। यदि एक कंटेनर सरल है, तो एक बॉक्स काफी हो सकता है। हालांकि, यदि एक कंटेनर में जटिल तर्क है, तो इसे बांटना आवश्यक है। स्तर 3 आरेख बनाने का निर्णय कोड की जटिलता और संचार की आवश्यकता पर आधारित होना चाहिए।

हर एक क्लास के लिए आरेख बनाने की कोशिश न करें। इससे जानकारी के अत्यधिक भार का नतीजा होता है। प्रणाली के व्यवहार को परिभाषित करने वाले प्रमुख संरचनात्मक ब्लॉक्स पर ध्यान केंद्रित करें। इसे एक पड़ोस के नक्शे के रूप में सोचें, न कि हर सड़क के नक्शे के रूप में।

💻 स्तर 4: कोड

C4 मॉडल का अंतिम स्तर कोड स्तर है। यह वह स्थान है जहां कार्यान्वयन के विवरण दिखाए जाते हैं। इसमें क्लास आरेख, अनुक्रम आरेख और डेटा मॉडल शामिल हैं। हालांकि यह शक्तिशाली है, लेकिन आम आर्किटेक्चरल संचार के लिए यह स्तर अक्सर सबसे कम आवश्यक होता है।

कोड आरेख बहुत अस्थिर होते हैं। जैसे ही कोई डेवलपर एक चर का नाम बदलता है या कोई विधि स्थानांतरित करता है, आरेख पुराना हो जाता है। इस कारण, C4 मॉडल कोड आरेखों का उपयोग केवल तभी करने की सलाह देता है जब बिल्कुल आवश्यक हो।

स्तर 4 के उपयोग के मामले

• जटिल एल्गोरिदम: जब तर्क केवल पाठ के लिए बहुत जटिल होता है।
• डेटाबेस स्कीमा: तालिका संबंधों और विदेशी कुंजियों को दिखाना।
• API विनिर्देश: विस्तृत अनुरोध और प्रतिक्रिया संरचनाएं।

आधुनिक विकास व्यवहार अक्सर कोड कमेंट्स और स्वचालित दस्तावेजीकरण पर निर्भर करते हैं ताकि हाथ से बने कोड आरेखों की जगह ले सकें। यदि आप स्तर 4 के आरेखों को बनाए रखने का चयन करते हैं, तो उन उपकरणों का उपयोग करने के बारे में सोचें जो इस जानकारी को सीधे कोडबेस से निकाल सकें। इससे रखरखाव के बोझ में काफी कमी आती है।

याद रखें कि कोड आरेख उच्च स्तर के दृश्यों का समर्थन करने चाहिए, उनके स्थान पर नहीं। एक डेवलपर को एक विशिष्ट बग को समझने के लिए अनुक्रम आरेख देखने की आवश्यकता हो सकती है, लेकिन वे इसे देखे बिना भी संपूर्ण प्रणाली डिज़ाइन को समझ सकते हैं।

📊 स्तरों की तुलना

अंतर स्पष्ट करने के लिए, यहां C4 मॉडल के चार स्तरों की तुलना करने वाली सारांश तालिका दी गई है।

स्तर	नाम	इसका उपयोग कौन करता है?	फोकस	अमूर्तता
1	प्रणाली संदर्भ	हितधारक, आर्किटेक्ट्स	सीमा और बाहरी प्रणालियां	उच्च
2	कंटेनर	डेवलपर्स, डेवोप्स	डेप्लॉयमेंट इकाइयां	मध्यम
3	घटक	विकासकर्ता	तार्किक कोड संरचना	कम
4	कोड	विकासकर्ता	कार्यान्वयन विवरण	बहुत कम

यह तालिका व्यापार संदर्भ से तकनीकी विवरण तक के विकास को उजागर करती है। स्तर 1 से स्तर 4 तक जाने से विवरण बढ़ता है लेकिन समझ की चौड़ाई कम हो जाती है। एक अच्छी आर्किटेक्चर रणनीति इन स्तरों को दर्शक के आधार पर संतुलित करती है।

🛠️ कार्यान्वयन रणनीति

C4 मॉडल को अपनाने के लिए टीमों के दस्तावेजीकरण के तरीके में बदलाव की आवश्यकता होती है। यह अधिक चित्र बनाने के बारे में नहीं है; यह उन चित्रों को बनाने के बारे में है जो सहीचित्र हैं। यहां एक प्रोजेक्ट में इस मॉडल को लागू करने का एक व्यावहारिक तरीका दिया गया है।

1. संदर्भ से शुरू करें

हर नए प्रोजेक्ट की शुरुआत सिस्टम संदर्भ को परिभाषित करके करें। टीम को इकट्ठा करें और यह सहमति बनाएं कि सिस्टम क्या करता है और इसका उपयोग कौन करता है। इस समन्वय से बाद में स्कोप क्रीप को रोका जा सकता है। यदि संदर्भ स्पष्ट नहीं है, तो आंतरिक डिजाइन को नुकसान होगा।

2. कंटेनर को परिभाषित करें

अगला, मुख्य निर्माण ब्लॉक की पहचान करें। तय करें कि कोड कहां चलेगा और डेटा कहां रहेगा। इस निर्णय को इंफ्रास्ट्रक्चर लागत और डेप्लॉयमेंट रणनीतियों पर प्रभाव पड़ता है। इस चरण में तकनीकी चयनों के बारे में स्पष्ट होना चाहिए।

3. आवश्यकता के अनुसार घटकों को बेहतर बनाएं

जैसे डिजाइन परिपक्व होता है, जटिल कंटेनरों को तोड़ें। हर एक विशेषता के लिए ऐसा न करें। केवल उन क्षेत्रों के लिए घटक आरेख बनाएं जहां समझना मुश्किल हो या विकासकर्ताओं के बीच विशिष्ट समन्वय की आवश्यकता हो।

4. वर्कफ्लो के साथ एकीकृत करें

दस्तावेजीकरण को अलग कार्य के रूप में नहीं रखना चाहिए। आरेख बनाने को विकास प्रक्रिया में एकीकृत करें। जब कोई पुल रिक्वेस्ट एक नई मुख्य विशेषता जोड़ती है, तो संबंधित आरेख को अपडेट करें। इससे दस्तावेजीकरण को कोड के साथ समकालीन रखा जाता है।

🛑 बचने के लिए सामान्य त्रुटियां

स्पष्ट मॉडल होने पर भी टीमें गलतियां कर सकती हैं। इन त्रुटियों के बारे में जागरूक रहने से दस्तावेजीकरण की अखंडता बनाए रखने में मदद मिलती है।

• अत्यधिक डिजाइन:हर छोटे मॉड्यूल के लिए आरेख बनाना। इससे मरम्मत के लिए दायित्व बढ़ता है बिना किसी मूल्य जोड़े।
• संबंधों को नजरअंदाज करना:यह दिखाए बिना बॉक्स बनाना कि वे कैसे जुड़ते हैं। तीर बॉक्स के बराबर महत्वपूर्ण हैं।
• पुराने आरेख:आरेखों को अप्रासंगिक होने देना। एक अप्रासंगिक आरेख कोई आरेख से भी बदतर है क्योंकि यह गलत विश्वास पैदा करता है।
• गलत स्तर का उपयोग करना: प्रबंधन को कोड विवरण या विकासकर्ताओं को उच्च स्तर का संदर्भ दिखाना। विवरण को दर्शकों के अनुरूप बनाएं।

एक और सामान्य समस्या स्तरों को मिलाना है। एक आरेख को स्पष्ट रूप से एक स्तर से संबंधित होना चाहिए। डेटाबेस स्कीमा (स्तर 4) को उच्च स्तर के सेवा प्रवाह (स्तर 2) के साथ मिलाना पाठक को भ्रमित करता है। स्तरों को अलग-अलग रखें।

🔄 रखरखाव और विकास

सॉफ्टवेयर आर्किटेक्चर स्थिर नहीं है। आवश्यकताएं बदलती हैं, तकनीक विकसित होती है, और टीमें पुनर्गठित होती हैं। दस्तावेज़ीकरण को इसके साथ विकसित होना चाहिए। आर्किटेक्चर आरेखों की नियमित समीक्षा आवश्यक है।

सिस्टम संदर्भ और कंटेनर आरेखों की तिमाही समीक्षा योजना बनाएं। ये सबसे स्थिर और उच्च मूल्य वाले दृश्य हैं। यदि टीम संरचना अक्सर बदलती है, तो कंपोनेंट आरेखों की अधिक बार समीक्षा की जा सकती है।

अपडेट प्रक्रिया को स्वचालित करना आदर्श है। कुछ उपकरण आपको आरेखों को कोड भंडारों से जोड़ने की अनुमति देते हैं। जब कोड में परिवर्तन होता है, तो आरेख स्वतः अपडेट हो जाता है। यह मानवीय प्रयास को कम करता है, लेकिन अभी भी मानवीय समीक्षा की आवश्यकता होती है ताकि अनुकरण सही रहे।

🤝 सांस्कृतिक प्रभाव

तकनीकी लाभों के अलावा, C4 मॉडल टीम संस्कृति को प्रभावित करता है। यह एक साझा शब्दावली को बढ़ावा देता है। जब सभी लोग “कंटेनर” और “कंपोनेंट” शब्दों का निरंतर उपयोग करते हैं, तो संचार तेज और अधिक सटीक हो जाता है।

इस साझा समझ से कोड समीक्षा के दौरान घर्षण कम होता है। “यह सेवा क्या करती है?” पूछने के बजाय, एक विकासकर्ता कह सकता है, “यह कंपोनेंट यूजर कंटेनर का हिस्सा है।” आरेख प्रश्न का उत्तर तुरंत देने के लिए आवश्यक संदर्भ प्रदान करता है।

यह जूनियर विकासकर्ताओं को भी सशक्त बनाता है। वे सिस्टम संदर्भ को देखकर यह समझ सकते हैं कि उनका काम कहाँ फिट होता है। वे कंपोनेंट आरेखों को देखकर अपने कोड को कैसे एकीकृत करना है, यह समझ सकते हैं। इससे प्रत्येक डिज़ाइन निर्णय के लिए सीनियर आर्किटेक्ट्स पर निर्भरता कम होती है।

📈 सफलता का मापन

आप कैसे जानेंगे कि C4 मॉडल काम कर रहा है? ओनबोर्डिंग समय में सुधार, आर्किटेक्चरल देनदारी में कमी और स्पष्ट संचार के लिए देखें। यदि नए टीम सदस्य त्वरित दिनों में प्रणाली को समझ सकते हैं, तो दस्तावेज़ीकरण प्रभावी है।

आर्किटेक्चर से संबंधित प्रश्नों की आवृत्ति का अनुसरण करें। यदि प्रश्न कम होते हैं, तो इसका मतलब है कि दस्तावेज़ीकरण उत्तर प्रदान कर रहा है। यदि प्रश्न बढ़ते हैं, तो आरेख बहुत जटिल या अद्यतन नहीं हो सकते हैं।

🏁 अंतिम विचार

आर्किटेक्चर की भ्रम निर्माण की जटिलता का प्राकृतिक परिणाम है। C4 मॉडल उस जटिलता में से एक सिद्ध मार्ग प्रदान करता है। इसके लिए महंगे उपकरणों या तीव्र प्रक्रिया परिवर्तन की आवश्यकता नहीं है। इसके लिए स्पष्टता और स्थिरता के प्रति प्रतिबद्धता की आवश्यकता है।

सही दर्शक के लिए सही स्तर के विवरण पर ध्यान केंद्रित करके, टीमें ऐसी प्रणालियाँ बना सकती हैं जो समझने, रखरखाव और विकास के लिए आसान हों। दस्तावेज़ीकरण में निवेश किया गया प्रयास लंबे समय तक उत्पादकता और प्रणाली स्थिरता में लाभ देता है। संदर्भ से शुरू करें, आवश्यकता पड़ने पर गहराई में जाएं, और आरेखों को जीवंत रखें।

याद रखें कि लक्ष्य पूर्णता नहीं है। लक्ष्य समझ है। थोड़ा पुराना होने पर भी प्रणाली को अच्छी तरह समझाने वाला आरेख उस आदर्श आरेख से बेहतर है जिसे कोई नहीं पढ़ता। सौंदर्यात्मक पूर्णता की तुलना में संचार को प्राथमिकता दें।

जैसे आप आगे बढ़ते हैं, दर्शक को ध्यान में रखें। चाहे वह एक हितधारक हो, एक विकासकर्ता हो या ऑपरेशंस इंजीनियर हो, यह सुनिश्चित करें कि आपके आरेख उनकी भाषा में बोलें। C4 मॉडल संरचना प्रदान करता है; आपकी टीम बुद्धिमत्ता प्रदान करती है। एक साथ, वे सॉफ्टवेयर डिलीवरी के लिए एक मजबूत आधार बनाते हैं।