मैं कैसे डिजाइन करना बंद कर दूं और मेरी अगुवाई में सुझाए गए इस प्रोजेक्ट को शुरू करना चाहिए? [बन्द है]


42

मैं एक जूनियर डेवलपर (~ 3 साल का ऍक्स्प) हूं और अपनी नौकरी पर हम एक नई प्रणाली के निर्माण की प्रक्रिया में हैं। मेरे लीड डेवलपर मुख्य वास्तुकार होंगे, हालांकि उन्होंने मुझे चुनौती दी है कि मैं सिस्टम को खुद (समानांतर में) आर्किटेक्चर करने की कोशिश करूं।

विचार-मंथन विचारों के कुछ पुनरावृत्तियों के दौरान और जो मैंने वास्तुकला के सुझावों के रूप में देखा था, उसे प्रस्तावित करते हुए, मेरे नेतृत्व ने मुझे यह प्रतिक्रिया दी कि मैं जो कर रहा हूं, वह "डिजाइनिंग" था न कि "आर्किटेक्चरिंग"।

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

मैं सॉफ्टवेयर डिजाइनर मोड से कैसे निकलूं और एक वास्तुकार की तरह अधिक सोचना शुरू कर दूं?


यहाँ "डिज़ाइन" के कुछ उदाहरण दिए गए हैं जो कि मेरे नेतृत्व द्वारा वास्तुकला के लिए प्रासंगिक नहीं थे:

  1. मैं हमारे सिस्टम से संसाधनों को लोड करने और उतारने के लिए एक एल्गोरिथ्म के साथ आया था और मेरे नेतृत्व ने कहा कि एल्गोरिदम स्पष्ट रूप से वास्तुकला नहीं हैं।
  2. मैं घटनाओं के एक सेट के साथ आया था जिसे सिस्टम को उठाना चाहिए और उन्हें किस क्रम में उठाना चाहिए, लेकिन यह भी इसे वास्तुकला के रूप में कटौती नहीं करता है।

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


यहाँ परियोजना के बारे में कुछ और विशिष्ट विवरण दिए गए हैं :

  • हम जिस प्रोजेक्ट का आर्किटेक्चर कर रहे हैं वह एक वेब एप्लिकेशन है।
  • मैं कोड की लगभग 10-100 हजार पंक्तियों का अनुमान लगा रहा हूं।
  • हम एक स्टार्ट अप हैं। हमारी इंजीनियरिंग टीम लगभग 3-5 लोग हैं।
  • निकटतम चीज जो हम अपने आवेदन की तुलना कर सकते हैं वह एक हल्का सीएमएस है। इसमें समान जटिलता है और यह मुख्य रूप से घटक लोडिंग और अनलोडिंग, लेआउट प्रबंधन और प्लग-इन स्टाइल मॉड्यूल के साथ संबंधित है।
  • आवेदन अजाक्स-वाई है। उपयोगकर्ता क्लाइंट को एक बार डाउनलोड करता है फिर डेटा का अनुरोध करता है क्योंकि उसे सर्वर से इसकी आवश्यकता होती है।
  • हम एमवीसी पैटर्न का उपयोग करेंगे।
  • आवेदन में प्रमाणीकरण होगा।
  • हम पुराने ब्राउज़र समर्थन (whew!) के बारे में बहुत चिंतित नहीं हैं, इसलिए हम नवीनतम और सबसे बड़ा लाभ उठाने के लिए देख रहे हैं जो कि बाहर है और बाहर आ जाएगा। (HTML5, CSS3, WebGL ;, मीडिया स्रोत एक्सटेंशन, और बहुत कुछ!)

यहाँ परियोजना के कुछ लक्ष्य हैं :

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


78
वास्तुकार कोई टोपी नहीं पहनता, बल्कि एक अमूर्त सिर की सुरक्षा प्रणाली को लागू करता है।
जॉन रेन्नोर

3
क्या आप अपने साथ आए सामान को साझा कर सकते हैं? मैं वास्तुकला को कार्यान्वयन अज्ञेय के रूप में वर्णन करने में संकोच कर रहा हूं ... शैतान हमेशा विवरण में होता है। उस ने कहा, आप नहीं चाहते कि विवरण बड़ी तस्वीर को अस्पष्ट करे। यह बताना मुश्किल है कि अधिक जानकारी के बिना कौन सा मामला है।
तेलस्टिन

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

3
@ डेरिल: मुझे निश्चित रूप से लगता है कि यह सीखने लायक है, हालांकि मैं आपके वास्तुकार के साथ मिलूंगा और पता लगाऊंगा कि वह वास्तव में किस डायग्राम का उपयोग कर रहा है (कुछ यूएमएल संदिग्ध मूल्य का है)।
रॉबर्ट हार्वे

