क्या डोमेन ड्रिवेन डिज़ाइन में डोमेन ऑब्जेक्ट केवल लिखने के लिए ही माना जाता है?


13

मैं लगभग दो वर्षों से डोमेन ड्रिवेन डिज़ाइन के बारे में पढ़ रहा हूँ और सावधानी से अपने दैनिक कार्य में या कम से कम योजनाएँ बना रहा हूँ कि मैं नियमित रूप से डोमेन ड्रिवेन डिज़ाइन के भीतर किस तरह से काम कर सकता हूँ।

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

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

  1. एक ऑब्जेक्ट पर एक इकाई परीक्षण कैसे किया जाता है जिसमें बसने वाले या विधियां हैं जो किसी वस्तु की स्थिति को संशोधित करती हैं लेकिन जो राज्य को पढ़ने के लिए कोई बाहरी इंटरफ़ेस प्रदान नहीं करती हैं जैसे कि सी # में संपत्ति पाने वाले से? क्या उस वस्तु को परीक्षण योग्य बनाने के उद्देश्य से राज्य को पूरी तरह से उजागर करना ठीक है?
  2. किसी उपयोगकर्ता को डोमेन में किए गए गणना या संचालन के परिणाम उन्हें दिखाने के लिए बिना कैसे दिखाए जाते हैं और फिर डोमेन के संदर्भ के बाहर लगातार स्टोर से परिणाम खींचते हैं? क्या केवल परिणाम दिखाने के उद्देश्य से राज्य को उजागर करना ठीक है।

क्या अंगूठे का नियम है कि केवल संपत्ति पाने वाले (एक्सेसर्स प्राप्त करें) वही होने चाहिए जो डोमेन में भी लिखने योग्य हैं? या कहा जाए कि केवल पढ़ने के लिए अलग-अलग गुण होने चाहिए क्योंकि वे केवल पढ़ने के उद्देश्य से होते हैं और इस प्रकार वास्तविक डोमेन मॉडल में आवश्यक भूमिका नहीं निभाते हैं?

संबंधित सामग्री:

  1. टीडीडी, डीडीडी और एनकैप्सुलेशन

जवाबों:


9

सुनिश्चित नहीं है कि डिजाइन दृष्टिकोण के लिए एक 'एक सही तरीका' उत्तर है, जो उचित है, अभी भी विकसित हो रहा है। सबसे पहले, DDD और CQRS एक ही चीज नहीं हैं, हालांकि CQRS लोग एक DDD- प्रभावित शुरुआती बिंदु से निकले हैं।

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

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

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

यदि आप इस शैली के साथ प्रयोग करते हैं, तो संज्ञान लें कि अन्य प्रोग्रामर इस दृष्टिकोण से परिचित नहीं होने जा रहे हैं, और यह कि अपेक्षाकृत कम (लेकिन दिलचस्प) परिदृश्य हैं जहां यह डिजाइन दृष्टिकोण के रूप में उचित है।

इकाई परीक्षण के लिए, कुछ दृष्टिकोण हैं जो आपके लिए काम कर सकते हैं। पहला, और सबसे स्वाभाविक है, उन घटनाओं को सत्यापित करना जो आप उम्मीद करते हैं कि आपके डोमेन ऑब्जेक्ट द्वारा उठाए गए हैं। एक डोमेन ऑब्जेक्ट परिवर्तन के बारे में जानकारी रखने वाले एक सामान्य परिवर्तित घटना को बढ़ा सकता है। आप इसे सत्यापित कर सकते हैं। आप इस तथ्य को सत्यापित कर सकते हैं कि घटना को उठाया गया था, और अन्य घटनाओं को नहीं उठाया गया था।

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

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


