डोमेन मॉडलिंग, डीडीडी

Question

में डोमेन ऑब्जेक्ट्स मैं वास्तव में डीडीडी के लिए नया हूं और कुछ अवधारणाओं को समझने की कोशिश कर रहा हूं।

क्या कोई मुझे डीडीडी में डोमेन मॉडलिंग के पीछे विचार समझा सकता है।

मैं पहले से ही विकिपीडिया स्पष्टीकरण के माध्यम से चला गया हूं: http://en.wikipedia.org/wiki/Domain_model लेकिन अभी भी लगता है कि मेरी समझ में कुछ भूरे रंग के क्षेत्र हैं।

मैं क्या समझ में आ के आधार पर, डोमेन मॉडलिंग उनके रिश्तों को व्यक्त करने के .. संस्थाओं है कि मॉडल आदि में भाग लेने का इजहार,

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

जो मुझे समझ में नहीं आता है वह डोमेन डोमेनिंग डीडीडी में हो जाता है। क्या यह वही वस्तु/वर्ग मॉडलिंग है जिसे आप ओओ दुनिया में पाते हैं, या यह डीडीडी के लिए कुछ नया है? ऑब्जेक्ट ओरिएंटेड डिज़ाइन/मॉडलिंग से यह अलग कैसे है?

आपके उत्तरों की अत्यधिक सराहना की जाती है।

Answer 1

एक भेद यह है कि डीडीडी में Domain Model Pattern का "उचित" कार्यान्वयन क्रॉस-कटिंग चिंताओं से अलग है।

उदाहरण के लिए, इसमें डेटाबेस या अन्य दृढ़ता से कोई लेना देना नहीं है। जहां इसमें सत्यापन तर्क शामिल है, यह व्यावसायिक सत्यापन है, न कि "क्या नाम कॉलम की लंबाई से अधिक है?" मान्यता।

विचार यह है कि डोमेन मॉडल व्यापारिक शर्तों ("सर्वव्यापी भाषा") में "व्यापार" को समाहित करता है - और यथासंभव "कार्यक्रम" के लिए व्यवसाय के प्रासंगिक पहलुओं को उजागर करता है सॉफ्टवेयर की जरूरत है।

फ्लिप पक्ष पर, "सॉफ़्टवेयर" आईओ, यूआई और इसी तरह से संबंधित है, लेकिन डोमेन मॉडल में सभी व्यावसायिक तर्क प्रस्तुत करता है।

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

Answer 2

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

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