डोमेन संचालित डिजाइन: कुल रूट कब बनाना है?

Question

मैं एएसपी.नेट एमवीसी परियोजना के साथ पहली बार डीडीडी लागू करने का प्रयास कर रहा हूं और मैं कुछ चीजों से जूझ रहा हूं।

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

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

अगर मुझे प्रदायक के लिए भंडार था तो मुझे वास्तव में गेटऑन करने की आवश्यकता थी। मैं अपनी कंपनी या कंपनी रिपोजिटरी में GetOneSupplier जोड़ कर कुछ काम जोड़ सकता हूं, लेकिन यह जंकी लगता है।

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

tldr;

अलग सूची/बनाने/अद्यतन/पृष्ठों को एक संकेत की आवश्यकता है कि एक इकाई अपनी खुद की जड़ होनी चाहिए?

Answer 1

आपकी शब्दावली के आधार पर मुझे लगता है कि आप एरिक इवांस की पुस्तक के आधार पर डीडीडी कर रहे हैं। ऐसा लगता है कि आप मॉडलिंग पर अपने प्रारंभिक जाने के साथ पहले से ही एक समस्या की पहचान कर चुके हैं और आप सही हैं।

आपने उल्लेख किया है कि आप Value Object के रूप में आपूर्तिकर्ता के बारे में सोचते हैं ... मेरा सुझाव है कि यह नहीं है। एक Value Object मुख्य रूप से इसकी संपत्तियों द्वारा पहचाना जाता है। उदाहरण के लिए, "30 सितंबर, 200 9" तिथि एक मूल्य वस्तु है। क्यूं कर? क्योंकि एक अलग महीने/दिन/वर्ष कॉम्बो के साथ सभी दिनांक उदाहरण अलग-अलग तिथियां हैं। उसी महीने/दिन/वर्ष कॉम्बो के साथ सभी दिनांक उदाहरण समान मानते हैं। हम आपके लिए "30 सितंबर, 200 9" को स्वैप करने पर कभी बहस नहीं करेंगे क्योंकि वे समान हैं :-)

दूसरी ओर Entity मुख्य रूप से इसकी "आईडी" द्वारा पहचाना जाता है। उदाहरण के लिए, बैंक खातों में आईडी हैं - उनके पास खाता संख्याएं हैं। यदि बैंक में दो खाते हैं, प्रत्येक $ 500 के साथ, यदि उनके खाते की संख्या अलग हैं, तो वे भी हैं। उनकी गुण (इस उदाहरण में, उनकी शेष राशि) उन्हें पहचान नहीं देती है या समानता का संकेत नहीं देती है।मैं शर्त लगाता हूं कि बैंक खातों को स्वैप करने पर भी बहस होगी, भले ही उनके बैलेंस समान हों :-)

तो, उदाहरण के लिए, मैं एक सप्लायर को Entity पर विचार करता हूं, क्योंकि मुझे लगता है कि प्रत्येक सप्लायर मुख्य रूप से इसकी आईडी द्वारा पहचाना जाता है इसकी संपत्तियों की तुलना में। मेरी अपनी कंपनी दुनिया में दो अन्य लोगों के साथ अपना नाम साझा करती है - फिर भी हम सभी विनिमय नहीं कर सकते हैं।

मुझे लगता है कि अगर आपको किसी ऑब्जेक्ट को CRUD करने के लिए विचारों की आवश्यकता है तो यह आपके सुझाव को लगता है कि यह Entity शायद अंगूठे के नियम के रूप में सच है, लेकिन आपको अन्य ऑब्जेक्ट्स को अलग-अलग चीज़ों से अलग करना चाहिए: गुण या आईडी।

अब जहाँ तक Aggregate Root रों जाते हैं, आप वस्तुओं के जीवन चक्र और अभिगम नियंत्रण पर ध्यान केंद्रित करना चाहते हैं। इस बात पर विचार करें कि मेरे पास कई टिप्पणियों वाले ब्लॉग हैं जिनमें कई टिप्पणियां हैं - Aggregate Root कहां हैं? आइए टिप्पणी के साथ शुरू करते हैं। क्या किसी पोस्ट के बिना टिप्पणी करना समझ में आता है? क्या आप एक टिप्पणी तैयार करेंगे, फिर एक पोस्ट ढूंढें और इसे संलग्न करें? यदि आप कोई पोस्ट हटाते हैं, तो क्या आप इसकी टिप्पणियां चारों ओर रखेंगे? मेरा सुझाव है कि एक पोस्ट एक "पत्ता" - टिप्पणियों के साथ Aggregate Root है। अब ब्लॉग पर विचार करें - इसकी पोस्ट के साथ इसका संबंध पोस्ट और टिप्पणियों के बीच समान है। यह भी मेरी राय में एक Aggregate Root एक "पत्ता" - पदों के साथ है।

अपने उदाहरण में

इसलिए, कंपनी और आपूर्तिकर्ता के बीच एक मजबूत संबंध जिससे यदि आप एक कंपनी को हटाना (मुझे पता है ... आप शायद ही कंपनी का एक उदाहरण है) आप भी अपने आपूर्तिकर्ताओं को हटाना चाहते हैं? यदि आप "स्टारबक्स" (यूएस में एक कॉफी कंपनी) को हटाते हैं तो क्या इसके सभी कॉफी बीन आपूर्तिकर्ताओं का अस्तित्व समाप्त हो जाता है? यह सब अपने डोमेन और एप्लिकेशन पर निर्भर करता है, लेकिन मैं होने की संभावना न के अपने EntitiesAggregate Roots हैं, या शायद उनके बारे में सोचने के लिए एक बेहतर तरीका है कि वे सकल जड़ें नहीं "पत्ते" के साथ एक कर रहे हैं की तुलना में अधिक सुझाव है (एकत्र करने के लिए कुछ भी नहीं है)। दूसरे शब्दों में, कंपनी आपूर्तिकर्ताओं के जीवन चक्र तक पहुंच या नियंत्रण को नियंत्रित नहीं करती है। यह केवल आपूर्तिकर्ताओं (या शायद कई से कई) के साथ एक से अधिक संबंध है।

यह Repositories करने के लिए हमें लाता है। RepositoryAggregate Roots को संग्रहीत करने और पुनर्प्राप्त करने के लिए है। आपके पास दो (तकनीकी रूप से वे कुछ भी एकत्र नहीं कर रहे हैं, लेकिन यह कहने से आसान है कि "रिपोजिटरीज कुल जड़ें या संस्थाएं जो समग्र रूप से पत्तियां नहीं हैं"), इसलिए आपको दो Repositories की आवश्यकता है। कंपनी के लिए एक और आपूर्तिकर्ताओं के लिए एक।

मुझे उम्मीद है कि इससे मदद मिलती है। शायद एरिक इवांस यहां घूमते हैं और मुझे बताएंगे कि मैं उनके प्रतिमान से विचलित हूं।

Answer 2

मुझे कोई ब्रेनर जैसा लगता है - प्रदायक के पास अपना स्वयं का भंडार होना चाहिए। यदि कोई तर्कसंगत संभावना है कि मॉडल में एक इकाई स्वतंत्र रूप से मौजूद हो सकती है तो यह मूल इकाई होनी चाहिए, अन्यथा आप वैसे भी फिर से प्रतिक्रिया कर सकते हैं, जो अनावश्यक काम है।

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

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