डीडीडी: क्या मुझे वास्तव में कुल मिलाकर सभी वस्तुओं को लोड करने की आवश्यकता है? (प्रदर्शन चिंताओं)

Question

डीडीडी में, एक भंडार एक संपूर्ण कुल लोड करता है - हम या तो इसे लोड करते हैं या इनमें से कोई भी नहीं। इसका मतलब यह भी है कि आलसी लोडिंग से बचना चाहिए।

मेरी चिंता प्रदर्शन-वार है। क्या होगा यदि यह हजारों ऑब्जेक्ट्स मेमोरी में लोड हो रहा है? उदाहरण के लिए, Customer के लिए कुल दस हजार Orders के साथ आता है।

इस तरह के मामलों में, क्या इसका मतलब यह हो सकता है कि मुझे अपने समेकन को फिर से डिजाइन और फिर से सोचने की आवश्यकता है? क्या डीडीडी इस मुद्दे के बारे में सुझाव देता है?

Answer 1

वर्नॉन से तीन लेखों की इस Effective Aggregate Design श्रृंखला पर एक नज़र डालें। मैंने उन्हें समझने में काफी उपयोगी पाया कि आप कब और कैसे बड़े समूह के बजाय छोटे समेकन को डिज़ाइन कर सकते हैं।

संपादित

मैं कुछ उदाहरणों की मेरे पिछले जवाब में सुधार करने, उनके बारे में अपने विचार साझा करने के लिए स्वतंत्र महसूस देने के लिए करना चाहते हैं।

सबसे पहले, एक सकल बारे में एक त्वरित परिभाषा (पैटर्न से ले लिया है, सिद्धांतों और डोमेन के आचरण स्कॉट बाजरा से प्रेरित डिजाइन पुस्तक)

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

अभ्यास में परिभाषा को देखने के लिए उदाहरण के साथ चलते हैं।

सरल उदाहरण

पहले उदाहरण दिखाता है कि परिभाषित करने एक सकल रूट स्थिरता सुनिश्चित करने के लिए जब डोमेन वस्तुओं के खिलाफ कार्रवाई प्रदर्शन में मदद करता है।

अगले व्यापार नियम को देखते हुए:

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

यहां नीलामी और बोलियां शामिल हैं जहां नीलामी कुल रूट है।

var newBid = new Bid(money); 
BidsRepository->save(auctionId, newBid); 

और तुम परिभाषित व्यापार नियम गुजर बिना एक बोली बचत गया:

तो हम कहते हैं कि बोली भी एक अलग सकल रूट आप के लिए होता है एक है, और आप आसानी से कर सकता है। हालांकि, केवल सकल रूट आप अपने डिजाइन को लागू कर रहे हैं, क्योंकि आप की तरह कुछ करने की ज़रूरत है के रूप में नीलामी होने:

var newBid = new Bid(money); 
auction.placeBid(newBid); 
auctionRepository.save(auction); 

इसलिए, आप विधि placeBid के भीतर अपने अपरिवर्तनीय जांच कर सकते हैं और कोई भी इसे छोड़ अगर वे करना चाहते हैं कर सकते हैं एक नई बोली रखें।

यहां यह स्पष्ट है कि बोली की स्थिति नीलामी की स्थिति पर निर्भर करती है।

परिसर उदाहरण

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

लेकिन, का कहना है कि अब व्यापार अगले अपरिवर्तनीय परिभाषित करता है:

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

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

समाधान? अंतिम संगति। क्या होगा यदि हम ग्राहक को उत्पाद खरीदने की अनुमति दें? जो है, आदेश के लिए एक समेकित रूट होने तो हम आदेश बनाने और सहेजने:

var newOrder = new Order(customerId, ...); 
orderRepository.save(newOrder); 

हम जब आदेश बनाई गई है एक घटना प्रकाशित और फिर हम अतुल्यकालिक रूप से जाँच करता है, तो ग्राहक पर्याप्त धनराशि है:

class OrderWasCreatedListener: 
    var customer = customerRepository.findOfId(event.customerId); 
    var order = orderRepository.findOfId(event.orderId); 
    customer.placeOrder(order); //Check business rules 
    customerRepository.save(customer); 

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

ध्यान रखें कि यूआई हमें पर्याप्त पैसे के बिना भुगतान करने से बचने में मदद कर सकता है, लेकिन हम यूआई पर अंधे से भरोसा नहीं कर सकते हैं।

तुम दोनों उदाहरण उपयोगी पाते हैं, और यदि आप संपर्क में परिदृश्यों के लिए बेहतर समाधान खोज :-)

Answer 2

इस तरह के मामलों में, क्या इसका मतलब यह हो सकता है कि मुझे अपने समेकन को फिर से डिजाइन और फिर से सोचने की आवश्यकता है?

लगभग निश्चित रूप से।

कुल डिजाइन के लिए ड्राइवर संरचना नहीं है, बल्कि व्यवहार है। हमें परवाह नहीं है कि "उपयोगकर्ता के पास हजारों ऑर्डर हैं"। जब हम किसी बदलाव को संसाधित करने का प्रयास करते हैं तो राज्य के किस टुकड़े की जांच की जानी चाहिए - परिवर्तन जानने के लिए आपको क्या डेटा लोड करने की आवश्यकता है।

आमतौर पर, आपको एहसास हो जाएगा कि एक आदेश बदलना (या नहीं) प्रणाली में अन्य आदेशों की स्थिति पर निर्भर करता है, जो एक अच्छा संकेत है कि दो अलग-अलग आदेशों का हिस्सा नहीं होना चाहिए वही कुल