चंचल आर्किटेक्चर

Question

मैं अपने स्नातक थीसिस शुरू कर रहा हूँ और विषय "चुस्त आर्किटेक्चर"

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

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

Answer 1

मैं निम्नलिखित की सिफारिश:

1. भंडार पैटर्न
2. विशिष्टता पैटर्न
3. निर्भरता इंजेक्शन
4. डोमेन प्रेरित डिजाइन

मूल रूप से सब कुछ ALT.NET भीड़ का उपदेश।

Answer 2

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

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

Answer 3

यह एक दिलचस्प सवाल है, यह। क्या एक वास्तुकला अलगाव में चुस्त हो सकता है? अगर हम एक्सपी की तरह कुछ देख रहे हैं तो मैं थोड़ा संदिग्ध हूं। या शायद मैंने गलत समझा है, लेकिन यह मुझे कभी विस्तार से नहीं रोका है ...

XP में, एक दृष्टिकोण लेने के लिए मुझे और पता है, हम बहुत कम समय के भीतर कुछ प्रकार की संरचना के लिए जा रहे हैं एक परियोजना शुरू करो; वास्तव में पहली कहानी पूरी होने के बारे में, वास्तव में। प्रारंभिक कहानी-लेखन के दौरान हम कुछ विचार प्राप्त करना शुरू कर देंगे कि हम क्या बना सकते हैं - यह अनिवार्य है: प्रोग्रामर कोड के संदर्भ में सोचते हैं। लेकिन बहुत दूर सोचने से हमें YAGNI क्षेत्र में ले जाता है।

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

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

Answer 4

जहां तक ​​मुझे चिंतित है Agile इस तरह के किसी भी "आर्किटेक्चर" का प्रचार नहीं करता है।Agile एक पद्धति है जो मौलिक सिद्धांतों पर आधारित है जो परियोजना प्रबंधन, रिलीज चक्र और सामान्य विकास अभ्यास को प्रभावित करती है लेकिन निश्चित रूप से सॉफ्टवेयर वास्तुकला नहीं।

यहां सूचीबद्ध सभी सॉफ़्टवेयर पैटर्न का उपयोग एक मजबूत झरना प्रक्रिया का उपयोग करके किया जा सकता है जो Agile विकास के लिए अनाथाश्रम है।

Answer 5

Onion Architecture

example

Answer 6

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

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

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

Answer 7

एक आवश्यक डिजाइन प्रथाओं का सुझाव है कि मैं आपके आर्किटेक्चर के पहले एक कार्यात्मक, अंत-टू-एंड कंकाल का निर्माण करना चाहता हूं। असली प्रतिक्रिया से जितनी जल्दी हो सके इसे सत्यापित करने के लिए।

व्यावहारिक प्रोग्रामर "ट्रेसर बुलेट" और एलिस्टेयर कॉकबर्न को "walking skeleton" के रूप में संदर्भित करते हैं।

क्या आप यह भी परिभाषित कर सकते हैं कि में आपके थीसिस का संदर्भ क्या है? क्या आप केवल application software या पर विचार करते हैं क्या आप अधिक जटिल प्रणालियों से निपटते हैं?

Answer 8

यदि रॉबर्ट मार्टिन के पास इसके बारे में कुछ कहना है (और उसने मूल एग्इल मैनिफेस्टो मीटिंग आईआईआरसी कहा है), तो बिल्कुल वास्तुकला में चपलता के साथ सब कुछ है। उनकी पुस्तक Agile Software Development, Principles, Patterns, and Practices का पहला पहला भाग SOLID वास्तुशिल्प सिद्धांतों के बारे में है। कुछ तिमाहियों में यह कुछ हद तक विवादास्पद रहा है लेकिन मुझे समझ में नहीं आता क्यों। यदि आपका कोडबेस भंगुर और भारी युग्मित है तो यह बदलने के लिए बहुत खुला नहीं हो सकता है, जो चपलता का प्रतीक है। संकल्पनात्मक रूप से कोड अभ्यास से प्रक्रिया को अलग करना एक बहुत ही अजीब बात है।

घोषणापत्र का सिद्धांत 1: "हम प्रक्रियाओं और उपकरणों पर व्यक्तियों और बातचीत को महत्व देते हैं।"

कोडबेज के आर्किटेक्चर से अलग एक अमूर्तता के रूप में एग्इल "प्रक्रिया" को परिभाषित करने के लिए इस पहले सिद्धांत की भावना का उल्लंघन करता है।