बॉब मार्टिन द्वारा "क्लीन आर्किटेक्चर" सभी आर्किटेक्चर के लिए अंगूठे का एक नियम है या यह सिर्फ विकल्पों में से एक है?


22

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

यह अच्छा कार्यक्रम लिखने का एक तरीका है, लेकिन एकमात्र तरीका नहीं है।

रेल और प्रतिक्रियाज 2 फ्रेमवर्क हैं जो दिमाग में आते हैं कि इस तरह की स्वच्छ वास्तुकला को बढ़ावा नहीं देते हैं। रेल आपके व्यापार तर्क को मॉडल ( FatModels और SkinnyControllers ) में होने की उम्मीद करती है, और आपके घटकों के अंदर प्रतिक्रिया करती है। दोनों कसकर जोड़े व्यापार तर्क और फ्रेमवर्क कोड के करीब पहुंचते हैं ।

मुझे 3 में से किसी भी तरीके से कुछ भी गलत नहीं लगता। यह किसी एक को चुनने के लिए एक निर्णय कॉल है।

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

तो, बॉब मार्टिन द्वारा "क्लीन आर्किटेक्चर" सभी आर्किटेक्चर के लिए अंगूठे का एक नियम है या यह सिर्फ विकल्पों में से एक है?


16
"क्लीन आर्किटेक्चर" कुछ ऐसा है जो बॉब मार्टिन ने आविष्कार किया था। बस।
रॉबर्ट हार्वे

2
शायद एक बेहतर सवाल यह है: रेल और रिएक्ट बेतहाशा सफल हैं। बॉब मार्टिन ने अपने क्लीन आर्किटेक्चर का उपयोग करते हुए, तुलना करने के लिए क्या लिखा है? मैं स्वयं इसका उत्तर जानना चाहूंगा।
user949300

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

1
स्टार्टअप और प्रोटोटाइप के लिए रेल बहुत सफल हो सकती है। जब 50 अन्य डेवलपर्स के साथ आगे बनाए रखने और विकसित करने का समय आता है - रेल "स्वतंत्रता" एक ऐसा मुद्दा बन जाता है जिससे जूझ रहे वरिष्ठ डेवलपर्स।
फैबियो

जवाबों:


34

जबकि "क्लीन आर्किटेक्चर" ठीक है और इसके कई फायदे हैं, यह याद रखना महत्वपूर्ण है:

  • द क्लीन आर्किटेक्चर काफी हद तक रॉबर्ट सी। मार्टिन की री-ब्रांडिंग है और संबंधित दृष्टिकोण जैसे जेफरी पलेर्मो (2008) और हेक्सागोनल आर्किटेक्चर ("पोर्ट्स एंड एडेप्टर") द्वारा एलिस्टेयर कॉकबर्न और अन्य (<2008) द्वारा विकसित किया गया है।

  • विभिन्न समस्याओं की अलग-अलग आवश्यकताएं होती हैं। क्लीन आर्किटेक्चर और संबंधित दृष्टिकोण डिकॉप्लिंग, लचीलापन और निर्भरता को ग्यारह तक बढ़ा देते हैं, लेकिन सादगी का त्याग करते हैं। यह हमेशा एक अच्छा सौदा नहीं है।

इन आर्किटेक्चर का अग्रदूत स्मॉलटाक से क्लासिक एमवीसी पैटर्न है। यह मॉडल को यूजर इंटरफेस (नियंत्रक और दृश्य) से अलग करता है, ताकि मॉडल यूआई पर निर्भर न हो। MVP, MVVM, जैसे MVC के कई रूप हैं…।

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

आमतौर पर, सर्वर अभी भी डेटाबेस या तीसरे पक्ष के प्रदाताओं जैसे बैकएंड सेवाओं पर निर्भर करता है। यह पूरी तरह से ठीक है, और एक साधारण स्तरित वास्तुकला की ओर जाता है।

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

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

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

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

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


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

2
मुझे उस तरह का बयान सुनना बहुत पसंद है, क्योंकि अक्सर मुझे ऐसे लोग मिल जाते हैं, जो आंख मूंदकर हर उस छोटी-सी चीज का अनुसरण करने की कोशिश करते हैं जो वह कहती है। कम से कम अगर "यह एक तरीका है, जो अक्सर काम करता है, लेकिन हमेशा सतर्क नज़र रखने के लिए" मुझे लगता है कि मैं उसके बारे में बेहतर महसूस कर सकता हूं, लेकिन मैं वास्तव में रॉबर्ट मार्टिन का प्रशंसक नहीं कह सकता
jleach

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

