आम तौर पर मुझे Mu (जेन अर्थ में) का जवाब देने का लुत्फ उठाना पड़ता है, क्योंकि परिदृश्य एक डीडीडी परिप्रेक्ष्य से गलत है। डीडीडी में हम व्यावसायिक आवश्यकताओं और डोमेन विशेषज्ञों से शुरू करते हैं और उनसे हम डोमेन मॉडल प्राप्त करते हैं।
हालांकि यह एक विवादास्पद बिंदु है, डेटाबेस लगभग व्यावसायिक घटनाओं का एक आकस्मिक आर्टिफैक्ट है (जो लगभग हमेशा बताता है कि संस्थाओं को जारी रखा जाना चाहिए)।
उसने कहा, मैं अपनी पूरी कोशिश करने की कोशिश करूंगा।
ज्यादातर मामलों में, ऑर्डर एक बहुत ही महत्वपूर्ण व्यावसायिक वस्तु है, और स्पष्ट रूप से हमें प्रत्येक पंक्ति में उत्पाद समेत ऑर्डर लाइनों के बारे में जानना आवश्यक है, इसलिए ऐसा लगता है कि हमें ऑर्डर लाइन (ऑर्डर_Detail) से एसोसिएशन की आवश्यकता है। उत्पाद के लिए।
हालांकि, जब कोई विशेष उत्पाद दिया जाता है, तो हमें शायद ही कभी यह पता होना चाहिए कि इसमें कौन से ऑर्डर शामिल किए गए थे, ताकि वहां एक तरफा रिश्ते का सुझाव दिया जा सके। हम ऑर्डर लाइन से उत्पाद तक नेविगेट कर सकते हैं, लेकिन उत्पाद से ऑर्डर लाइनों तक नहीं।
हालांकि, उपर्युक्त विश्लेषण एक गहरे स्तर पर झूठा हो सकता है। डेवलपर और डोमेन विशेषज्ञ के बीच निम्न बातचीत की कल्पना कीजिए:
देव:हम उत्पादों के आदेश से इस संघ बना लिया है ताकि हम हमेशा एक विशेष क्रम में उत्पादों के बारे में सब कुछ पता है।
समाप्ति:यह अच्छा लगता है, लेकिन क्या सप्लायर के बारे में?
देव:इसमें भी शामिल है।
समाप्ति:तो क्या होता है जब हम उत्पाद के लिए आपूर्तिकर्ता को बदलने?
देव:कि परोक्ष रूप में अच्छी तरह आदेश डेटा में परिलक्षित होगा ...
समाप्ति:यही नहीं है कि हम क्या चाहते हैं। हम डेटा को उस समय ऑर्डर को प्रतिबिंबित करना चाहते हैं जब हमने इसे भेज दिया था।
इस मामले में, यह पता चला है कि वास्तव में डेटाबेस स्कीमा में एक त्रुटि है। समस्या रिपोर्टिंग के कारण हो सकती है, क्योंकि व्यावसायिक एनालिस्टिस्ट रिपोर्ट चला सकते हैं कि विभिन्न आपूर्तिकर्ताओं ने कमाई को कैसे प्रभावित किया है (मुझे क्या पता है)।
ऐसा मामला ऑर्डर लाइनों से उत्पाद को पूरी तरह से काटने का सुझाव दे सकता है। आदेशों को ऐतिहासिक उत्पाद डेटा नहीं, ऐतिहासिक (स्नैपशॉट) उत्पाद डेटा रखना चाहिए।
हम भी एक ProductSnapshotमूल्य वस्तु कि शब्दार्थ डोमेन मॉडल में इस मॉडल के लिए एक Productइकाई दर्पण entroduce सकता है।
सब कुछ, यह Order मॉडल और ऑर्डर लाइनों (ProductSnapShots के साथ) के रूप में मॉडल के लिए अधिक से अधिक उचित लगता है, लेकिन ऑर्डर और ग्राहकों के बीच संबंधों के बारे में क्या?
जैसा कि मैं वर्तमान में एसोसिएशन और समेकन को समझता हूं, एसोसिएशन को समेकित करता है। एक आदेश दिया, क्या हम ग्राहक के बारे में जानना चाहते हैं? सबसे अधिक संभावना। एक ग्राहक को देखते हुए, क्या आप ऑर्डर के बारे में जानना चाहेंगे? शायद।
यह दो-तरफा संबंध सुझाता है, जो Customerकुल रूट बनाता है। इसका मतलब है कि आपके पास CustomerRepository होगा, लेकिन OrderRepository नहीं होगा। हर बार आपको ऑर्डर की आवश्यकता होती है, आपको इसे Customer के माध्यम से प्राप्त करना होगा।
कुछ मामलों में यह सही मायने में समझ सकता है, जबकि यह वास्तव में अन्य परिस्थितियों में घबराहट हो सकता है। यह वास्तव में व्यावसायिक आवश्यकताओं पर निर्भर करता है ...
आप OrderRepository भी बनाने पर विचार कर सकते हैं, लेकिन यह Customer कुल रूट पर हमला करता है। यदि आप ऐसा करते हैं, तो यह अस्पष्ट हो जाता है जहां आदेश की ज़िम्मेदारी झूठ बोलती है। यदि आप ऑर्डर से ग्राहक तक घूमते हैं तो क्या होता है? Customer में ऑर्डर की एक सूची है, लेकिन क्या आप OrderRepository से ऑर्डर पढ़ते हैं, तो क्या वे सभी स्मृति में आबादी में हैं?
शायद नहीं, लेकिन यदि आप CustomerRepository से ग्राहक को पढ़ते हैं तो वे होने की संभावना है।यहां बिंदु यह है कि का विश्लेषण कुल रूट महत्वपूर्ण है, और एक बार जब आप एक समग्र परिभाषित कर लेते हैं, तो आपको इसके साथ रहना होगा और इसका सम्मान करना होगा।
जो मुझे बड़ा समुच्चय से अधिक पक्ष छोटे समुच्चय करने का कारण बनता है, तो इस उदाहरण में, मैं Order और उसके आदेश लाइनों के लिए कुल विवश होता है, और Order और Customer बीच कोई संबंध नहीं है।
नहीं Order और Customer के बीच एक औपचारिक संघ होने का मतलब यह नहीं है कि हम उन पर सभी संबंधित नहीं कर सकते हैं, लेकिन हम किसी दिए गए ग्राहक के लिए हम सभी को आदेश देता है स्पष्ट सेवाओं की जरूरत है। हम सिर्फ एक से दूसरी तरफ नेविगेट नहीं कर सकते हैं।
उदाहरण सबसे अच्छा नहीं है। स्पष्ट रूप से नॉर्थविंड डेटाबेस दिमाग में संबंधपरक डेटा के साथ किया गया था। जैसा कि आपने कहा था, हम उस डेटाबेस की शुरुआत में आवश्यक आवश्यकताओं को नहीं जानते हैं। लेकिन आपके एनालिसिस बहुत अच्छे और विस्तृत हैं। यह दिखाता है कि डीएम को कैसे सोचना चाहिए और मॉडलिंग किया जाना चाहिए। आपके समय और विस्तृत प्रतिक्रिया के लिए धन्यवाद। –