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

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

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

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

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

• प्रणाली के मौलिक ब्लॉक
• उपकरण
• उपकरण और वितरण तंत्र को अनुप्रयोग कोर से जोड़ना
  
  • बंदरगाहों
  • प्राथमिक या नियंत्रण एडाप्टर्स
  • द्वितीयक या प्रबंधित एडेप्टर
  • नियंत्रण उलटा
• अनुप्रयोग कोर का संगठन
  
  • आवेदन स्तर
  • डोमेन स्तर
    
    • डोमेन सेवाएँ
    • डोमेन मॉडल
• घटकों
  
  • घटक डिस्कनेक्ट
    
    • अन्य घटकों में तर्क को ट्रिगर करना
    • अन्य घटकों से डेटा पुनर्प्राप्त करना
      
      • घटकों के लिए साझा डेटा संग्रहण
      • घटक के लिए अलग डेटा स्टोरेज
• नियंत्रण प्रवाह

प्रणाली के मौलिक ब्लॉक

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

इसके अलावा, पोर्ट्स एंड एडेप्टर आर्किटेक्चर सिस्टम में कोड के तीन मौलिक ब्लॉकों को स्पष्ट रूप से परिभाषित करता है:

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

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

जैसा कि आप कल्पना कर सकते हैं, एक सामान्य निष्पादन प्रवाह यूआई में कोड से एप्लिकेशन कोर के माध्यम से इंफ्रास्ट्रक्चर कोड तक जाता है, एप्लिकेशन कोर पर वापस जाता है और अंत में, प्रतिक्रिया यूआई को दी जाती है।

उपकरण

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



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

उपकरण और वितरण तंत्र को अनुप्रयोग कोर से जोड़ना

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

एडेप्टर जो एप्लिकेशन को कुछ करने के लिए कहते हैं, उन्हें प्राथमिक या नियंत्रण एडेप्टर कहा जाता है, जबकि एडेप्टर जो कुछ करने के लिए एप्लिकेशन को बताते हैं, उन्हें माध्यमिक या प्रबंधित एडेप्टर कहा जाता है।

बंदरगाहों

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

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

प्राथमिक या नियंत्रण एडाप्टर्स

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



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

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

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

द्वितीयक या प्रबंधित एडेप्टर

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



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

अब एक MySQL-विशिष्ट एडेप्टर बनाएं जो इस इंटरफ़ेस को लागू करेगा। इसमें सारणी को सहेजने और पंक्ति को तालिका में हटाने के लिए विधियाँ होंगी, और जहाँ दृढ़ता की आवश्यकता होगी, वहाँ हम इसे लागू करेंगे।

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

नियंत्रण उलटा

इस टेम्पलेट की एक विशेषता यह है कि एडेप्टर एक विशिष्ट उपकरण और एक विशिष्ट पोर्ट (एक इंटरफ़ेस को लागू करके) पर निर्भर करते हैं। लेकिन हमारा व्यावसायिक तर्क केवल पोर्ट (इंटरफ़ेस) पर निर्भर करता है, जिसे व्यापार तर्क की जरूरतों को पूरा करने के लिए डिज़ाइन किया गया है और यह किसी विशिष्ट एडेप्टर या उपकरण पर निर्भर नहीं करता है।



इसका मतलब यह है कि निर्भरताएं केंद्र की ओर निर्देशित होती हैं, अर्थात् , वास्तुकला स्तर पर नियंत्रण सिद्धांत का उलटा होता है ।

हालांकि, फिर से, यह जरूरी है कि पोर्ट को एप्लिकेशन कोर की जरूरतों के अनुसार बनाया जाए, न कि केवल टूल एपीआई की नकल करें ।

अनुप्रयोग कोर का संगठन

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

आवेदन परत (आवेदन परत)

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

उपयोग के मामलों को आवेदन स्तर पर परिभाषित किया जाता है - डीडीडी और प्याज वास्तुकला का पहला स्तर।



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

एप्लिकेशन सेवाओं और / या कमांड संचालकों में एक उपयोग मामले की तैनाती तर्क, एक व्यावसायिक प्रक्रिया होती है। एक नियम के रूप में, उनकी भूमिका इस प्रकार है:

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