जवाबों:


26

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

यह सब कहने के बाद, आप जिस स्थिति में हैं उसके लिए आपको कुछ सलाह की आवश्यकता है। वहाँ से बाहर सॉफ्टवेयर आर्किटेक्चर की एक पूरी दुनिया है, कागजात, किताबें, सम्मेलन, लेकिन आप आमतौर पर पैटर्न और अमूर्त की तलाश कर रहे हैं। परियोजना पर अधिक जानकारी के बिना मैं केवल एक व्यापक उदाहरण दे सकता हूं। उदाहरण के लिए, यदि आप एकीकरण में काम कर रहे थे तो सर्विस ओरिएंटेड आर्किटेक्चर ( SOA) है) पैटर्न जहां आप सिस्टम के कुछ हिस्सों को 'सेवाओं' में विभाजित करते हैं, इसलिए आप प्रत्येक भाग के साथ एक परिभाषित तरीके से काम कर सकते हैं, वेब प्रोग्राम में इसे तब वेब सेवाओं के रूप में लागू किया जाता है (हालांकि उस तक सीमित नहीं होना चाहिए) और हाल ही में JSON के साथ RESTful APIs का उदय, फिर से मैं कहूंगा कि यह SOA की वास्तुकला से आने वाला एक डिज़ाइन है। मैं कहूंगा कि मॉडल, व्यू, कंट्रोलर (एमवीसी) आम उपयोग में एक आर्किटेक्चर पैटर्न का एक और उदाहरण है, सिस्टम के घटकों की जिम्मेदारी को विभाजित करने के लिए भागों को स्वैप करने की अनुमति देने के लिए, त्रुटियों और परीक्षण को शामिल करने के लिए।

10,000 फीट के स्तर से, यदि आप इसे एक व्हाइटबोर्ड पर आकर्षित कर सकते हैं और एक सक्षम प्रोग्रामर को समझा सकते हैं जो आपके क्षेत्र में काम नहीं करता है और आपकी प्रोग्रामिंग भाषा और वर्तमान कार्यान्वयन विवरण नहीं जानता है तो यह संभवतः वास्तुकला है। यदि आप इसके बारे में एक किताब लिख सकते हैं कि आपकी कंपनी के बाहर किसी को भी इसकी परवाह होगी तो शायद यह वास्तुकला है। यदि आप अपने स्वयं को विस्तार से समझाते हैं और इसे अन्य कोड-बेस / कंपनियों / उद्योगों के लिए सामान्यीकृत नहीं कर सकते हैं तो संभवतः यह डिजाइन है।

मैं इस बात से सहमत हूं कि आपके द्वारा दिए गए दो उदाहरण कोड डिज़ाइन हैं न कि आर्किटेक्चर। पहला कारण यह है कि जब आप कहते हैं कि आप लोडिंग संसाधनों के लिए एक 'एल्गोरिथ्म' के साथ आए हैं, तो मुझे लगता है कि आप का मतलब है कि आपने उस कार्य को पूरा करने के लिए निर्देशों का एक सेट डिज़ाइन किया है, और यह नहीं कि आपने एक नया एल्गोरिथ्म डिज़ाइन किया है जो वे 1 वर्ष में सिखाएंगे अगले साल COMSC। दूसरे उदाहरण में, फिर से मैं मानता हूं कि यह डिजाइन है। यदि आपने मुझे इन विचारों में से किसी एक को दिखाया है तो मैं अपने यादृच्छिक सॉफ्टवेयर प्रोजेक्ट में उनका उपयोग नहीं कर पाऊंगा। आपको जावा में 'उच्च स्तर', ऑब्जेक्ट ओरिएंटेड (OO) पर जाना होगा, बजाय इसके कि मैं कस्टमर क्लास को पर्सन क्लास का सब-क्लास बनाना चाहता हूँ। यहां तक ​​कि सामान्य रूप से अपवादों के बारे में बात करना भी निम्न स्तर (कार्यान्वयन के बहुत करीब) माना जा सकता है।

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

आपकी स्थिति के लिए वास्तुकला के अन्य उदाहरण:

  1. पूरी मशीन को वर्चुअल मशीन पर रखना, क्लाउड प्रोवाइडर पर या घर में होस्ट करना और स्टेटलेस मशीन इंस्टेंसेस रखना, ताकि किसी भी मशीन को फेल करने पर किसी भी स्टेट को कॉपी किए बिना या किसी भी जानकारी को खोए बिना वर्चुअल मशीन के नए इंस्टेंस से बदला जा सके।
  2. अराजकता के साथ शुरुआत से लाइव उत्पादन विफलता परीक्षण में भवन ।

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


