क्विक सारांश: क्लीन आर्किटेक्चर, रॉबर्ट सी। मार्टिन

यह पुस्तक की छाप के साथ-साथ कुछ अवधारणाओं और ज्ञान के बारे में एक कहानी होगी, जो इस पुस्तक के लिए धन्यवाद, अध्ययन किए गए थे

आर्किटेक्चर

क्या आप इस प्रकाशन को पढ़ सकते हैं, इस प्रश्न का स्पष्ट उत्तर दे सकते हैं कि वास्तुकला क्या है? प्रोग्रामिंग और डिजाइन के संदर्भ में वास्तुकला क्या है? वह क्या भूमिका निभाती है? इस शब्द में बहुत सारी अस्पष्टताएँ हैं। और सब कुछ स्पष्ट प्रतीत होता है, लेकिन किसी तरह अमूर्त, और सटीकता के बिना। मार्टिन का मानना ​​है, और मैं उससे सहमत हूं, कि आवेदन में दो घटक हैं:

1. व्यवहार (व्यवहार) - कार्य और कार्य जो प्रोग्राम (घटक, सेवा) करता है।
2. वास्तुकला - यह शब्द बदलते अनुप्रयोगों के बारे में अधिक है।

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

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

लेखकों के बारे में

इससे पहले कि मैं इस किताब के बारे में कुछ कहूं, मैं अपने बारे में थोड़ा कहना चाहता हूं।
फिलहाल, मैं ASP .NET कोर के माध्यम से सेवाओं को विकसित करने में विशेषज्ञता वाला एक मजबूत जूनियर डेवलपर हूं।

अब मैं एक साल के लिए एक "गैलरी" पर काम कर रहा हूं, और मुझे थोड़ा सा लग रहा है

मैंने इस पुस्तक को पहले ही 2 बार पढ़ा है, और मैं इसे पढ़ने के लिए सभी को सलाह देता हूं:

• एम्बेडेड सिस्टम के डेवलपर्स;
• सामने के छोर;
• बैक एंडोर्स;
• और देवोपम भी।

सामान्य तौर पर, जो कोई भी कम से कम किसी तरह से पीपी के विकास से जुड़ा हुआ है, मेरा मतलब है कि अलग-अलग सायलोव और पीएम'ओव के प्रत्यक्ष विकास का मतलब है हम यहां ध्यान नहीं देते हैं (हालांकि यह जानना भी उपयोगी होगा कि एक नौकरानी कभी-कभी किसी कार्य पर 2 बार अधिक समय क्यों देती है), मैं आपको पढ़ने के लिए सलाह देता हूं। यह किताब।
और अब मैं यह तर्क देने की कोशिश करूंगा कि मुझे ऐसा क्यों लगता है

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

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

किताब के बारे में

पर निर्भर करता है

पुस्तक को पढ़ने से पहले, मैंने उसी होबे पर बहुत सारे लेख पढ़े, जहाँ "निर्भरता" जैसा शब्द दिखाई दिया। यह क्या है, कौन किस पर निर्भर है, क्या वास्तव में "पर निर्भर करता है" का अर्थ है, और कोई वर्ग किसी पर कैसे निर्भर हो सकता है?

और जैसे ही मैंने पुस्तक पढ़ी, मैंने दो बिंदु सीखे:

निर्भरता एक शब्द है जिसका अर्थ है कि कुछ वर्ग (घटक, सेवा) कुछ अन्य वर्ग (घटक, सेवा) के बारे में जानता है, और कोड स्तर पर यह ज्ञान निर्धारित किया जाता है (अब javists, sharpers, लोग मुझे समझेंगे) एक निश्चित नाम स्थान आयात द्वारा । दूसरे शब्दों में: आपके पास नाम ए डिफ़ॉल्ट के साथ एक वर्ग ए है। क्लासेस और एक वर्ग बी अन्य। क्लासेस। इसलिए, यदि क्लास A कोड किसी अन्य का उपयोग करता हुआ दिखाई दे। - इसका मतलब है कि क्लास A क्लास B पर निर्भर करता है।
इस योजना के अनुसार समझने के लिए कि आश्रित वर्ग कहाँ है और कहाँ नहीं है - तीर की दिशा को देखें: 1) तीर कक्षा B की दिशा में वर्ग A से इंगित करेगा। इसका मतलब है कि वर्ग B, वर्ग A की तुलना में अधिक स्वतंत्र है और वर्ग A में परिवर्तन है। , कोई "नुकसान" वर्ग बी के लिए

