2012-07-19 8 views
18

मैंने पाया कि डीडीडी प्राकृतिक है यदि मैं एक परिचालन/लेनदेन प्रकार के आवेदन पर काम कर रहा हूं। हालांकि मैं हमेशा रिपोर्टिंग प्रकार के कार्यों को संभालने के लिए एक उचित तरीके से अटक गया हूं।डोमेन संचालित डिज़ाइन हैंडल रिपोर्टिंग कैसे करता है?

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

इस तरह के कार्यों के लिए, यह काफी स्वाभाविक है अगर हम एसक्यूएल (या जो भी क्वेरी भाषा) में शामिल होने के प्रदर्शन कर सकते हैं, स्तंभों हम रुचि रखते हैं मिलता है, और मालिश परिणाम सेट वापस जाएँ। हालांकि, ऐसा लगता है कि डीडीडी के साथ यह अच्छी तरह से नहीं जा रहा है: हमें एक अतिरिक्त विशेष भंडार की आवश्यकता है या मौजूदा "इकाई/मूल्य वस्तु" (जो विशेष परिणाम है) लौटने वाले मौजूदा से संबंधित भंडार की आवश्यकता है। इस तरह की विशेष "संस्थाओं" में वास्तव में कोई डोमेन अर्थ नहीं है।

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

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

मैंने सोचा कि ऐसी स्थिति काफी आम है (आमतौर पर एक बड़ी प्रणाली में परिचालन नहीं होता है बल्कि रिपोर्टिंग और पूछताछ के कार्यों भी शामिल होते हैं), मैं जानना चाहता हूं कि लोग इससे कैसे निपट रहे हैं?

उत्तर

2

हमने हाल ही में सिस्टम विकास के लिए डीडीडी का उपयोग करने में प्रवेश किया है। मुझे आपकी ही चिंताएं थीं लेकिन अंत में कमांड क्वेरी जिम्मेदारी पृथक्करण (सीक्यूआरएस) [फाउलर, यंग, ​​दहन] के लिए बस गईं। हालांकि इसे पूछताछ के लिए "डीबी पथ" की आवश्यकता है, मुझे ऐसा नहीं लगता कि यह कमांड के लिए डीबी को सीधे करने के लिए मोहक हो जाता है (जो डोमेन स्थिति को बदलते हैं)। अलगाव बहुत स्पष्ट है - आदेश डोमेन के माध्यम से जाते हैं, क्वेरीज सीधे डीबी पर जाते हैं।

+0

ईमानदारी से यह तय करना मुश्किल है कि कौन सा सही है लेकिन सीक्यूआरएस का उपयोग करना सबसे उचित लगता है (और यह डोमेनड्रिंडेंडिग.org से भी सबसे विश्वसनीय प्रतिक्रिया है) –

1

एक दृष्टिकोण एक अलग रिपोर्टिंग प्रणाली जो भाग गया डेटा आपके ऐप का डेटा की दुकान से खिलाती एक और अधिक रिलेशनल प्रारूप में डेटा का एक और प्रतिलिपि संग्रहीत करने के लिए किया जाएगा।

एक शॉर्टकट मैं का उपयोग किया है एक दृश्य या संग्रहीत प्रक्रिया एक सरल गूंगा वस्तु में शामिल हो गए डेटा लौटाने के लिए तैयार करना है।

+0

वास्तव में आपके द्वारा किए गए दो सुझावों को मैंने अपने मूल प्रश्न में सुझाया है। मेरी चिंताओं को हल करने के लिए मैं कुछ स्पष्टीकरण या तर्क चाहता हूं। और, फिर से जोर देने के लिए, "रिपोर्टिंग" जिस पर मैं बात कर रहा हूं, वह "रिपोर्ट" होने के लिए जरूरी नहीं है, बल्कि कुछ पूछताछ कार्यों को भी परिचालन कार्यों के साथ बारीकी से उपयोग किया जाता है। –

0

अपेक्षाकृत जटिल प्रश्नों। (जैसे, किसी व्यापारी द्वारा किए गए सभी ऑर्डर का सारांश देना, या कुछ स्टॉक वाले ट्रेडिंग खातों के लिए खाता सारांश प्रदर्शित करना)

ऐसे कार्यों को करने के लिए भंडारों के लिए यह आम बात है। मुझे लगता है कि आप इस कुशलता से कार्यान्वित करने के बारे में चिंतित हैं, और इसका उत्तर "आलसी लोडिंग" है।

उदाहरण के लिए, "सभी आदेशों कि एक व्यापारी किया सारांश" लेते हैं। "सारांश" एक रिपोर्टिंग कार्य है, तो चलो इसे एक तरफ रखें। डोमेन कार्य "व्यापारी के लिए सभी ऑर्डर ढूंढें" है। आपके पास इस तरह की एक रिपोजिटरी विधि हो सकती है:

List<Order> findOrdersByTrader(Trader trader); 

आप प्रत्येक आदेश के लिए केवल न्यूनतम (सारांश) जानकारी लोड करके इसे कार्यान्वित कर सकते हैं। यदि आप Order इकाई में रिपोजिटरी इंटरफ़ेस को इंजेक्ट करते हैं, तो इकाई स्वयं को अतिरिक्त उप-इकाइयों को लोड करने के लिए रिपोजिटरी पर कॉल कर सकती है।


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

+1

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

+0

@AdrianShum: मेरा अपडेट देखें। – casablanca

18

ज्यादातर मामलों में डीडीडी रिपोर्टिंग के मामले में एक अलग बोल्ड संदर्भ और एक सहायक सबडोमेन है जहां डोमेन संचालित डिजाइन अधिक हो जाएगा। डीडीडी की सबसे महत्वपूर्ण अवधारणा को याद रखें: कोर डोमेन पर अपने मॉडलिंग प्रयासों पर ध्यान केंद्रित करें और सबसे आसान संभव समाधान का उपयोग करके अन्य सभी को लागू करें।