कमान संचालकों को दो तरीकों से इस्तेमाल किया जा सकता है:

1. उनमें उपयोग के मामले को निष्पादित करने के लिए तर्क हो सकते हैं;
2. उन्हें हमारी वास्तुकला में एक कनेक्शन के सरल भागों के रूप में इस्तेमाल किया जा सकता है जो एक कमांड प्राप्त करते हैं और बस उस तर्क को लागू करते हैं जो एप्लिकेशन सेवा में मौजूद है।

उदाहरण के लिए उपयोग करने के लिए कौन सा दृष्टिकोण निर्भर करता है:

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

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

डोमेन स्तर

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

डोमेन सेवाएँ

जैसा कि मैंने ऊपर उल्लेख किया है, आवेदन सेवा की भूमिका:

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

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

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

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

डोमेन मॉडल

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

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

घटकों

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



मैं घटक पैकेजों के आयोजन का समर्थक हूं और बेशर्मी से साइमन ब्राउन के चित्र को निम्नानुसार बदलना चाहता हूं:



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

घटक डिस्कनेक्ट

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

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

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

अन्य घटकों में तर्क को ट्रिगर करना

जब हमारे घटक (घटक बी) में से एक को कुछ करने की आवश्यकता होती है जब कुछ और किसी अन्य घटक (घटक ए) में होता है, तो हम घटक ए से कक्षा बी / घटक बी के तरीके से सीधे कॉल नहीं कर सकते, क्योंकि तब A, B से जुड़ जाएगा।

हालांकि, हम एप्लिकेशन इवेंट को भेजने के लिए इवेंट मैनेजर का उपयोग कर सकते हैं, जो कि बी को शामिल करने वाले किसी भी घटक को वितरित किया जाएगा, और बी में इवेंट श्रोता वांछित कार्रवाई को ट्रिगर करेगा। इसका मतलब है कि घटक ए इवेंट मैनेजर पर निर्भर करेगा, लेकिन घटक बी से अलग होगा।

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

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

अन्य घटकों से डेटा पुनर्प्राप्त करना

जैसा कि मैं इसे देखता हूं, घटक को डेटा को संशोधित करने की अनुमति नहीं है कि यह "स्वयं" नहीं है, लेकिन यह किसी भी डेटा का अनुरोध और उपयोग कर सकता है।

घटकों के लिए साझा डेटा संग्रहण

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

घटक के लिए अलग डेटा स्टोरेज

इस स्थिति में, समान टेम्पलेट लागू किया जाता है, लेकिन डेटा संग्रहण स्तर अधिक जटिल हो जाता है। अपने स्वयं के डेटा वेयरहाउस के साथ घटकों की उपस्थिति का मतलब है कि प्रत्येक डेटा वेयरहाउस में शामिल हैं:

• डेटा का एक सेट जो एक घटक का मालिक है और बदल सकता है, जो इसे सच्चाई का एकमात्र स्रोत बनाता है;
• एक डेटासेट जो अन्य घटकों के डेटा की एक प्रति है जिसे वह स्वयं नहीं बदल सकता है, लेकिन वे घटक की कार्यक्षमता के लिए आवश्यक हैं। जब भी यह स्वामी घटक में बदलता है तो इस डेटा को अपडेट किया जाना चाहिए।

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

नियंत्रण प्रवाह

जैसा कि मैंने ऊपर कहा, कंट्रोल फ्लो उपयोगकर्ता से एप्लिकेशन कोर, इंफ्रास्ट्रक्चर टूल्स तक, फिर एप्लीकेशन कोर तक जाता है - और उपयोगकर्ता को वापस। लेकिन वास्तव में कक्षाएं एक साथ कैसे काम करती हैं? कौन किस पर निर्भर करता है हम उनकी रचना कैसे करते हैं?

अंकल बॉब की तरह, क्लीन आर्किटेक्चर पर अपने लेख में, मैं UMLish स्कीमा प्रबंधन के प्रवाह को समझाने की कोशिश करूँगा ...

बिना आज्ञा / अनुरोध बस