मैंने जिस प्रकार की परियोजना के साथ काम कर रहा हूं, उसके आसपास कुछ और विशिष्टता जोड़ी है। (उत्तर के लिए पीएस धन्यवाद! वहाँ बहुत सारे उपयोगी विवरण हैं जहाँ मैं प्रसंस्करण कर रहा हूँ।)
डेरिल

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

1
"अक्सर आर्किटेक्ट के लिए बहुत उपयोगी होता है कि जो संभव है उसका गहरा ज्ञान हो" मुझे लगता है कि यह सर्वोपरि है। मैं एक ऐसी इमारत में रहने की कल्पना नहीं कर सकता जहाँ वास्तुकार को लकड़ी, कंक्रीट और कांच की संभावनाओं का ज्ञान नहीं था। जितना गहरा ज्ञान उतना ही अधिक रोमांचक और जमीनी-स्थापत्य कला।
क्रिस वेसलिंग

हालांकि यहाँ लगभग सभी उत्तर मददगार रहे हैं, आपका शायद सबसे अधिक मददगार रहा है और समुदाय को यह सबसे उपयोगी भी लगता है।
दरियाल

16

इन दो विचारों के बीच अंतर वास्तव में महत्वपूर्ण है जहां मैं काम करता हूं।

जिसे आप "वास्तुकला" कहते हैं, "हम" अंग्रेजी में प्रोग्रामिंग कहते हैं। यह आंशिक रूप से महत्वपूर्ण है क्योंकि यदि आप इसे गैर-प्रोग्रामर में नहीं बता सकते हैं, तो कुछ गलत है। यह हो सकता है कि आप समस्या को अच्छी तरह से नहीं समझते हैं, या यह हो सकता है कि आप "प्रेत" समस्या को हल कर रहे हैं (यहां चर्चा नहीं की गई है)।

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

मैंने जो काम किया है, उससे कुछ उदाहरण:

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

वहां कोई कोड नहीं। किसी भी भाषा में लिखा जा सकता है। कार्यान्वयन इस विवरण द्वारा निर्धारित नहीं किया गया है।

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

फिर, यहां कुछ भी कार्यान्वयन को निर्धारित नहीं करता है, हालांकि कुछ कार्यान्वयन स्पष्ट रूप से दूसरों की तुलना में अधिक उपयोगी हैं।

डिज़ाइन (जिसे हम पैटर्न या कार्यान्वयन कहते हैं) और आर्किटेक्चर (जिसे हम डिज़ाइन कहते हैं) के बीच का अंतर यह है कि उनमें से एक कोडिंग / कार्यान्वयन समस्या को हल करता है और दूसरा वास्तविक दुनिया की समस्या को हल करता है।


2
आपका प्राकृतिक भाषा भेद मेरे लक्ष्य के लिए दिलचस्प और बहुत उपयोगी है। धन्यवाद!
डेरिल

14

शायद इससे मदद मिलेगी। मैंने हमेशा एक इंजीनियर की वरिष्ठता को एक सवाल के रूप में देखा है कि वे अपने दम पर कितनी बड़ी समस्या हल कर सकते हैं।

मोटे तौर पर, इस विचार को व्यक्त करने के लिए:

  • आप किसी को प्रोग्रामिंग के लिए नया, छोटे और निहित कार्यों के साथ कई नए निर्देश दे सकते हैं कि कैसे कार्य को अन्य टुकड़ों के साथ एकीकृत करने की आवश्यकता है

  • मध्य स्तर का देव वह है जो किसी एप्लिकेशन के कुछ हिस्से का विवरण ले सकता है, और उस एप्लिकेशन के संदर्भ में काम कर सकता है।

  • एक वरिष्ठ देव एक दुकान के तकनीकी बाधाओं के भीतर, खरोंच से एक मध्यम आकार के आवेदन का निर्माण कर सकता है।

  • एक अधिक वरिष्ठ देव ऐसा कर सकते हैं, और प्रौद्योगिकी विकल्पों को इस तरह से बना सकते हैं कि इसे अच्छी तरह से काम करने के लिए किन तकनीकों का उपयोग करना है।

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

वास्तुकार जो पूछ रहा है वह समस्या को आम तौर पर उससे भी अधिक देखने के लिए है। यदि आपको सिस्टम को काम करने के लिए कई अनुप्रयोगों को एक साथ रखना था:

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

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

