परियोजना वास्तुकला विकास, जहाज और जावास्क्रिप्ट

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

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



लेख पवित्रजेएस 2018 पाइटर सम्मेलन से एलेक्सी बोगाचुक ( ईपीएएम के समाधान-वास्तुकार) की एक रिपोर्ट पर आधारित है। Cutscene के तहत - रिपोर्ट का वीडियो और प्रतिलेख।

निर्माण वास्तुकला और परियोजना वास्तुकार की भूमिका के लिए दृष्टिकोण

स्वम - हम जानते हैं

तो स्वीडिश जहाज वासा से नाविकों ने कहा। वे बस रवाना हो गए, डूबते जहाज से भाग गए, जो अभी स्लिप से पानी में उतारा गया था। वासा का इससे क्या लेना-देना है?



आइए एक छोटी कहानी से शुरू करते हैं जो आपको एप्लिकेशन आर्किटेक्चर के निर्माण के दृष्टिकोण और प्रोजेक्ट आर्किटेक्ट की भूमिका पर एक पूरी तरह से अलग नज़र आती है।

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

• बाल्टिक बेड़े में जहाज सबसे बड़ा होना चाहिए: 70 मीटर लंबा, 10 चौड़ा;
  
• आपको तीन डेक चाहिए, जो 300 सैनिकों को समायोजित करेंगे;
  
• उसके पास दो पंक्तियों में 64 बंदूकें होनी चाहिए;
  
• निर्माण के लिए 3 वर्ष दिए गए हैं।
  

इस समय ऐसे जहाज के एनालॉग्स मौजूद नहीं थे। हालांकि, वह खुद भी लंबे समय तक नहीं रहे, इसके निर्माण के जश्न के बीच डूबने।

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

हेनरिक के निम्नलिखित वास्तुदोष स्पष्ट हैं (जो संयोगवश, अगर वह अदालत में बच गए तो उन्हें अपनी जान गंवानी पड़ सकती है):

• सभी परस्पर विरोधी प्रतिबंध संतुलित नहीं थे।
  
• कोई जोखिम प्रबंधन नहीं था, क्योंकि इससे पहले किसी ने भी इस परिमाण के जहाजों का निर्माण नहीं किया था।
  
• ग्राहक संबंध प्रबंधन भी अनुपस्थित था - हेनरिक में राजा के साथ बहस करने का साहस नहीं था।
  
• गलत निर्माण तकनीकों का इस्तेमाल किया।
  
• वास्तुकार असंभव आवश्यकताओं के लिए सहमत हुए।
  

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

शक्तिशाली दोस्त

कोड की पहली पंक्ति लिखने से पहले गलत आर्किटेक्चर वाले कितने एप्लिकेशन मृत हैं?
परियोजना पर वास्तुकला के प्रभाव का चक्र इस प्रकार है:



बाएं से दाएं:

1. इच्छुक पक्ष या हितधारक हैं (जहाज के मामले में, यह राजा और खजाना है)।
   
2. उनके अपने लक्ष्य हैं (यूरोप में पहला जहाज)।
   
3. लक्ष्य आवश्यकताओं (भविष्य के जहाज की विशिष्ट विशेषताओं) को निर्धारित करते हैं।
   
4. अगला, चित्र, आरेख और डिज़ाइन बनाए जाते हैं।
   
5. परियोजना पर निर्माण।
   

इनमें से किसी एक चरण में एक गलती आपके प्रोजेक्ट के भविष्य को पार कर सकती है।

समाधान वास्तुकार पुस्तिका

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

यदि हम अपने नायक के समय में रहते थे, जब वास्तुकला में गलतियों को मौत की सजा दी जाती थी, यह पुस्तक रक्त में लिखी जाएगी।

सभी कहानियों में वास्तुशिल्प काता (कार्य) दिए जाएंगे। वे ग्राहक की पहली आवश्यकताओं, समस्या का सार और निष्कर्ष के साथ एक सरलीकृत अनुरोध शामिल करेंगे।

जिमी की घड़ी की कहानी

ग्राहक की आवश्यकताएं

• वर्तमान UI-समाधान बदलें।
  