1
Jucy बिट्स के साथ शुरू करने के लिए +1। इसके अलावा: सिर्फ CQS (अभी के लिए 'ईवेंट्स के हिस्से को छोड़ देना) को शुरू करने के लिए एक अच्छी जगह हो सकती है।
cottsak

1

क्या डोमेन ड्रिवेन डिज़ाइन में डोमेन ऑब्जेक्ट केवल लिखने के लिए ही माना जाता है?

नंबर CQRS DDD के साथ उपयोग किया जा सकता है।


लेकिन क्या CQRS का क्वेरी भाग उन सभी डेटा के बारे में है जो डोमेन मॉडल द्वारा मॉडल में परिवर्तन लिखने के लिए उपयोग किया जाता है या क्या इसका उपयोग अनुप्रयोग परत के लिए डेटा को क्वेरी करने के लिए किया जा सकता है जो उपयोगकर्ता को मान दिखा सकता है? मैं कुछ से सुन रहा हूं कि डीडीडी सभी परिवर्तनों के समन्वय के बारे में है और इसका उपयोग किसी अन्य उद्देश्य से पढ़ने के लिए नहीं किया जाना चाहिए, क्योंकि डोमेन मॉडल के भीतर किसी अन्य ऑब्जेक्ट में परिवर्तनों को समन्वयित करना है। निर्णय एक तरह से या दूसरे का अर्थ होगा कि मूल रूप से अलग-अलग मॉडल डिज़ाइन जो डोमेन ऑब्जेक्ट पर उजागर डेटा को देखते हुए भिन्न होगा यदि यह केवल डोमेन में खपत है।
जिपरसन

0

आपके डोमेन मॉडल यूनिट परीक्षणों की जाँच होनी चाहिए कि प्रत्येक कमांड निष्पादित के लिए सही डोमेन ईवेंट उठाए गए हैं। आपके डोमेन कमांड और कैप्चर की गई घटनाओं को राज्य के लिए पूछताछ की जा सकती है।

आप ToString()अपने डोमेन आदेशों और घटनाओं पर ओवरराइड कर सकते हैं ताकि राज्य की स्वचालित, मानव पठनीय रिपोर्टिंग प्रदान की जा सके।

अपने दूसरे प्रश्न का उत्तर देने के लिए, आदेशों के परिणामों को प्रदर्शित करने के लिए आपको डोमेन घटनाओं के लिए अपने रीड-मॉडल को 'प्रकाशित' करने की व्यवस्था करनी चाहिए।


क्या आप इस बात पर थोड़ा विस्तार कर सकते हैं कि क्या यह तब भी लागू होता है जब आप इवेंट-सोर्सिंग का उपयोग नहीं कर रहे हैं?
जिपरसन

1
इवेंट सोर्सिंग के बिना शायद मेरा सुझाव काम नहीं करेगा; मुझे आपके कोड के तरीके नहीं पता हैं। एक डोमेन ऑब्जेक्ट के लिए जो आदर्श रूप से किसी भी गुण को उजागर नहीं करता है, शायद आप स्पष्ट रूप से एक परीक्षण इंटरफ़ेस को लागू कर सकते हैं जो उन गुणों को उजागर करता है जिन्हें आप परीक्षण करना चाहते हैं। इस तरह के डोमेन ऑब्जेक्ट को टेस्ट इंटरफेस में डालने के लिए केवल आपका टेस्ट कोड 'पता' होगा।
एड जेम्स

उस सुझाव के लिए धन्यवाद। मैं विशेष रूप से परीक्षण क्षमता के लिए अपने डोमेन वर्गों को संशोधित करने के विचार के बारे में थोड़ा असहज महसूस करता हूं, लेकिन मुझे लगता है कि यह उन क्षेत्रों में से एक हो सकता है जो अभी भी डोमेन ड्रिवेन डिज़ाइन में हैं यदि आप इसे परीक्षण योग्य बनाना चाहते हैं। एक और विचार यह है कि यदि एक ही इंटरफ़ेस के माध्यम से स्थिरता और परीक्षणशीलता को उजागर करना था तो कम से कम आपके दो के बजाय केवल एक बुनियादी ढाँचे की निर्भरता का परिचय देना होगा। दूसरे क्या सोचते हैं?
जिपरसन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.