एनीमिक डोमेन मॉडल [अनुवाद]

डीडीडी के मेरे उत्साही अध्ययन की पृष्ठभूमि के खिलाफ, मैंने 25 नवंबर 2003 को एनीमा डोमेन मॉडल मार्टिन मार्टिन द्वारा एक लेख पढ़ा। कभी-कभी, सामग्री की बेहतर समझ के लिए, मैं इसे रूसी में अनुवाद करता हूं। इसलिए मैंने अनुवाद को साझा करने का फैसला किया।

लेखक का अनुवाद और कुछ स्थानों पर बहुत शब्दार्थ।



मूल से लिंक करें।



लेख में पहले से प्रकाशित पुस्तक के उद्धरण हैं, जो पेशेवरों द्वारा रूसी में अनुवादित किए गए थे, मेरे अनुवाद की समझ में सुधार करने के लिए, मैंने पुस्तक के उद्धरणों को स्पॉइलर के तहत उद्धृत किया।

पेल डोमेन मॉडल



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







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



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



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



यह भी ध्यान देने योग्य है कि डोमेन ऑब्जेक्ट्स में व्यवहार का प्लेसमेंट, डोमेन लॉजिक को दृढ़ता और प्रस्तुति परत से अलग करने के लिए परतों का उपयोग करने के सुसंगत दृष्टिकोण का खंडन नहीं करना चाहिए। डोमेन ऑब्जेक्ट में जो लॉजिक होना चाहिए, वह डोमेन लॉजिक है, उदाहरण के लिए: सत्यापन, गणना या जिसे आप "व्यावसायिक नियम" कहते हैं।

(बेशक, ऐसे मामले होते हैं जब आप किसी डेटा स्रोत या प्रेजेंटेशन लॉजिक के टुकड़ों को किसी पैरामीटर ऑब्जेक्ट को किसी पैरामीटर के माध्यम से पास करते हैं, लेकिन यह "मेरे विचार" के लिए ऑर्थोगोनल है।)



गलत व्याख्या के स्रोतों में से एक यह है कि कई ऑब्जेक्ट-ओरिएंटेड विशेषज्ञ सर्विस लेयर बनाने के लिए डोमेन मॉडल के ऊपर एक प्रक्रियात्मक सेवाओं की परत रखने की सलाह देते हैं। लेकिन यह एक तर्क नहीं है कि व्यवहार को डोमेन मॉडल में न रखें, वास्तव में, सेवा परत व्यवहार के साथ डोमेन मॉडल के साथ संयोजन में इसके उपयोग को प्रोत्साहित करती है।



एरिक इवांस की उत्कृष्ट पुस्तक, डोमेन ड्रिवेन डिज़ाइन , इन परतों के बारे में निम्नलिखित कहती है।

एप्लीकेशन लेयर [जैसा कि वह सेवा लेयर को कॉल करता है]: उन कार्यों को परिभाषित करता है जो एप्लिकेशन को हल करने के लिए माना जाता है और उनके निष्पादन को (अमीर) डोमेन मॉडल को निर्देशित करता है। इस परत के कार्य व्यापार के लिए महत्वपूर्ण हैं (व्यावसायिक तर्क नहीं) या बस अन्य प्रणालियों के अनुप्रयोग स्तर के साथ बातचीत कर रहे हैं। यह परत पतली रहनी चाहिए। इसमें व्यावसायिक तर्क या कोई ज्ञान शामिल नहीं है, यह केवल निचले स्तर पर डोमेन ऑब्जेक्ट्स के सेट के लिए कार्यों को दर्शाता है और प्रतिनिधियों को काम करता है। यह एक ऐसा राज्य नहीं करता है जो व्यापार तर्क में स्थिति को प्रतिबिंबित करेगा, लेकिन यह उपयोगकर्ता को और / या एप्लिकेशन को समग्र रूप से सूचित करने के लिए कार्य की स्थिति के बारे में जान सकता है।

डोमेन लेयर (या मॉडल लेयर): व्यवसाय प्रक्रियाओं के अर्थ का प्रतिनिधित्व करने के लिए जिम्मेदार, व्यावसायिक स्थिति और व्यावसायिक नियमों (व्यावसायिक तर्क) के बारे में जानकारी प्रदान करता है। यहां, एप्लिकेशन (उसके व्यावसायिक भाग में) की स्थिति को दर्शाने वाले राज्य की निगरानी और उपयोग किया जाता है, यहां तक ​​कि डेटा भंडारण (दृढ़ता) के तकनीकी विवरणों को भी बुनियादी ढांचे के लिए सौंप दिया जाता है।

यह परत अनुप्रयोग का दिल है।

यहाँ मुद्दा यह है कि सर्विस लेयर पतला है , और सभी तर्क डोमेन लेयर में है। वह (एरिक) अपने सेवा टेम्पलेट में इसे दोहराता है ।

अब उचित वस्तु में व्यवहार रखने पर, प्रक्रियात्मक प्रोग्रामिंग में धीरे-धीरे खिसक जाना बहुत जल्द एक सामान्य गलती है।

मुझे नहीं पता कि यह विरोधी पैटर्न इतना आम क्यों है। मुझे इस तथ्य से संदेह है कि बहुत सारे लोग हैं, जिन्होंने सही डोमेन मॉडल के साथ काम नहीं किया, खासकर अगर वे डेटा की दुनिया से आए थे। कुछ प्रौद्योगिकियां इस एंटी-पैटर्न को प्रोत्साहित करती हैं, जैसे कि जे 2 ईई की एंटिटी बीन्स, यह एक कारण है कि मैं पीओजेपी डोमेन मॉडल क्यों पसंद करता हूं।



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

आपका ध्यान देने के लिए धन्यवाद।



मैं आमंत्रित करने का नाटक नहीं करता, क्योंकि मुझे इसकी आवश्यकता नहीं है। लेकिन अगर किसी को लगता है कि सामग्री एक निमंत्रण के लायक है, तो बस मुझे टिप्पणियों में बताएं, मुझे खुशी होगी।