यदि हम कमांड बस का उपयोग नहीं करते हैं, तो नियंत्रक आवेदन सेवा या क्वेरी ऑब्जेक्ट पर निर्भर करेगा।

^{[पूरक ११/१ ]/२०११] मैंने डीटीओ को पूरी तरह से छोड़ दिया है, जिसका उपयोग मैं अनुरोध से डेटा वापस करने के लिए करता हूं, इसलिए मैंने इसे अभी जोड़ा है। MorphineAdministered के लिए धन्यवाद , जिसने एक स्थान का संकेत दिया ।} ऊपर दिए गए आरेख में, हम एप्लिकेशन सेवा के लिए इंटरफ़ेस का उपयोग करते हैं, हालांकि हम कह सकते हैं कि वास्तव में इसकी आवश्यकता नहीं है, क्योंकि एप्लिकेशन सेवा हमारे एप्लिकेशन कोड का हिस्सा है। लेकिन हम कार्यान्वयन को बदलना नहीं चाहते हैं, हालांकि हम एक पूर्ण रीफैक्टरिंग का संचालन कर सकते हैं।



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

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

उपयोग के मामले को पार्स करने के बाद, एप्लिकेशन सेवा पूरे सिस्टम को सूचित कर सकती है कि उपयोग का मामला हुआ है, तो यह घटना को ट्रिगर करने के लिए घटना डिस्पैचर पर निर्भर करेगा।

यह ध्यान रखना दिलचस्प है कि हम हठ इंजन और रिपॉजिटरी दोनों पर इंटरफेस की मेजबानी करते हैं। यह बेमानी लग सकता है, लेकिन वे विभिन्न उद्देश्यों की सेवा करते हैं:

• दृढ़ता इंटरफ़ेस ओआरएम पर एक अमूर्त परत है, जिससे हम एप्लिकेशन कोर को बदले बिना ओआरएम को स्वैप कर सकते हैं।
• persistence-. , MySQL MongoDB. persistence- , ORM, . , , , , , , MongoDB SQL.

C /

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

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

^{[पूरक ११/१ ]/२०११] मैंने डीटीओ को पूरी तरह से छोड़ दिया है, जिसका उपयोग मैं अनुरोध से डेटा वापस करने के लिए करता हूं, इसलिए मैंने इसे अभी जोड़ा है। आपका धन्यवादMorphineAdministered , जिसने एक स्थान का संकेत दिया ।} आपने देखा होगा कि बस, कमांड, अनुरोध और हैंडलर के बीच कोई निर्भरता नहीं होती है। वास्तव में, एक अच्छा अलगाव सुनिश्चित करने के लिए उन्हें एक दूसरे के बारे में जानने की आवश्यकता नहीं है। कमांड या अनुरोध को संसाधित करने के लिए एक विशिष्ट हैंडलर को बस को निर्देशित करने की विधि को एक सरल कॉन्फ़िगरेशन में कॉन्फ़िगर किया गया है। दोनों मामलों में, सभी तीर - निर्भरताएं जो आवेदन की कर्नेल सीमा को पार करती हैं - बिंदु आवक। जैसा कि पहले बताया गया है, यह पोर्ट्स एंड एडेप्टर, ओनियन और क्लीन आर्किटेक्चर का मौलिक नियम है।

निष्कर्ष

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

योजनाएं बेकार हैं, लेकिन योजना सब कुछ है। - आइजनहावर

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

हालांकि:

नक्शा एक क्षेत्र नहीं है। - अल्फ्रेड कोरज़ीबस्की

दूसरे शब्दों में, ये सिर्फ सिफारिशें हैं! एक आवेदन एक क्षेत्र, एक वास्तविकता, एक विशिष्ट उपयोग मामला है जहां हमें अपने ज्ञान को लागू करने की आवश्यकता है, और यह निर्धारित करता है कि वास्तविक वास्तुकला कैसा दिखेगा!

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

इस तरह मैं अपने लिए यह सब कल्पना करता हूं।

इन विचारों को अगले लेख में और अधिक विस्तार से चर्चा की गई है: "केवल गाढ़ा परतों से अधिक । "