2
@bitsoflogic यह जानना अच्छा है! टीबीएच मैंने उनकी किताबें नहीं पढ़ी हैं और मेरी राय उनकी बातों, लेखों और उनके सामान को पढ़ने वाले लोगों के सवालों पर आधारित है। अब तक, मैंने और अधिक उदाहरण देखे हैं, जहां उनके पास ध्यान देने योग्य बारीकियों का अभाव है। यह एक वास्तविक समस्या है कि क्लीन कोड जूनियर देवों के लिए बहुत अधिक विपणन है, जो अभी तक संदर्भ में अपनी राय नहीं रख सकते हैं। स्वच्छ वास्तुकला के बारे में उनकी बात (यह प्रश्न एक रिकॉर्डिंग पर आधारित है) सीमाओं पर चर्चा नहीं करता है। जो दर्शक ठीक है, उसके लिए, जो उसे "अधिकार" मानता है, उसके लिए यह एक भ्रामक दृष्टिकोण प्रस्तुत करता है।
जुआन

1
@ मैं वास्तव में किसी को भी पैटर्न और आर्किटेक्चर के लिए समय और स्थान के बारे में अधिक गहराई से बात करते देखना पसंद करूंगा। वे आम तौर पर एक निश्चित समस्या से निपटने के लिए बाध्य होते हैं, ऐसा कोडिंग भाषा या व्यवसाय की आवश्यकता के कारण होता है, फिर भी चर्चा हमेशा "कैसे लागू करें" पर केंद्रित होती है। पुस्तक के लिए, कोडिंग के इतिहास के बारे में उनका ज्ञान (इसे जीते हुए) चीजों पर एक अनूठा दृष्टिकोण रखने में सक्षम था। उस ने कहा, मुझे लगता है कि आप किताब में वही मुद्दा पाएंगे जो आपने वार्ता में देखा था।
बिट्सफ्लॉजिक

24

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

आस - पास भी नहीं।

जब आप इसे देखते हैं:

यहाँ छवि विवरण दर्ज करें

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

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

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

अब चीजों को अस्तित्व में लाने से पहले आपको उन्हें अन्य चीजों में बदलना होगा। मैंने यहाँ खोजबीन की और उसे यह प्यारा सा चित्र दिया:

यहाँ छवि विवरण दर्ज करें

और तुम सब छोड़ कर भी निर्माण कर सकते हो main()

मैं बिल्डरों और कारखानों का उपयोग करने की सलाह दूंगा जब आप प्रक्रियात्मक निर्माण कोड के ढेर को अच्छे काटने के आकार के वैचारिक विखंडू में तोड़ना चाहते हैं। लेकिन स्वच्छ वास्तुकला या किसी भी अन्य buzzword आर्किटेक्चर में कुछ भी नहीं है जो आपको मांग करता है। तो अगर आप के साथ रहना चाहते हैं main(), ठीक है। बस, दया करो

बॉब मार्टिन द्वारा "क्लीन आर्किटेक्चर" सभी आर्किटेक्चर के लिए अंगूठे का एक नियम है या यह सिर्फ विकल्पों में से एक है?

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

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

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

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

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

आप सही हे। वह करता है। अंकल बॉब को लगता है कि ढांचे को पुस्तकालयों की तरह माना जा सकता है। और वे कर सकते हैं। लेकिन उस निर्णय पर भी आपको कुछ खर्च होता है।

श्री मार्टिन जो संरक्षित करने की कोशिश कर रहे हैं, वह एक ऐसी जगह है जहाँ आपकी सामान्य प्रयोजन की भाषा अभी भी सामान्य है। आप हर जगह एक रूपरेखा फैलाते हैं। जब आप ऐसा करते हैं, तो आप अपनी भाषा को किसी डोमेन विशिष्ट भाषा कहलाने की राह पर अग्रसर होते हैं। HTML एक डोमेन विशिष्ट भाषा है। यह बहुत अच्छी तरह से काम करता है, लेकिन ऐसे अन्य कार्य हैं जो यह बिल्कुल नहीं कर सकते हैं।

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


4

वीडियो को उद्धृत करने के लिए:

"आप SQL में मेल मर्ज नहीं करना चाहते हैं।"

के बाद:

"मैंने वास्तव में एक एसक्यूएल संग्रहित प्रक्रिया देखी थी जो एक संपूर्ण मेल मर्ज थी"

मेल मर्ज जैसे आर्किटेक्चर, कई में से सिर्फ एक विकल्प है।

जो वैकल्पिक नहीं है वे समस्याएं हैं जिन्हें वास्तुकला हल करने की कोशिश कर रही है।

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

यदि आप केवल एक वास्तुशिल्प शैली का अनुसरण करते हैं, क्योंकि यह अच्छी तरह से सोचा जाता है, तो आप गलतियां करने और समान समस्याओं का सामना करने की संभावना रखते हैं।


2

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

उपरोक्त कथन के कारणों के साथ क्लीन आर्किटेक्चर पर अंकल बॉब के लेख का एक वाक्य-दर-वाक्य विश्लेषण है:

ऑब्जेक्ट-ओरिएंटेड परिप्रेक्ष्य से स्वच्छ वास्तुकला


1

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

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


ऐसा लगता है कि बनाए गए बिंदुओं पर पर्याप्त रूप से कुछ भी नहीं दिया गया है और 4 पिछले उत्तरों में समझाया गया है
gnat
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.