(BTW, मेरे पास एक समान विकास वक्र है, जो आर्किटेक्ट के लिए मुझे समझाता है, संबंधित अनुप्रयोगों के एक परिवार के वास्तुशिल्प से लेकर या बहुत जटिल विशेषताओं का एक समूह है, एक समूह के लिए तकनीकी दिशा निर्धारित करने के लिए, पूरे संगठन के लिए रणनीतिक तकनीकी निर्णय लेने के लिए। ।)

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

... यहाँ एक सादृश्य है। मान लीजिए कि आपको एक मैजिक ब्लैक बॉक्स बनाने के लिए कहा गया है। एक इंजीनियर के रूप में, आपको मैजिक ब्लैक बॉक्स के आंतरिक कामकाज के बारे में जानने की उम्मीद है। लेकिन एक वास्तुकार के रूप में, आपका ध्यान अलग है। आप जिज्ञासा से बाहर बॉक्स में झांक सकते हैं सकता है, लेकिन आप सब कुछ के बारे में obsess की उम्मीद कर रहे हैं चारों ओर सब जादू काले बक्से।

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


2

"डिज़ाइन" और "आर्किटेक्चर" के बीच सटीक अंतर थोड़ा व्यक्तिपरक है और कुछ ओवरलैप है। हालाँकि, यह अंतर है क्योंकि मैं इसे समझता हूं:

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

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

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

ईवेंट फ्रेमवर्क में, डिज़ाइन कह सकता है "एक इवेंट इस इंटरफ़ेस का उपयोग करता है," और "एक थ्रेड पूल है जो इवेंट मैनेजर श्रमिकों को घटनाओं को भेजने के लिए उपयोग करता है।" MVC के लिए एक डिज़ाइन "मॉडल के लिए हाइबरनेट का उपयोग, नियंत्रक के लिए स्प्रिंग और दृश्य के लिए GWT हो सकता है।"

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

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


2

अगर मैं यहाँ कुछ भी जोड़ सकता हूँ , तो यह है: कोड मत सोचो । बिल्कुल भी।

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

आपके विशिष्ट उपयोग के मामले में, मेरी राय में और अधिक वास्तु प्रश्न इस प्रकार होंगे:

  • आप एमवीसी का उपयोग क्यों कर रहे हैं? क्या यह सब आप जानते हैं? उपयोग करने के लिए बेहतर पैटर्न हैं? क्यों?
  • आप किस रूपरेखा का उपयोग कर रहे हैं, और क्यों ?
  • कैसे होगा पैमाना? कोड-वार नहीं, क्योंकि अभी तक कोई फर्क नहीं पड़ता। क्षैतिज रूप से बड़े पैमाने पर स्थितियां क्या होंगी; आप यह करने के लिए किस सेवा (AWS) का उपयोग करेंगे?
  • प्रमाणीकरण कैसे किया जाएगा? कोड-वार नहीं: क्या आप प्रत्येक अनुरोध पर एक यादृच्छिक, अद्वितीय टोकन उत्पन्न करने जा रहे हैं और यह अपेक्षित टोकन के खिलाफ जाँच कर रहा है? यह मत सोचो कि आप कोड में यह कैसे करेंगे। इस बारे में सोचें कि आप ऐसा क्यों कर रहे हैं - क्योंकि यह व्यावहारिक रूप से किसी भी वेब भाषा में किया जा सकता है।

असल में, कोड के बारे में बात नहीं करते हैं। यहां तक ​​कि अगर तुम नहीं जानते कि कैसे कुछ करना है, जब कोई इच्छा होती है, तो एक तरीका है । इससे पहले कि आप वास्तव में उन्हें एक साथ रखने के बारे में चिंता करने से पहले पहेली के टुकड़े एक साथ कैसे फिट होंगे, इस बारे में अधिक सोचें।


1

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

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

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

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

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

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

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


0

एक डेवलपर के रूप में, आप शायद समाधान प्रदान करने के आदी हैं। यह सोचने का एक बहुत अच्छा तरीका है, लेकिन यह वास्तुकला के बारे में सोचने के दौरान आपको बाधा डाल सकता है।

मुझे पता है कि यह उस समस्या का वर्णन करने में मदद करता है जिसे आप पहले हल करने की कोशिश कर रहे हैं। क्या क्या चाहिए? क्या अड़चनें हैं? क्या आप इन आवश्यकताओं का पता लगाने के लिए हितधारकों से बात कर सकते हैं?

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

और चूंकि यह एक सीखने का अनुभव है, इसलिए सवाल पूछने से डरो मत, भले ही वे मूर्ख हों।


1
मैंने जोड़ा स्पष्टता के लिए परियोजना के कुछ लक्ष्यों की गणना की है।
डेरिल
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.