आप डीडीडी में समेकन के बीच संबंधों को कैसे संभालेंगे?

Question

मैं अभी भी डीडीडी के चारों ओर अपने सिर को लपेट रहा हूं, और मेरे सामने आने वाले ठोकरों में से एक यह है कि अलग-अलग योगों के बीच संबंधों को कैसे संभाला जाए। मान लें कि मेरे पास एक कुल encapsulating ग्राहक और एक और encapsulating शिपमेंट्स मिल गया है।

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

मैं 'रिलेशनशिप' के बजाय 'एसोसिएशन' कह रहा हूं क्योंकि मैं तनाव देना चाहता हूं कि यह एक डोमेन निर्णय है, बुनियादी ढांचा नहीं - मैं पहले मॉडल से सिस्टम को डिजाइन कर रहा हूं।

संपादित करें: मुझे पता है कि मुझे वस्तुओं को सीधे टेबल पर मॉडल करने की आवश्यकता नहीं है - यही कारण है कि मैं पहले मॉडल को डिजाइन कर रहा हूं। इस बिंदु पर मुझे डेटाबेस की परवाह नहीं है - केवल इन दो योगों के बीच संबंध।

Answer 1

कोई कारण नहीं है कि आपके शिपमेंट रिपॉजिटरी आपके शिपमेंट मॉडल में ग्राहक डेटा एकत्र नहीं कर सकता है। रेपॉजिटरीज़ को टेबल के साथ 1-से-1 मैपिंग नहीं होना चाहिए।

मेरे पास कई रिपॉजिटरीज हैं जो एकाधिक तालिकाओं को एक एकल डोमेन मॉडल में जोड़ती हैं।

Answer 2

मुझे लगता है कि इस प्रश्न का उत्तर देने के दो स्तर हैं। एक स्तर पर, सवाल यह है कि मैं ग्राहक और शिपमेंट के बीच संबंध कैसे बना सकता हूं। मुझे वास्तव में "भरने" अर्थशास्त्र पसंद है जहां आपके शिपमेंट रिपोजिटरी में fillOrders (सूची ग्राहक, ....) हो सकते हैं।

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

Answer 3

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

आम तौर पर, मैं संस्थाओं के बीच एक-से-माने संघ नहीं बनाता जब कई पक्ष सीमित नहीं होते हैं।