• इस समाधान के विकास और कार्यान्वयन के लिए एक नया दृष्टिकोण प्रस्तुत करें।
  
• एक बेहतर उपयोगकर्ता अनुभव की आवश्यकता है।
  
• इसी समय, सभी सर्वोत्तम प्रथाओं का पालन करें।
  
• विभिन्न प्लेटफार्मों के लिए समर्थन।
  

क्या किया गया है?

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



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

गलती क्या है? वास्तुकला को परिभाषित करने के पहले चरण में, हितधारकों को गलत तरीके से परिभाषित किया गया था।

निष्कर्ष

किसी भी वास्तुकला की शुरुआत हितधारकों की पहचान से होती है। उनकी पहचान करने के लिए, कई दृष्टिकोण हैं, हम उनमें से एक पर विचार करेंगे - हम एक आरएसीआई मैट्रिक्स का निर्माण करेंगे।

Raci

संक्षिप्त नाम यह है: आर - जिम्मेदार, जो लागू करेंगे; ए - जवाबदेह निर्णय निर्माताओं; सी - परामर्श (व्यवसायी लोग) सलाह देना; मैं - सूचित, जिन लोगों को सूचित करने की आवश्यकता है। इच्छुक पार्टियों में से प्रत्येक को एक या अन्य श्रेणी में सौंपा जाना चाहिए। मैट्रिक्स भूमिकाओं और कार्यों को इंगित करता है।



ऐसे मैट्रिक्स का निर्माण करने के बाद, हम समझ सकते हैं कि हितधारक कौन हैं।

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

प्याज़

प्याज का दृष्टिकोण RACI मैट्रिसेस से कुछ अलग है।



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

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

इतिहास: पर्याप्त उपवास नहीं

कंपनी के पास व्यापार से एक ग्राहक था, इस मामले में लेनदेन की गति बहुत महत्वपूर्ण है। इसके आधार पर, कई आवश्यकताओं को तैयार किया गया था।

ग्राहक की आवश्यकताएं

• प्रतिस्पर्धियों से तेज रहें
  

• लेन-देन को 0.5 सेकंड से अधिक समय में करना आवश्यक है।
  

क्या किया

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

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



निष्कर्ष

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

आप "खोज की आवश्यकताएं" पुस्तक में उपयोगी सिफारिशें पा सकते हैं, लेखक - इयान अलेक्जेंडर, लजेर्का बेयस-डुकिक।

घोड़े के अग्रदूतों ने कैसे दूध पिलाया इसकी कहानी

बीमा बेचने वाली कंपनी की अपनी वेबसाइट होती है। यह बहुत अच्छा काम करता है और इसमें अच्छी कार्यक्षमता स्थापित है। इसमें पहले से ही एक जटिल व्यावसायिक तर्क है।

ग्राहक की आवश्यकताएं

• साइट के अलावा, आपको एक मोबाइल एप्लिकेशन बनाने की आवश्यकता है जो कर्मचारी अपने फोन पर उपयोग करेंगे
  
• आवेदन में ऑफलाइन मोड होना चाहिए।
  

क्या किया

आवश्यकताओं के आधार पर, प्रतिक्रिया मूल में लिखने का निर्णय लिया गया। विकास शुरू हो गया है। पहली कॉल के दौरान, आवश्यकताओं के शोधन और परिवर्धन प्राप्त हुए थे:

• कंपनी कर्मचारियों को फोन जारी करती है, और वे सभी एंड्रॉइड पर काम करते हैं।
  
• ग्राहक केवल ऑफ़लाइन मोड में रुचि रखता है।
  
• समय सीमा - दो महीने।
  

जाहिर है, जटिल व्यापार तर्क के साथ एक तैयार तीसरे पक्ष के उत्पाद को छांटने और दो महीने में एक नया लिखने का काम ऐसे समय सीमा में फिट नहीं होता है। PWA (प्रोग्रेसिव वेब ऐप्स) का उपयोग करने का निर्णय लिया गया।

