हाय, हैब्र।आज मैं
स्लैक में रूसी-भाषा के
GoCommunity में #school चैनल पर गया और
वहाँ एक दिलचस्प संवाद पाया। इस संवाद ने मुझे कुछ विचारों के बारे में बताया कि कैसे मेरे सहयोगी
"डोमेन मॉडल" की अवधारणा की व्याख्या करते हैं।
जैसा कि यह निकला, काफी गलत हैं या बिल्कुल सटीक नहीं हैं, और कभी-कभी इस शब्द की पूरी तरह से गलत व्याख्याएं हैं, जो अनिवार्य रूप से इसे विकृत करती हैं। इस संवाद के आसपास, इस लेख का विचार पैदा हुआ था। कट के तहत विवरण।
वास्तुकला के बारे में प्रश्न।
इसलिए, डेवलपर ने समुदाय में निम्नलिखित प्रश्न पूछा:
मुझे बताएं कि वास्तुकला को सही तरीके से कैसे किया जाए, मान लें कि मैंने डेटाबेस में एक टैबलेट बनाया है, मेरे लिए एक मॉडल बनाने के लिए सुधारों को कहा है, क्या मैं इस मॉडल का उपयोग अपने आवेदन में एक डोमेन मॉडल के रूप में कर सकता हूं, या क्या यह बेहतर है कि मैं अपना डोमेन मॉडल बनाऊं और एक एडाप्टर बनाऊं जो मुझे वास्तव में मेरा डोमेन मॉडल देगा। इसे एक सुधार मॉडल से बना रहे हैं? "
जिसके लिए एक अन्य प्रोग्रामर ने निम्नलिखित उत्तर दिया:
एनीमिक मॉडल के साथ सबसे सरल वास्तुकला है। यह तब है जब DB मॉडल = डोमेन मॉडल = एपीआई प्रतिक्रिया मॉडल। अमीर डोमेन मॉडल एक दुर्लभ जानवर है और आम तौर पर एनीमिक में पतित होता है। एनीमिक का मतलब डीटीओ संरचना है। तरीकों के बिना विशेषताओं (क्षेत्रों) का सामान्य सेट। तर्क ऐसे कार्यों के एक समूह में पतित हो जाता है जो इस तरह के dto पर काम करते हैं। फाउलर कई बार इस तरह के आर्किटेक्चर को एंटीपैटर्न मानते हैं। लेकिन फिर एक अच्छा microservice समाधान, आदि।
इसे पढ़ने के बाद, मुझे अचानक एहसास हुआ कि व्यावसायिक तर्क परत के संगठन को लेकर इतना विवाद क्यों है, और क्यों कई लोग इस तरह के दृष्टिकोण जैसे कि
स्वच्छ वास्तुकला , आदि को अमल में लाने में विफल रहते हैं।
"एनीमिक मॉडल के साथ वास्तुकला" का क्या अर्थ है?
यदि आप नेटवर्क पर इस तरह की अवधारणा को खोजने की कोशिश करते हैं, तो आप सबसे अधिक संभावना यह नहीं पाएंगे, क्योंकि ऐसी कोई वास्तुकला नहीं है।
"AnemicDomainModel" की अवधारणा है, और अगर हम एक ही Fowler की ओर मुड़ते हैं, तो यह पता चलता है कि यह सिर्फ एक
एप्लीकेशन आर्किटेक्चर (हेलो फोरट्रान, ALGOL, COBOL, BASIC, पास्कल और C)
बनाने के लिए एक
प्रक्रियात्मक दृष्टिकोण है । यह, संक्षेप में, उत्तर के लेखक को
"एनीमिक मॉडल के साथ वास्तुकला" कहा जाता है ।
डोमेन मॉडल।
अगला, अगला सवाल उठता है: क्या
"एनीमिक मॉडल" अनिवार्य रूप से एक मॉडल है? मुझे नहीं लगता, और इसीलिए।
सच्चाई यह है कि डोमेन मॉडल
"डीबी मॉडल" या
"एपीआई प्रतिक्रिया मॉडल" के विपरीत डेटा मॉडल नहीं है। डोमेन मॉडल
की एक बहुत विशिष्ट परिभाषा है । इसके अलावा, डेटाबेस मॉडल के साथ हस्तक्षेप करना गलत है, जो अनिवार्य रूप से एक
डेटा मॉडल है ।
जब यह डोमेन मॉडल की बात आती है, तो यह ठीक वैचारिक मॉडल है। और यह विषय क्षेत्र की अवधारणाओं और उनके बीच संबंधों (यानी, व्यवहार और डेटा की समग्रता) की समग्रता है। सामान्य तौर पर, मुख्य विशेषता जो एक विषय क्षेत्र के एक मॉडल को दूसरे से अलग करती है, ठीक व्यावसायिक नियमों का एक सेट है।
हां, वैचारिक मॉडल अलग-अलग रूपों (डेटाबेस या एपीआई प्रतिक्रियाओं से डेटा) में प्रस्तुत किए गए डेटा के साथ काम कर सकता है, लेकिन इसका सार नहीं बदलेगा,
व्यवहार सर्वोपरि है । हम एक विशिष्ट आउटपुट प्राप्त करने के लिए मॉडल में इनपुट पास करते हैं। यह परिणाम मॉडल के भीतर व्यावसायिक तर्क को लागू करने (दूसरे शब्दों में, व्यावसायिक नियमों को लागू करने) द्वारा प्राप्त किया जाता है। मैं यहां गणितीय मॉडल और तकनीकी प्रक्रियाओं (हैलो छात्र वर्षों) के मॉडलिंग के साथ एक समानता का पता लगाता हूं।
अवधारणाओं के प्रतिस्थापन के साथ क्या होता है?
जब आप डेटा संरचनाओं को
"डोमेन मॉडल" कहते हैं , तो आप अवधारणाओं को बदलने के लिए स्वतंत्र हैं या नहीं। यह इस तथ्य की ओर जाता है कि अक्सर व्यावसायिक तर्क पूरे अनुप्रयोग में फैलता है। वास्तव में, इस मामले में विषय क्षेत्र का मॉडल डेटा संरचनाओं के साथ काम करने वाले कार्यों का बहुत ही स्मीयर सेट है।
मध्यम और बड़े अनुप्रयोगों के विकास के मामले में, इन अवधारणाओं की गलतफहमी या मिश्रण, एक नियम के रूप में, सिस्टम के विकास की शुरुआत में कई समस्याओं और प्रश्नों की ओर जाता है, न कि दीर्घकालिक समर्थन का उल्लेख करने के लिए। उनमें से, उदाहरण के लिए, ऐसे सामान्य प्रश्न हैं:
- "- डेटा को कहां मान्य किया जाए?"
- "- चक्रीय निर्भरता से कैसे बचें?"
- "-" यह "सामान्य रूप से व्यावसायिक तर्क है?"
- "- और हम व्यावसायिक तर्क कहाँ रखते हैं?"
- आदि
इसके अलावा, यदि आपके पास एक साधारण सीआरयूडी है, अर्थात्। अनिवार्य रूप से डेटाबेस के लिए एक इंटरफ़ेस, सबसे अधिक संभावना है कि कोई समस्या नहीं होगी। यदि आप एक बुनियादी ढाँचा-स्तरीय पुस्तकालय (उदाहरण के लिए, किसी नेटवर्क या समान डेटाबेस के साथ काम करने के लिए) लिख रहे हैं, तो कोई समस्या नहीं होनी चाहिए। ऐसा इसलिए है क्योंकि एक RFC है और सभी "व्यावसायिक नियम" लंबे समय से स्पष्ट हैं, और तर्क लंबे समय से स्पष्ट हैं। आप एक सरल प्रक्रियात्मक कार्यक्रम लिख सकते हैं, और वैसे भी सबकुछ ठीक हो जाएगा।
यदि हम इस तथ्य पर वापस लौटते हैं कि डोमेन मॉडल के बारे में संवाद गो समुदाय में उत्पन्न हुआ, तो मैं ऐसा कहूंगा। इस तथ्य के कारण कि गो एक बहु-प्रतिमान भाषा है और कई सफल ओओपी अवधारणाओं (रचना, इंटरफेस) का समर्थन करता है, जब डोमेन को मॉडलिंग करते समय उन्हें अनदेखा न करें और एक प्रक्रियात्मक शैली में विशेष रूप से कोड लिखें, जैसे कि आप बेसिक या सी के साथ काम कर रहे हैं।
सही ढंग से "डोमेन मॉडल" की अवधारणा की व्याख्या करते हुए, यह काफी स्पष्ट हो जाता है कि क्यों अक्सर व्यापार तर्क को एक अलग परत में अलग करने के लिए प्रथागत है। यह भी स्पष्ट हो जाता है कि आप इस समान परत का चयन कैसे कर सकते हैं और क्लीन आर्किटेक्चर या इसके किसी अन्य रूपांतर को लागू कर सकते हैं। एक अलग परत को अलग करके, हम अनिवार्य रूप से एक पुस्तकालय बनाते हैं जो प्रोग्राम कोड के रूप में वैचारिक मॉडल को लागू करता है। नतीजतन, व्यावसायिक तर्क इस पुस्तकालय के ढांचे के भीतर संकुचित हो जाता है, और पूरे आवेदन में नहीं फैलता है (एक शुद्ध प्रक्रियात्मक दृष्टिकोण के साथ)।
बेशक, इन अवधारणाओं को समझना आपको डिज़ाइन गलतियों से नहीं बचाएगा, आपको एक आदर्श डेवलपर या सिस्टम आर्किटेक्ट नहीं बनाएगा, और आपको पहली बार सब कुछ सही करने के लिए नहीं सिखाएगा। यहां, न केवल सिद्धांत महत्वपूर्ण है, बल्कि अभ्यास भी है। फिर भी, जैसे ही आप अवधारणाओं को सही ढंग से समझते हैं और परिभाषाओं की व्याख्या करते हैं, कई चीजें आपके लिए बहुत अधिक स्पष्ट और सरल हो जाएंगी।
संक्षेप में देना।
- "डेटा" को एक डोमेन मॉडल कहना सही नहीं है।
- एक डोमेन मॉडल एक वैचारिक मॉडल है जिसमें व्यवहार और डेटा दोनों शामिल होते हैं। इसे एक अलग परत में समझाया जा सकता है, या इसे पूरे एप्लिकेशन में फैलाया जा सकता है।
- "एनीमिक मॉडल के साथ आर्किटेक्चर" एक एप्लिकेशन आर्किटेक्चर बनाने के लिए एक प्रक्रियात्मक दृष्टिकोण से अधिक कुछ नहीं है जिसमें डोमेन मॉडल पूरे एप्लिकेशन में है
परिभाषाओं पर ध्यान दें, उन्हें तिरछे पढ़ने की तुलना में गहराई से अध्ययन करें। बहुत बार हम आलसी होते हैं और टुकड़ों में जानकारी हासिल करते हैं, जिसके बाद विकृति निश्चित रूप से होती है। वापस आना न भूलें और उन चीजों को याद रखें जो आपको लंबे समय तक स्पष्ट लगती हैं, और हमेशा स्रोतों का उल्लेख करें और कुदाल को कुदाल कहें।
सभी को अच्छा! आपका ध्यान के लिए धन्यवाद।
पुनश्च। मुझे रचनात्मक आलोचना सुनने के साथ-साथ "डोमेन मॉडल" क्या है, के बारे में आपकी दृष्टि भी खुशी होगी। स्रोत के संदर्भ में स्वागत है।
UPD: लेख "डोमेन मॉडल" की अवधारणा की स्वतंत्र रूप से व्याख्या करने और इस अवधारणा को एक अर्थ में रखने का प्रयास नहीं है जिसका मुझे पता है। मैं इसे व्यक्त करना चाहता हूं: इस अवधारणा में अर्थ लंबे समय से निवेश किया गया है, और यह कंप्यूटरसाइंस पर पुस्तकों और लेखों में विस्तार से वर्णित है। लेख उनके अर्थों को विकृत किए बिना इन बहुत अवधारणाओं की सही धारणा के महत्व पर सहयोगियों को व्यक्त करने का एक प्रयास है (यह महत्वपूर्ण है क्योंकि व्यवहार में यह आपको अधिक सार्थक कोड लिखने की अनुमति देगा)।
UPD2: मैं एंटरप्राइज थ्योरी नहीं आर्किटेक्ट हूं। आप जैसे हैं वैसे ही प्रैक्टिसिंग डेवलपर हैं। मैं हर दिन कोड लिखता हूं और अपने कोड को बेहतर बनाने के लिए और ग्राहकों को खुश करने के लिए इन चीजों के बारे में बात करता हूं। यदि, आपकी राय में, मैंने मूल अर्थ को विकृत कर दिया है, तो स्रोत से लिंक साझा करें और इंगित करें कि मैंने इसे गलत तरीके से कहां रखा है, ताकि मैं इसे ठीक कर सकूं।
UPD3: क्योंकि कई शब्द "विषय क्षेत्र" की विभिन्न तरीकों से व्याख्या करते हैं, मैं विषय क्षेत्रों के कुछ उदाहरण देता हूं ताकि अवधारणाओं का कोई भ्रम और प्रतिस्थापन न हो। विषय क्षेत्र हमेशा इस बात पर निर्भर करता है कि आप अनुप्रयोग विकास का उपयोग करके किस समस्या का समाधान करते हैं:
- टिकट बुक करना (यदि आप आरक्षण प्रणाली के डेवलपर हैं)
- बैंकिंग (यदि आप बैंकिंग एप्लिकेशन के डेवलपर हैं)
- ऑपरेटिंग सिस्टम (यदि आप डेवलपर OS डेवलपर हैं)
- क्लाउड इंफ्रास्ट्रक्चर मैनेजमेंट (यदि आप k8s डेवलपर हैं)
- वर्चुअलाइजेशन (यदि आप एक डॉक डेवलपर हैं)
- प्रदर्शन की निगरानी (यदि आप एक प्रोमेथियस / ग्राफाना डेवलपर हैं)