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

श्रृंखला के पिछले लेख में , मैंने एक अवधारणा मानचित्र प्रकाशित किया जो कोड प्रकारों के बीच संबंधों को दर्शाता है।

लेकिन यह हमेशा मुझे लगता था कि वहां सब कुछ बहुत अच्छी तरह से परिलक्षित नहीं होता है, मुझे नहीं पता था कि यह कैसे बेहतर है। यह एक सामान्य कोर के बारे में है।

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

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



इसके स्थान के बावजूद, मेरा मतलब यह नहीं था कि कॉमन कोर बाकी कोड पर निर्भर करता है या यह कि कॉमन कोर डोमेन लेवल के अंदर एक और लेयर है।

एक आम कोर क्या है!

डीडीडी के जनक एरिक इवांस द्वारा परिभाषित सामान्य कोर, कोड है कि विकास टीम कई सीमित संदर्भों के बीच विभाजित करने का निर्णय लेती है:

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

- "कॉमन कर्नेल" , वार्ड कनिंघम से डीडीडी विकी

इस प्रकार, यह किसी भी प्रकार का कोड हो सकता है: डोमेन-स्तरीय कोड, एप्लिकेशन-स्तरीय कोड, लाइब्रेरी ... जो भी हो।



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

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

निश्चित रूप से, यदि हमारे पास माइक्रोसर्विस की बहुभाषी प्रणाली है, तो सामान्य कोर वर्णनात्मक होना चाहिए, JSON, XML, YAML, इत्यादि में, ताकि सभी माइक्रोसिस्टर्स इसे समझ सकें।

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

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

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

जब भाषा पर्याप्त नहीं है ...

तो, हमारे पास सभी संकेंद्रित परतों के साथ आवेदन कोड है, और आवेदन कोर आम कोर पर निर्भर करता है, जो इस सभी कोड के तहत है।

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

हालांकि, सवाल उठता है: "क्या होगा यदि भाषा निर्माण पर्याप्त नहीं हैं?" खैर, जाहिर है, हम इन भाषाओं का निर्माण स्वयं करते हैं और इस प्रकार भाषा की खामियों की भरपाई करते हैं। लेकिन मेरे पास महत्वपूर्ण अनुवर्ती प्रश्न हैं: “इस कोड के अस्तित्व को कैसे और कहाँ तक उचित ठहराया जाए? इसका उपयोग कब और कैसे किया जाए, यह स्पष्ट रूप से कैसे इंगित किया जा सकता है? ”

मैंने जो कुछ देखा और किया, वह यूटिल्स या कॉमन्स नामक एक पैकेज था, जहां यह कोड स्थित है। लेकिन अंत में, हम वहाँ सभी कोड डंपिंग करते हैं, जिसे हम नहीं जानते हैं कि कहां रखा जाए! विभिन्न प्रयोजनों और उपयोग में आसानी के लिए सभी प्रकार के कोड (सीधे एक एडाप्टर में लिपटे ...) अंततः वहां डंप होते हैं। पैकेज का कोई वैचारिक अर्थ नहीं है, कोई सुसंगतता नहीं है, कोई सुसंगतता नहीं है, कोई स्पष्टता नहीं है, बहुत सारी अस्पष्टताएं हैं।

मैं Utils और Commons संकुल को छोड़ना चाहता हूँ!

सभी पैकेज में वैचारिक सामंजस्य होना चाहिए! यह स्पष्ट होना चाहिए कि पैकेज का उपयोग कब और कैसे करना है! कोई अस्पष्टता नहीं!

उदाहरण के लिए, यदि कोई एप्लिकेशन कमांड लाइन इंटरफ़ेस के साथ कुछ विशेष तरीके से इंटरैक्ट करता है, तो 'Acme / Util / SpecialCli' को नेमस्पेस में रखने के बजाय, आप इसे 'Acme / App / Infrastructure / Cli / SpecialCli' में रख सकते हैं। यह कहता है कि यह पैकेज सीएलआई के साथ जुड़ा हुआ है, यह एक्मे ऐप ऐप के बुनियादी ढांचे का हिस्सा है। ऐप इन्फ्रास्ट्रक्चर संबद्धता यह भी कहती है कि एप्लिकेशन के कर्नेल में एक पोर्ट होता है जिससे यह पैकेज मेल खाता है।

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

जिसे भाषा का हिस्सा माना जा सकता है उसका एक और उदाहरण PHP में अद्वितीय UUIDs है। भाषा के बाहर उनकी कल्पना करना काफी संभव है, क्योंकि हर बार एक नया संस्करण होता है और यह कोड समर्थन के साथ एक बुरा सपना होता है, लेकिन यह एक बहुत ही सामान्य अवधारणा है, भाषा का हिस्सा बनने के लिए एक व्यापक और पर्याप्त रूप से सुसंगत अवधारणा है।

तो क्यों नहीं एक UUID कार्यान्वयन बनाने और इसे PHP के हिस्से की तरह उपयोग करें, हम एक DateTime ऑब्जेक्ट का उपयोग कैसे करते हैं?! जब हम कार्यान्वयन को नियंत्रित करते हैं, तो मुझे कोई दोष नहीं दिखता है।

क्या सिद्धांत क्वेरी भाषा (DQL) के बारे में? (सिद्धांत PHP में हाइबरनेट पोर्ट है) क्या हम DQL को देख सकते हैं जैसे कि यह SQL, Elasticsearch QL या Mongo QL थे?

निष्कर्ष

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



मेरे लिए, निर्विवाद सत्य यह है कि वास्तुकला हमेशा मौजूद है, एकमात्र सवाल यह है कि क्या हम इसे नियंत्रित करते हैं या नहीं?

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