मुझे पहले से ही ऐसे काम का अनुभव था। सिर्फ एक PWA आवेदन नहीं लिखा गया था, यह आइसोमोर्फिक था। क्लाइंट पर सर्वर से सेवाओं का पुन: उपयोग किया गया था, विशेष आवरण लिखे गए थे जिनके साथ आप इन सेवाओं के साथ संवाद कर सकते थे। एक राउटर में लिखा गया था कि MongoDB डेटाबेस के सभी अनुरोधों को पुनर्निर्देशित किया गया था, क्लाइंट पर, एडेप्टर के माध्यम से, उन्होंने IndexedDB के साथ काम किया। नीचे योजना।



इसलिए, समस्याएं आवश्यकताओं के साथ थीं, जो इतनी सरल नहीं हैं। आवश्यकताओं क्या हैं के एक उदाहरण पर विचार करें:



एक रूप है, और हमें सत्यापन त्रुटियों का उत्पादन करने की आवश्यकता है, यदि गलत URL दर्ज किया गया है, तो हमें पृष्ठ 404 प्रदर्शित करने की आवश्यकता है। आवश्यकताओं के साथ क्या गलत है? वे इस बारे में बात करते हैं कि सिस्टम को क्या करना चाहिए। लेकिन वास्तुकार के लिए, क्या प्रणाली अधिक महत्वपूर्ण होनी चाहिए। यदि आप इस बात में तल्लीन हैं कि सिस्टम को क्या करना चाहिए, तो आप बहुत गहराई से विवरण में जा सकते हैं और गलत तरीके से जा सकते हैं। ऐसी आवश्यकताओं को कार्यात्मक कहा जाता है, उन्हें MoSCoW आवश्यकताएं भी कहा जाता है। इन आवश्यकताओं में अक्सर पाए जाने वाले शब्द:



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

निष्कर्ष

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

गोरे कौवे की कहानी

ग्राहक की आवश्यकताएं

• एक अलग सेवा विकसित करें जो डेटा को एक्सएमएल-प्रारूप में रूपांतरित और कैश करती है।
  
• उसे थर्ड-पार्टी विरासत प्रणाली से ऐसा करना चाहिए।
  

क्या किया

हमने एक अच्छी कामकाजी सेवा विकसित की है, यह Node.js. पर किया है। यह है कि पूरी तरह से एक प्रणाली के रूप में शुरू की गई नई सेवा के साथ एक साथ लग रहा था।



जाहिर है, Node.js यहाँ एक काली भेड़ है, इस तथ्य के बावजूद कि सब कुछ अच्छी तरह से काम किया।

ग्राहकों को सेवा के हस्तांतरण के दौरान त्रुटि का पता चला था जो Node.js. से परिचित नहीं थे यह स्थिति पूरी तरह से परियोजना के लिए बाधाओं की पहचान करने की भूमिका को दर्शाती है। सीमाएं क्या हैं?

• तकनीकी
  
• समय और बजट
  
• ग्राहक डेवलपर स्टैक
  

निष्कर्ष

वास्तुकार उन सभी मौजूदा प्रतिबंधों का पता लगाने के लिए बाध्य है जो अंतिम उत्पाद को प्रभावित कर सकते हैं। सीमाएं वास्तु निर्णय हैं जो आपके लिए पहले और बाद में किए गए हैं।

अगला, हम गुणवत्ता की विशेषताओं की ओर मुड़ते हैं, हम उनमें विशेष रुचि रखते हैं।

गुणवत्ता गुण

बहुत सुरक्षित पुस्तकालय

बहुत सारे गुणवत्ता गुण हैं, आपको बस उस सूची को देखना है जो विकिपीडिया हमें देता है।



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

जंगल में फोन

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



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

• UX में सुधार करें ताकि यह एक व्यक्ति को लगे कि उत्पादकता अधिक है।
  
• ऑप्टिमाइज़ रिसोर्स (JS, CSS, images, फोंट, आदि)।
  
• कैशिंग प्रदर्शन करें।
  
• सेवा-कार्यकर्ता, आलोचनात्मक मार्ग जोड़ें।
  
• संपीड़न लागू करें।
  
• HTTP / 2।
  

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

