आधुनिक सॉफ्टवेयर इंजीनियरिंग में, घटकों के बीच कैसे बातचीत होती है, इसकी समझ स्थिरता, स्केलेबिलिटी और रखरखाव के लिए महत्वपूर्ण है। जैसे-जैसे प्रणालियाँ जटिलता में बढ़ती हैं, स्पष्ट आर्किटेक्चरल दस्तावेजीकरण की आवश्यकता अत्यंत महत्वपूर्ण हो जाती है। C4 मॉडल सॉफ्टवेयर आर्किटेक्चर के दृश्यात्मक रूप से प्रस्तुत करने के लिए एक संरचित दृष्टिकोण प्रदान करता है, जो उच्च स्तर के संदर्भ से लेकर कोड-स्तरीय विवरण तक जाता है। इन स्तरों में से, वह कंटेनर दृश्य एक अद्वितीय स्थिति में है। यह व्यावसायिक क्षमताओं और नीचे के इंफ्रास्ट्रक्चर के बीच सेतु का कार्य करता है।
यह मार्गदर्शिका यह जांचती है कि C4 कंटेनर दृश्य का उपयोग करके इंफ्रास्ट्रक्चर निर्भरताओं को कैसे प्रभावी ढंग से मानचित्रित किया जाए। हम अबstraction के सिद्धांतों, दस्तावेजीकरण के लिए विशिष्ट प्रकार की निर्भरताओं और समय के साथ सटीकता बनाए रखने के लिए बेस्ट प्रैक्टिसेज के बारे में चर्चा करेंगे। इन रणनीतियों का पालन करके टीमें यह सुनिश्चित कर सकती हैं कि उनके आर्किटेक्चरल आरेख निर्णय लेने के लिए संबंधित और उपयोगी बने रहें।
📚 C4 मॉडल हायरार्की को समझना
C4 मॉडल आर्किटेक्चर दस्तावेजीकरण को चार अलग-अलग स्तरों में व्यवस्थित करता है। प्रत्येक स्तर एक विशिष्ट दर्शक जनता के लिए होता है और अलग-अलग स्तर की विस्तृत जानकारी प्रदान करता है। इंफ्रास्ट्रक्चर मानचित्रण के लिए कंटेनर दृश्य का सही उपयोग करने के लिए इन स्तरों को समझना आवश्यक है।
-
स्तर 1: सिस्टम संदर्भ 🌍
पूरे सिस्टम और उपयोगकर्ताओं और अन्य प्रणालियों के बीच संबंध को परिभाषित करता है। यह उच्चतम स्तर की अबस्ट्रैक्शन है। -
स्तर 2: कंटेनर 📦
प्रणाली के भीतर उच्च स्तर के सॉफ्टवेयर बिल्डिंग ब्लॉक्स का वर्णन करता है। एक कंटेनर सॉफ्टवेयर का एक डिप्लॉय किया गया इकाई है, जैसे वेब एप्लिकेशन, मोबाइल ऐप या डेटाबेस। -
स्तर 3: घटक ⚙️
कंटेनर्स को आंतरिक कार्यात्मक समूहों में बांटता है। इस स्तर पर कोड के आंतरिक संरचना पर ध्यान केंद्रित किया जाता है। -
स्तर 4: कोड 💻
विशिष्ट क्लासेज, फंक्शन या मॉड्यूल के विवरण देता है। इसे उच्च स्तर की आर्किटेक्चरल चर्चाओं में दुर्लभ रूप से शामिल किया जाता है।
जब इंफ्रास्ट्रक्चर निर्भरताओं का मानचित्रण करना हो, तो कंटेनर दृश्य (स्तर 2) सबसे उपयुक्त है। यह तकनीकी विवरण और व्यावसायिक प्रासंगिकता के बीच संतुलन बनाता है। यह आर्किटेक्ट्स को यह दिखाने की अनुमति देता है कि सॉफ्टवेयर घटक किस तरह इंफ्रास्ट्रक्चर संसाधनों पर निर्भर हैं, बिना सर्वर कॉन्फ़िगरेशन या कोड विशिष्टताओं में फंसे रहे।
🔍 कंटेनर दृश्य की व्याख्या
C4 मॉडल में एक कंटेनर एक अलग, डिप्लॉय किए जा सकने वाले सॉफ्टवेयर इकाई का प्रतिनिधित्व करता है। सामान्य उदाहरणों में शामिल हैं:
-
उपयोगकर्ता के अनुरोधों को सेवा करने वाला वेब एप्लिकेशन।
-
विशिष्ट व्यावसायिक तर्क को संभालने वाली माइक्रोसर्विस।
-
स्थायी डेटा संग्रहीत करने वाला डेटाबेस प्रबंधन प्रणाली।
-
उपयोगकर्ता उपकरण पर चलने वाला मोबाइल एप्लिकेशन।
-
एक योजना के अनुसार चलने वाला बैच प्रोसेसिंग कार्य।
कंटेनर दृश्य आरेख इन कंटेनरों और उनके बीच संबंधों को दृश्यात्मक रूप से प्रस्तुत करता है। यह प्रश्न का उत्तर देता है: “सॉफ्टवेयर के टुकड़े कैसे एक साथ काम करते हैं ताकि कार्यक्षमता प्रदान की जा सके?”
कंटेनर की मुख्य विशेषताएं
-
डिप्लॉय किया जा सकता है: इसे स्वतंत्र रूप से बनाया, परीक्षण किया और डिप्लॉय किया जा सकता है।
-
एक्जीक्यूटेबल: यह कार्य करने के लिए कोड चलाता है।
-
तकनीक विशिष्ट: इसमें एक तकनीकी स्टैक (उदाहरण के लिए, जावा स्प्रिंग बूट, पायथन डिजीन, पोस्टग्रेसक्यूएल) का अनुमान लगाता है।
-
सीमा: इसकी स्पष्ट इंटरफेस होती है जिसे अन्य कंटेनर उपयोग कर सकते हैं।
इन आरेखों को बनाते समय, प्रत्येक सर्वर इंस्टेंस की सूची बनाने से बचना आवश्यक है। इसके बजाय, समान इंफ्रास्ट्रक्चर को तार्किक कंटेनर में समूहित करें। उदाहरण के लिए, एक “वेब सर्वर” कंटेनर लोड बैलेंसर के पीछे सर्वर के क्लस्टर का प्रतिनिधित्व कर सकता है, बजाय दस अलग-अलग मशीनों के लिए दस अलग-अलग बॉक्स बनाने के।
🌐 इंफ्रास्ट्रक्चर निर्भरताओं का नक्शा बनाना
इस कार्य में मुख्य चुनौती सॉफ्टवेयर आर्किटेक्चर को उस इंफ्रास्ट्रक्चर से जोड़ना है जिस पर यह चलता है। जबकि C4 मॉडल मुख्य रूप से सॉफ्टवेयर-केंद्रित है, इंफ्रास्ट्रक्चर निर्भरताएं उन सॉफ्टवेयर कंटेनरों के आधार हैं जिन पर वे आधारित हैं। इन निर्भरताओं को सही तरीके से नक्शा बनाने से यह सुनिश्चित होता है कि इंफ्रास्ट्रक्चर में बदलाव सॉफ्टवेयर कार्यक्षमता को नहीं तोड़ते।
1. तार्किक बनाम भौतिक निर्भरताओं के बीच अंतर स्थापित करना
एक सामान्य गलती यह है कि सॉफ्टवेयर कंटेनर को भौतिक हार्डवेयर के साथ मिलाना। एक वेब एप्लीकेशन कंटेनर एक सर्वर पर चलता है, लेकिन आरेख मुख्य रूप से सॉफ्टवेयर सीमा पर ध्यान केंद्रित करना चाहिए।
|
पहलू |
तार्किक दृश्य |
भौतिक दृश्य |
|---|---|---|
|
केंद्रित बिंदु |
कार्यक्षमता और इंटरफेस |
हार्डवेयर और नेटवर्क टोपोलॉजी |
|
उदाहरण |
एपीआई गेटवे |
कुबरनेटीज क्लस्टर / ईसी2 इंस्टेंस |
|
स्थिरता |
उच्च (बदलाव दुर्लभ होते हैं) |
निम्न (बदलाव अक्सर होते हैं) |
|
आरेख का उपयोग |
सिस्टम डिज़ाइन |
डिप्लॉयमेंट योजना |
C4 कंटेनर दृश्य के संदर्भ में, हम सॉफ्टवेयर कंटेनर को उस इंफ्रास्ट्रक्चर संसाधन के साथ मैप करते हैं जिसकी इसके समर्थन के लिए आवश्यकता होती है। हम कंटेनर को सर्वर से बदलते नहीं हैं; हम संबंध को दिखाते हैं।
2. इंफ्रास्ट्रक्चर निर्भरताओं के प्रकार
इस संदर्भ में निर्भरताएं विशिष्ट श्रेणियों में आती हैं। उन्हें सही तरीके से पहचानने से आवश्यकता, सुरक्षा और प्रदर्शन की योजना बनाने में मदद मिलती है।
-
डेटा निर्भरताएं: डेटा कहां संग्रहीत है? इसमें डेटाबेस, ऑब्जेक्ट स्टोरेज और फाइल सिस्टम शामिल हैं। कंटेनर को डेटा पढ़ने और लिखने के लिए पहुंच की आवश्यकता होती है।
-
प्रक्रिया निर्भरताएं: क्या कंटेनर किसी अन्य प्रक्रिया से संचार करने की आवश्यकता रखता है? इसमें संदेश भंडार, कैशिंग लेयर और बैकग्राउंड वर्कर शामिल हैं।
-
नियंत्रण निर्भरताएं: क्या कंटेनर बाहरी प्रमाणीकरण या अनुमति सेवाओं पर निर्भर है? इसमें पहचान प्रदाता और API की चाबियां शामिल हैं।
-
गणना निर्भरताएं: क्या कंटेनर बाहरी गणना संसाधनों पर निर्भर है? इसमें सर्वरलेस फंक्शन या GPU इंस्टेंस शामिल हैं।
3. मैपिंग का दृश्यीकरण
इन निर्भरताओं को प्रभावी ढंग से मैप करने के लिए, आरेख में स्पष्ट नियमों का उपयोग करना चाहिए। तीर संचार की दिशा को दर्शाते हैं। लेबल प्रोटोकॉल या डेटा प्रकार का वर्णन करते हैं। इंफ्रास्ट्रक्चर तत्वों को ऐसे बॉक्स के रूप में दर्शाया जा सकता है जिनके विशिष्ट शैली हो ताकि उन्हें एप्लिकेशन कंटेनर से अलग किया जा सके।
उदाहरण के लिए, एक “उपयोगकर्ता इंटरफेस” कंटेनर किसी “बैकएंड API” कंटेनर से जुड़ सकता है। फिर “बैकएंड API” कंटेनर एक “संबंधात्मक डेटाबेस” कंटेनर और एक “कैश” कंटेनर से जुड़ता है। इनके नीचे, आप यह दर्शा सकते हैं कि डेटाबेस कंटेनर एक विशिष्ट इंफ्रास्ट्रक्चर परत पर स्थित है, जैसे कि एक प्रबंधित सेवा या एक समर्पित क्लस्टर।
🛠️ मैपिंग के लिए चरण-दर-चरण विधि
इंफ्रास्ट्रक्चर निर्भरताओं का सटीक मैप बनाने के लिए एक व्यवस्थित दृष्टिकोण की आवश्यकता होती है। एक प्रक्रिया का पालन करने से अलग-अलग टीमों और परियोजनाओं में सुसंगतता सुनिश्चित होती है।
चरण 1: मौजूदा कंटेनरों की सूची बनाएं
सबसे पहले सिस्टम सीमा के भीतर सभी सॉफ्टवेयर कंटेनरों की सूची बनाएं। इस सूची में शामिल होना चाहिए:
-
वेब एप्लिकेशन
-
API सेवाएं
-
डेटाबेस उदाहरण
-
संदेश भंडार
-
बाहरी सिस्टम एकीकरण
यदि सिस्टम विशाल है तो प्रत्येक माइक्रोसर्विस को शामिल नहीं करना चाहिए। मुख्य मूल्य प्रवाहों पर ध्यान केंद्रित करें। अपर्याप्त स्पष्टता बनाए रखने के लिए उपयुक्त स्थानों पर संबंधित सेवाओं को समूहित करें।
चरण 2: संचार बिंदुओं की पहचान करें
प्रत्येक कंटेनर के लिए, यह पहचानें कि वह अन्य कंटेनरों से कैसे जुड़ता है। निम्नलिखित प्रश्न पूछें:
-
किन प्रोटोकॉल का उपयोग किया जाता है (HTTP, gRPC, TCP)?
-
कौन सी डेटा आदान-प्रदान की जाती है?
-
क्या संपर्क सिंक्रोनस है या एसिंक्रोनस?
-
क्या सुरक्षा आवश्यकताएं हैं (TLS, प्रमाणीकरण)?
इस चरण में निर्भरताओं को स्पष्ट रूप से परिभाषित करने में मदद मिलती है। यह “यह जुड़ता है” के बजाय “यह HTTPS के माध्यम से JWT प्रमाणीकरण के साथ जुड़ता है” तक जाता है।
चरण 3: इंफ्रास्ट्रक्चर संसाधनों से जोड़ें
अब, कंटेनरों को इंफ्रास्ट्रक्चर से मैप करें। इसका मतलब भौतिक सर्वरों को बनाना नहीं है। बल्कि, इंफ्रास्ट्रक्चर के संदर्भ को दिखाने के लिए डायग्राम पर टिप्पणियाँ लगाएँ।
-
होस्टिंग परिवेश:क्या कंटेनर स्थानीय रूप से, क्लाउड में या हाइब्रिड में चल रहा है?
-
नेटवर्क सेगमेंटेशन:क्या कंटेनर एक सार्वजनिक सबनेट या निजी VLAN में है?
-
स्केलिंग:क्या कंटेनर को स्वचालित स्केलिंग की आवश्यकता है?
-
स्थायित्व:क्या डेटा मेमोरी, डिस्क या क्लाउड ऑब्जेक्ट स्टोर में स्टोर है?
इस जानकारी को स्पष्ट करने के लिए नोट्स या बाहरी टिप्पणियों का उपयोग करें, ताकि मुख्य डायग्राम गड़बड़ न हो। इससे दृश्य व्यवस्था साफ रहती है।
चरण 4: स्टेकहोल्डर्स के साथ सत्यापन करें
जब डायग्राम तैयार हो जाए, तो संबंधित टीमों के साथ इसकी समीक्षा करें। इसमें डेवोप्स, सुरक्षा और विकास नेताओं को शामिल किया जाता है।
-
डेवोप्स:इंफ्रास्ट्रक्चर के मान्यताओं की सही होने की पुष्टि करें।
-
सुरक्षा:सुनिश्चित करें कि संवेदनशील डेटा प्रवाह को सही तरीके से पहचाना गया है और सुरक्षित किया गया है।
-
विकास:सुनिश्चित करें कि तार्किक प्रवाह वास्तविक कार्यान्वयन के अनुरूप है।
इस सत्यापन चरण का बहुत महत्व है। यह दस्तावेजीकृत आर्किटेक्चर और वास्तविक डेप्लॉयमेंट के बीच अंतर को पकड़ता है।
✅ दस्तावेजीकरण के लिए सर्वोत्तम प्रथाएँ
आर्किटेक्चरल डायग्राम बनाए रखना अक्सर उन्हें बनाने से कठिन होता है। लंबे समय तक मूल्य सुनिश्चित करने के लिए, इन सर्वोत्तम प्रथाओं का पालन करें।
|
प्रथा |
इसका क्यों महत्व है |
कैसे लागू करें |
|---|---|---|
|
इसे सरल रखें |
जटिल डायग्रामों को नजरअंदाज कर दिया जाता है। |
प्रति डायग्राम कंटेनरों की संख्या 10-15 तक सीमित रखें। जूम स्तरों का उपयोग करें। |
|
नोटेशन को मानकीकृत करें |
यह सुनिश्चित करता है कि सभी प्रतीकों को समझते हैं। |
डेटाबेस, एपीआई और उपयोगकर्ताओं के लिए स्थिर आकृतियों का उपयोग करें। |
|
संस्करण नियंत्रण |
समय के साथ परिवर्तनों को ट्रैक करता है। |
आरेख के स्रोत फ़ाइलों को कोड भंडार में स्टोर करें। |
|
परिवर्तन पर अद्यतन करें |
पुरानी जानकारी को रोकता है। |
आरेख अद्यतनों को कोड पुल अनुरोधों से जोड़ें। |
|
मूल्य पर ध्यान केंद्रित करें |
स्पष्ट बातों के दस्तावेजीकरण से बचता है। |
केवल उन निर्भरताओं का दस्तावेजीकरण करें जो जोखिम या लागत को प्रभावित करती हैं। |
⚠️ बचने के लिए सामान्य त्रुटियाँ
यहाँ तक कि अनुभवी वास्तुकार भी निर्भरताओं के मानचित्रण के दौरान जाल में फंस सकते हैं। इन सामान्य समस्याओं के बारे में जागरूक रहने से उच्च गुणवत्ता वाले दस्तावेजीकरण के निर्माण में मदद मिलती है।
1. आरेख को अत्यधिक जटिल बनाना
हर एक निर्भरता को दिखाने की कोशिश करने से आरेख पढ़ने योग्य नहीं बन सकता है। यदि एक कंटेनर लॉगिंग सेवा से जुड़ता है, तो यह स्थापित ढांचा माना जा सकता है और अगर लॉगिंग रणनीति जटिल नहीं है तो इसके लिए अलग से बॉक्स बनाने की आवश्यकता नहीं है। निर्णायक मार्गों पर ध्यान केंद्रित करें जो प्रणाली की स्थिरता को प्रभावित करते हैं।
2. असमान धाराओं को नजरअंदाज करना
बहुत से आधुनिक प्रणालियाँ घटना-आधारित वास्तुकला पर निर्भर करती हैं। यदि आप केवल अनुरोध-प्रतिक्रिया तीर बनाते हैं, तो आप घटनाओं के प्रवाह को छोड़ देते हैं। असमान संदेशों, रेखाओं और प्रवाहों का प्रतिनिधित्व करने के लिए विभिन्न रेखा शैलियों या प्रतीकों का उपयोग करें।
3. ढांचे के विवरणों से उपयोगकर्ताओं को भ्रमित करना
कंटेनर दृश्य सॉफ्टवेयर के बारे में है। यदि आप भौतिक नेटवर्क स्विच, राउटर या फायरवॉल बनाते हैं, तो आप डेप्लॉयमेंट दृश्य में चले जा रहे हैं। ढांचे के मानचित्रण को उच्च स्तर पर रखें। विशिष्ट IP पतों या हार्डवेयर मॉडल के बजाय ढांचे के प्रकार का उल्लेख करें।
4. सुरक्षा सीमाओं का ध्यान न देना
निर्भरताएँ अक्सर सुरक्षा क्षेत्रों को पार करती हैं। प्राथमिकता या एन्क्रिप्शन की आवश्यकता होने वाले स्थान को निर्दिष्ट न करने से सुरक्षा लेखा की समस्या हो सकती है। सार्वजनिक नेटवर्कों को पार करने वाले या सख्त पहुंच नियंत्रण की आवश्यकता वाले संबंधों को स्पष्ट रूप से लेबल करें।
🔄 रखरखाव और विकास
वास्तुकला स्थिर नहीं है। प्रणालियाँ विकसित होती हैं, निर्भरताएँ बदलती हैं और ढांचा बदलता है। छह महीने पहले सही आरेख आज अप्रासंगिक हो सकता है। C4 कंटेनर दृश्य की अखंडता बनाए रखने के लिए, जीवंत दस्तावेजीकरण रणनीति अपनाएं।
जहां संभव हो, स्वचालित करें
कोड या कॉन्फ़िगरेशन फ़ाइलों से आरेख उत्पन्न करने वाले उपकरणों का उपयोग करें। इससे दस्तावेजीकरण के अद्यतन के लिए आवश्यक मैनुअल प्रयास कम होता है। यदि ढांचे का कोड बदलता है, तो आरेख स्वतः अद्यतन हो सकता है।
नियमित समीक्षाएँ
वास्तुकला आरेखों की नियमित समीक्षा की योजना बनाएं। इन समीक्षाओं के दौरान, यह सत्यापित करें कि आरेख प्रणाली की वर्तमान स्थिति के अनुरूप है। पूछें:
-
क्या नए कंटेनर जोड़े गए हैं?
-
क्या किसी कंटेनर को अप्रचलित या हटा दिया गया है?
-
क्या संचार प्रोटोकॉल में परिवर्तन हुए हैं?
-
क्या ढांचे का मानचित्रण अभी भी सही है?
CI/CD के साथ एकीकृत करें
निरंतर एकीकरण पाइपलाइन में आरेख सत्यापन को शामिल करने पर विचार करें। यदि एक पुल अनुरोध वास्तुकला में महत्वपूर्ण बदलाव करता है, तो सुनिश्चित करने के लिए एक जांच शुरू करें कि दस्तावेज़ीकरण अद्यतन किया गया है। इससे एक संस्कृति बनती है जहां दस्तावेज़ीकरण को कोड के रूप में माना जाता है।
📝 निर्भरता मैपिंग के लिए चेकलिस्ट
अपने C4 कंटेनर दृश्य आरेख को अंतिम रूप देने से पहले, पूर्णता सुनिश्चित करने के लिए इस चेकलिस्ट को दोहराएं।
-
☐ क्या सभी प्रमुख सॉफ्टवेयर कंटेनर शामिल हैं?
-
☐ क्या डेटा प्रवाह की दिशा स्पष्ट रूप से चिह्नित है?
-
☐ क्या संचार के लिए प्रोटोकॉल लेबल किए गए हैं?
-
☐ क्या इंफ्रास्ट्रक्चर संदर्भ टिप्पणी किए गए हैं (उदाहरण के लिए, क्लाउड, ऑन-प्रेम)?
-
☐ क्या सुरक्षा सीमाएं और प्रमाणीकरण विधियां नोट की गई हैं?
-
☐ क्या आरेख अनावश्यक तकनीकी भार से मुक्त है?
-
☐ क्या आरेखों की संचालन टीम द्वारा समीक्षा की गई है?
-
☐ क्या आरेख एक केंद्रीय, पहुंच योग्य स्थान पर संग्रहीत है?
🔗 अन्य दृश्यों के साथ एकीकरण
कंटेनर दृश्य अकेले नहीं मौजूद होता है। यह सिस्टम संदर्भ और कंपोनेंट दृश्य से जुड़ता है। जब इंफ्रास्ट्रक्चर निर्भरताओं को मैप करते हैं, तो इन दृश्यों में संगतता सुनिश्चित करें।
-
सिस्टम संदर्भ: सुनिश्चित करें कि यहां दिखाए गए बाहरी सिस्टम कंटेनर दृश्य में निर्भरताओं के साथ मेल खाते हैं।
-
कंपोनेंट दृश्य: सुनिश्चित करें कि आ inter घटक तार्किक रूप से उन कंटेनरों से मेल खाते हैं जिनमें वे स्थित हैं।
इस संरेखण से विरोधाभासों को रोका जाता है। उदाहरण के लिए, यदि कंटेनर को कंटेनर दृश्य में “केवल क्लाउड” के रूप में चिह्नित किया गया है, तो सिस्टम संदर्भ में इसे ऑन-प्रेम सर्वर पर चलते हुए नहीं दिखाना चाहिए। संगतता दस्तावेज़ीकरण में विश्वास बनाती है।
💡 अंतिम विचार
C4 कंटेनर दृश्य का उपयोग करके इंफ्रास्ट्रक्चर निर्भरताओं को मैप करना तकनीकी नेताओं और वास्तुकारों के लिए एक महत्वपूर्ण कौशल है। यह सॉफ्टवेयर के उस वातावरण के साथ बातचीत करने के तरीके के बारे में स्पष्टता प्रदान करता है जो इसका समर्थन करता है। एक संरचित दृष्टिकोण का पालन करके, सामान्य त्रुटियों से बचकर और समय के साथ आरेखों को बनाए रखकर, टीमें अपनी वास्तुकला का एक जीवंत मानचित्र बना सकती हैं।
इस स्पष्टता के कारण स्केलेबिलिटी, सुरक्षा और लागत के संबंध में बेहतर निर्णय लेने में सहायता मिलती है। यह अनावश्यक निर्भरताओं के कारण बाधाओं के जोखिम को कम करता है। अंततः, लक्ष्य पूर्ण आरेख बनाना नहीं है, बल्कि उपयोगी आरेख बनाना है जो टीम को उस प्रणाली को समझने में मदद करे जिसे वे बना रहे हैं और बनाए रख रहे हैं।
आधार से शुरू करें। अपने कंटेनर पहचानें। उनके संबंधों को मैप करें। इंफ्रास्ट्रक्चर संदर्भ को टिप्पणी करें। समीक्षा और सुधार करें। यह आवर्ती प्रक्रिया एक टिकाऊ वास्तुकला दस्तावेज़ीकरण की रचना करेगी जो समय के परीक्षण को सहन कर सकती है।