क्या रिपोजिटरी निर्माण के दौरान एक-दूसरे से बात करते हैं तो क्या यह किसी भी डोमेन संचालित डिज़ाइन प्रिंसिपल का उल्लंघन करता है?डोमेन संचालित डिज़ाइन, रिपॉजिटरीज और मिश्रित इकाइयां
उदाहरण के लिए उपयोगकर्ता पता भंडार शहर/क्षेत्र/देश भंडारों से डेटा प्राप्त करने के लिए बातचीत करता है?
यह डोमेन संचालित डिजाइन का उल्लंघन करता है, मुझे लगता है कि भंडार एक दूसरे के संदर्भ में नहीं होना चाहिए। साथ ही, आपको डेटाबेस तालिका के साथ भंडार के बीच 1: 1 मैप नहीं करना चाहिए।
यह Aggregate और AggregateRoot की अवधारणा है।
Order
OrderLine
संबंध 1 के साथ: एन, (आदेश, ऑर्डर लाइन) एक समग्र रूप में परिभाषित किया गया है क्योंकि ऑर्डर लाइन अकेले आदेश बिना नहीं रह सकता उदाहरण के लिए, डेटाबेस में मान 2 टेबल है। और इस मामले में, आदेश इस कुल की जड़ है।
इस के साथ, बजाय दो डेटा संग्रह स्थान बनाने की:
OrderRepository
OrderLineRepository
तुम बस केवल एक OrderRepository पूरे कुल का ख्याल रखना चाहिए, व्यापक लोड का उपयोग कर, डालें और OrderLine
तो में साथ हटाना आपके मामले में, इस बात पर विचार करना चाहिए कि क्या आपके पास पता/शहर/क्षेत्र/देश भंडार मौजूद हैं या नहीं।
आशा इस मदद
हम आईएसओ मुद्राओं और हमारी प्रणाली में आईएसओ देशों के साथ एक ही मुद्दा बारे में जाना। हमने पाया कि हमारे पास लगभग कुल योग था (और इसके लिए एक समान भंडार है) एक उप इकाई के रूप में आवश्यक मुद्रा और/या देश की संस्थाएं। (ऊपर चुओंग Le के जवाब की तरह)
पुनः प्राप्त करने के अपने अनुभव DDD से उपयोग करें और नीले रंग पुस्तक एक अमूल्य गाइड है, लेकिन आप न इसे अपनाने के लिए है 100% सटीक रूप से, आप बोर्ड पर सिफारिशें लेते हैं लेकिन फिर आप इसे समझने के लिए अनुकूलित करते हैं तुम्हारे लिए।
आशा इस मदद करता है ...
आपके समस्या के कई तरीके हैं:
2 कुल जड़ों के बीच एक तंग संबंध रखें और व्यवस्थित ढंग से दूसरे रूट के पूरे कुल हाइड्रेट जब आप हाइड्रेट पहली जड़ इसके लिए पहली रिपोजिटरी दूसरी बात की बात करती है, जो आईएमओ किसी भी डीडीडी सिद्धांत को तोड़ता नहीं है लेकिन संभावित रूप से समस्याग्रस्त प्रदर्शन के रूप में हो सकता है।
2 जड़ों को एक साथ ढीले से लिंक करें। इसका मूल रूप से पूर्ण उदाहरण के बजाय संदर्भित रूट की आईडी को इंगित करना है। या तो क्लाइंट कोड या रूट स्वयं (हालांकि कुछ कहेंगे कि उत्तरार्द्ध खराब अभ्यास है) फिर संदर्भित रूट को इसके आईडी से अपने आईडी से रीहाइड्रेट करेगा।
यह समझें कि शहर, क्षेत्र या देश जैसे वस्तुएं वास्तव में (अपरिवर्तनीय) मूल्य वस्तुएं हैं, किसी आईडी की आवश्यकता नहीं है और बिना किसी परिणाम के किसी भी समग्र रूट या इकाई द्वारा सीधे संदर्भित किया जा सकता है। इसका मतलब इन वस्तुओं के लिए कोई भंडार नहीं है।
विकल्प 1 और 2 के बीच चयन केवल एक तकनीकी प्रश्न है और केवल प्रदर्शन और डेवलपर सुविधा को प्रभावित करेगा। विकल्प 3 संभावित व्यावसायिक प्रभावों के साथ एक डोमेन विकल्प का अधिक है। क्या शहर, क्षेत्र और देश बड़ी डोमेन इकाइयां हैं जो उपयोगकर्ता बनाने, संशोधित करने और हटाने में सक्षम होंगे? क्या उन लोगों को समर्पित विशेष स्क्रीन हैं? ये निर्णय हैं जो निर्णय लेने से पहले आपको अपने डोमेन विशेषज्ञ से चर्चा करने की आवश्यकता है।
लिंक उपयोगी हो सकते:
Aggregate Root references other aggregate roots
http://tech.groups.yahoo.com/group/domaindrivendesign/message/8696
खैर। डीडीडी में भंडारों का पूरा उद्देश्य डेटा स्रोत को दूर करना है। यदि आप उपयोगकर्ता पते को पूरा करने के लिए शहर/क्षेत्र/देश की आवश्यकता है तो उन भंडारों का उपयोग करें।
उस दृष्टिकोण के साथ समस्या यह है कि प्रश्न बदले में अक्षम होंगे।
इसके बजाय, डेटाबेस में एक दृश्य बनाएं जो सभी आवश्यक जानकारी के साथ उपयोगकर्ता पता लोड करता है (या यदि आपके पास है तो अपने ओआरएम का उपयोग करें)।
संक्षेप में:
DDD में कुछ भी नहीं तय है कि कैसे आप अपने खजाने को लागू करना चाहिए नहीं है। DDD उस पर बहुत स्पष्ट है इकाई रिपोजिटरी से भरी हुई पूरा होना चाहिए, चाहे कितना जानकारी डेटा स्रोत में संग्रहीत किया जाता = भंडार सिर्फ एक अमूर्त परत
के रूप में परिभाषित किया गया है यह करता है जिस तरह से मदद के लिए छोड़कर मेरे सिस्टम में कुछ चीजें हो रही हैं। हमने प्रांतों/राज्यों और देशों को आदर्शीकृत किया है। तो यदि उपयोगकर्ता या स्टोर को इसका पता डेटा लोड करना होगा और उस क्षेत्र के संदर्भ हैं जो क्षेत्र/देश भंडार का उपयोग करेंगे। क्या इस संदर्भ में क्षेत्रों/देशों के विभिन्न संस्करणों को लोड करना ठीक है, मैं उन्हें अधिक से अधिक वस्तुओं की तुलना में मूल्य वस्तुओं के रूप में उपयोग करूँगा? –
इस सरल स्पष्टीकरण के लिए धन्यवाद। अंत में प्रकाश बल्ब मेरे लिए आया था। :) – kman