आइए CQRS (कमांड क्वेरी जिम्मेदारी अलगाव) पैटर्न का उपयोग करने का प्रयास करें। एक रणनीति के रूप में इस पैटर्न का उपयोग करना यहां तक ​​कि आवेदन की कई परतों को प्रभावित करता है: बैक-एंड और फ्रंट-एंड दोनों।



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



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

इसलिए, हमने कुछ रणनीति का इस्तेमाल किया। हम एप्लिकेशन लॉन्च करते हैं और देखते हैं कि यह मदद नहीं करता है, क्योंकि कोई इंटरनेट कनेक्शन नहीं है। तो हम गलती सहनशीलता के लिए आए थे कि समाधान वास्तुकार को ध्यान रखना चाहिए।

Steadfast टिन सैनिक

कोई भी नहीं चाहता कि आवेदन दिन में कई बार गिर जाए, हर कोई गलती सहिष्णुता चाहता है।

आवेदन के लिए कड़ाई से काम करने के लिए, तेजी से असफल सिद्धांत को लागू किया जा सकता है:

• हमेशा एकीकरण बिंदुओं को पहले से सत्यापित करें।
  
• धीमे कनेक्शन से बचें।
  
• अपनी प्रविष्टियां जांचें।
  

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



जबकि सब कुछ ठीक चल रहा है, हम कुछ नहीं कर रहे हैं। जैसे ही समय समाप्त हो जाता है, हम ऑफ़लाइन हो जाते हैं और थोड़ी देर बाद हम एक नया अनुरोध करते हैं। यदि अनुरोध फिर से एक त्रुटि के साथ होता है, तो हम एक बढ़े हुए समय के साथ ऑफ़लाइन मोड में रहते हैं। और अगर अनुरोध ठीक हो गया, तो हम ऑनलाइन मोड में लौट आए। इस प्रकार, यह पैटर्न एकीकरण बिंदुओं को सत्यापित करने और कनेक्शन को धीमा करने की अनुमति देता है।

पनडुब्बी

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

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

दुबली बाल्टी

ऊपर वर्णित एक के समान रणनीति का उपयोग लीक बाल्टी पैटर्न में किया जाता है।



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

कृपया ध्यान दें कि इस पैटर्न को लागू करने वाली सेवा को भी रणनीति, सत्यापन में लपेटा जाएगा और इसे बढ़ाया जाएगा। इसलिए वास्तुकला का निर्माण किया जाता है।



हरे तीर का क्या मतलब है? विभिन्न सेवाएं विभिन्न प्रोटोकॉल, डेटाबेस और अन्य सेवाओं के माध्यम से एक-दूसरे के साथ बातचीत करती हैं।

जो लोग दोष सहिष्णुता के पैटर्न के बारे में अधिक जानना चाहते हैं, उनके लिए रॉबर्ट एस। हैमर द्वारा दोष सहिष्णु सॉफ़्टवेयर के लिए पुस्तक पैटर्न सहायक होंगे।



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

मिठाई का उदाहरण

मामला

• हम मौजूदा प्लेटफॉर्म के लिए मौजूदा ग्राहकों में सुधार की पेशकश करना चाहते हैं।
  
• इस मंच पर लगभग 400 स्थिर साइटें पहले ही लिखी जा चुकी हैं।
  
• समस्या यह है कि यह महंगा और लंबा है।
  
• सामग्री प्रबंधन भी महंगा और लंबा है।
  
• मंच द्रुपाल में लिखा है।
  

मान लीजिए कि आप इन समस्याओं को हल करने के लिए निम्नलिखित रूपरेखाओं का उपयोग कर सकते हैं:



हमने पहले ही इच्छुक पार्टियों को ढूंढ लिया है। लक्ष्यों को परिभाषित करने की आवश्यकता है।

सबसे वैश्विक लक्ष्य ग्राहक को संतुष्ट करना है।

व्यावसायिक लक्ष्य ग्राहक की लागतों का अनुकूलन करना है (यह ग्राहक के लिए पहले से ही एक दिलचस्प लक्ष्य है)।
निम्नलिखित और अधिक निजी लक्ष्य हैं: बाजार में उत्पाद लाने में लगने वाले समय को कम करने के लिए, सामग्री प्रबंधन के समय को कम करना।

फिर निम्नलिखित प्रतिबंधों की खोज की जाती है:

