डोमेन-संचालित डिज़ाइन में, क्या आप अपने यूआई में अपनी डोमेन इकाइयों का उपयोग कर सकते हैं?

Question

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

लेकिन मुझे क्या यकीन नहीं है, यह है कि क्या यह डीडीडी का सख्त सिद्धांत है, या यह कि यह सिर्फ अलग डेवलपर्स की व्याख्या है।

क्या आप सीधे यूआई में अपने डोमेन ऑब्जेक्ट्स का उपयोग कर सकते हैं, और फिर भी उस अधिनियम में डीडीडी पद्धति का पालन कर रहे हैं?

या क्या यह हमेशा प्रदर्शन वस्तुओं का उपयोग करने के लिए एक डीडीडी सर्वोत्तम अभ्यास है?

नोट: जबकि मैं एमवीसी का उल्लेख करता हूं, मुझे वास्तव में दिलचस्पी है कि डिस्प्ले ऑब्जेक्ट्स को डीडीडी प्रोजेक्ट में लगभग सभी डीडीडी संगत यूआई पैटर्न में इस्तेमाल किया जाना चाहिए या नहीं।

Answer 1

डीडीडी डोमेन को मॉडलिंग के साथ शुरू होने वाले सॉफ़्टवेयर को डिजाइन करते समय सोचने का एक तरीका है। webpage के रूप में कहते हैं:

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

एक चीज जो स्वाभाविक रूप से इस डिजाइन पैटर्न से बाहर होती है वह एक स्तरित वास्तुकला है। यह परतों में में DDD Pattern Summaries

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

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

Answer 2

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

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

Answer 3

एक एमवीसी डिज़ाइन के भीतर आप आमतौर पर रिपोजिटरी -> डोमेन मॉडल से मैपिंग करेंगे और फिर डोमेन मॉडल से -> मॉडल देखें। दृश्य मॉडल में अक्सर डोमेन ऑब्जेक्ट होते हैं।

Answer 4

जवाब काफी सीधे है:

• डोमेन वस्तुओं डोमेन उन्मुख डिजाइन और तरीकों की है।
• दृश्य ऑब्जेक्ट्स उन्मुख डिजाइन और विधियों को देख/नियंत्रित करते हैं।

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

Answer 5

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

वे Command and Query Responsibility Segregation (सीक्यूआरएस) के नाम से जाना जाने वाला सिद्धांत पढ़ रहे हैं।

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

डीडीडी शर्तों में, आप कह सकते हैं कि डोमेन मॉडल और प्रेजेंटेशन मॉडल आमतौर पर अलग-अलग बाउंड संदर्भों में होते हैं।

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

यदि आपका सिस्टम बस CRUD है और कोई व्यवहार है, बाहर एक मचान प्रणाली है कि स्वचालित रूप से आपके डेटाबेस स्कीमा के बंद बनाया जा सकता है, ASP.NET गतिशील डेटा की तरह

Answer 6

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