ठोस

इस पुस्तक को पढ़ने के मुख्य कारणों में से एक मूल स्रोत से SOLID सिद्धांतों की व्याख्या थी, क्योंकि अंकल रॉब ने इन सिद्धांतों को विकसित किया था और हम कह सकते हैं कि उनके लिए धन्यवाद हम इस नाम को सुनते हैं - SOLID।
उन लोगों के लिए जो इस सिद्धांत में नहीं हैं - इन सिद्धांतों को 5 नियमों के अनुसार अपने अनुप्रयोगों को डिजाइन करने के लिए कहा जाता है और सलाह दी जाती है:

एस - एसआरपी (एकल जिम्मेदारी सिद्धांत)
O - OCP (खुले-बंद सिद्धांत)
एल - एलएसपी (लिस्कोव प्रतिस्थापन सिद्धांत)
I - ISP (इंटरफ़ेस पृथक्करण सिद्धांत)
डी - डीआईपी (निर्भरता उलटा सिद्धांत)

इन सभी सिद्धांतों को कक्षाओं और वस्तुओं के स्तर पर, मॉड्यूल और घटकों के स्तर पर, और रेल (सेवाओं) के स्तर पर लागू किया जा सकता है।

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

निर्भरता उलटा के बारे में

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



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

वास्तु निर्णय लेने के बारे में

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

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

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

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

डीडीडी संदर्भ

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

यदि आप DDD के समर्थक हैं, या एक बनना चाहते हैं, या आप इस बारे में कुछ नहीं समझते हैं, लेकिन समझना चाहते हैं, तो पुस्तक को पढ़ना होगा, विशेष रूप से पुस्तक का दूसरा भाग।

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

सार संक्षेप

चाचा रॉब इस बारे में भी बात करता है कि कैसे कार्यान्वयन विवरण आपके सिस्टम को नुकसान पहुंचा सकते हैं और भविष्य में इसे बिना दर्द के विकसित होने से रोक सकते हैं।

याद रखें!
DB एक कार्यान्वयन विवरण है
ग्राहक (वेब, मोबाइल, आदि) - कार्यान्वयन विवरण
फ्रेमवर्क एक कार्यान्वयन विवरण है।

जितना संभव हो उतना सार करना आवश्यक है और उस पर निर्भर नहीं है, ऊपर वर्णित इंटरफेस और अमूर्तता, निर्भरता नियम और अन्य तंत्रों के साथ उलटा निर्भरता का उपयोग करना

मॉड्यूल के निर्माण के लिए तरीके

मुझे एएसपी .NET कोर पर एक सेवा डेवलपर के रूप में यह अनुभाग विशेष रूप से पसंद आया। इसके लिए तैयार घटकों से एकीकृत सेवा वास्तुकला के निर्माण के तरीकों का वर्णन करता है।

रॉबर्ट ने 4 संभावित परत अलगाव योजनाओं का वर्णन किया।

उन्होंने यह स्पष्ट किया कि 3-लेयर आर्किटेक्चर: UI (कंट्रोलर्स), सर्विसेज (डोमेन), DAL (डेटाबेस) का अक्सर इस्तेमाल किया जाने वाला तंत्र दूसरों की तुलना में क्यों खराब है। मैंने बहुत सी परियोजनाएं नहीं देखी हैं, लेकिन प्रत्येक में, उदाहरण के लिए, माइक्रो-सर्विस, बैक एंड पर, यह तीन-परत वास्तुकला का उपयोग करता है।

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

सामान्य तौर पर, पुस्तक की यह समीक्षा समाप्त हो गई है। मुझे वास्तव में पुस्तक ही पसंद आई, मैंने जो भी पढ़ा, उसका मुझे लेखक के प्रति आभार नहीं है। आपके ध्यान के लिए धन्यवाद, प्रिय पाठकों, कड़ाई से न्याय नहीं करते हैं - यह प्रकाशन पुस्तक और मेरे व्यक्तिगत उत्साह की धारणा पर आधारित है

अद्यतन 1.0

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