• आपको ड्रुपल में लिखने की ज़रूरत है, क्योंकि ग्राहक ने कुछ समय के लिए लाइसेंस और समर्थन खरीदा है।
  
• परियोजना ReactJS और VueJS का उपयोग करती है, और ग्राहक इसे जारी रखना चाहता है, कंपनी किसी अन्य ढांचे पर विचार करने के लिए तैयार नहीं है।
  

गुणवत्ता गुण परिभाषित करने के बाद, हमें पता चला:

• सभी 400 साइटों (रखरखाव) का समर्थन करने की क्षमता को छोड़ना महत्वपूर्ण है।
  
• , (testability).
  
• (re-usability).
  
• (performance).
  
• (accessibility).
  

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

संदर्भ आरेख:



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

हम कंटेनर आरेख की ओर मुड़ते हैं:



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

एक घटक आरेख इस तरह दिखता है:



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

कंटेंट मैनेजमेंट वर्कफ़्लो को कैसे तेज़ करें? साइट पीढ़ी मॉड्यूल के साथ सीधे काम करने के लिए सामग्री प्रबंधकों को अवसर प्रदान करना आवश्यक है। पिछली सभी प्रथाओं को याद करते हुए, हम टेम्पलेट सेवा मॉड्यूल के लिए आवश्यक दृष्टिकोण जोड़ते हैं। ध्यान दें कि Drupal का उपयोग सामग्री हब में शुद्ध रूप से किया जाता है। हम निष्कर्ष निकालते हैं कि स्थिर पीढ़ी के लिए, NuxtJS या Next.js फ्रेमवर्क लिखे गए हैं, जो क्रमशः, Vue.js और React.js पर लिखे गए हैं। एकीकरण बिंदुओं के प्रतिस्थापन के रूप में, GitHub और शाखाओं का उपयोग करना फायदेमंद है, इसलिए हम JAM दृष्टिकोण पर आते हैं। जावास्क्रिप्ट, एपीआई, मार्कडाउन के रूप में अस्वीकृत।



यह देखा जा सकता है कि जिस स्टैक का उपयोग करने का निर्णय लिया गया था, वह मूल से अलग है। एक ओर, हमने Node.js और कुछ प्रकार के आधुनिक ढांचे का उपयोग किया। हम Drupal को सामग्री प्रबंधन के लिए छोड़ देंगे, लेकिन इसे हमारे सिस्टम से व्यवस्थित करने से, हम भविष्य में नए CMS के साथ एकीकरण कर पाएंगे, जो अधिक सुविधाजनक और तेज़ हो सकता है। इस प्रकार जावास्क्रिप्ट, एपीआई, मार्कडाउन दृष्टिकोण की समझ में आया।

निष्कर्ष

आपको अंतिम प्रौद्योगिकी स्टैक का सावधानीपूर्वक चयन करने की आवश्यकता है। यह हम आर्किटेक्ट की अपनी किताब में लिखते हैं।

अंतिम कहानी

केस

आर्किटेक्ट ने सभी हितधारकों, आवश्यकताओं, लक्ष्यों, सीमाओं की पहचान की। फिर एक निश्चित परियोजना बनाई गई थी। आवेदन का विकास सामान्य था, लेकिन अंत में परियोजना विफल हो गई।

ऐसा क्यों हुआ?

तथ्य यह है कि परियोजना के डेवलपर्स को आवश्यकताओं, हितधारकों, सीमाओं और गुणवत्ता विशेषताओं के बारे में पता नहीं था। टास्क ट्रैकर में कार्यों के रूप में विशेष रूप से विकास किया गया था, जो अंततः पूरे प्रोजेक्ट के पतन का कारण बना।

निष्कर्ष

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

परिणाम

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

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

यदि आपको रिपोर्ट पसंद आई है, तो ध्यान दें: 24-25 नवंबर को मॉस्को में एक नया होलीजेएस आयोजित होगा , और वहां कई दिलचस्प चीजें भी होंगी। कार्यक्रम के बारे में पहले से ही ज्ञात जानकारी साइट पर है, और वहां टिकट खरीदे जा सकते हैं।