डोमेन संचालित डिजाइन: बड़े संबंधों को कैसे मॉडल करें, लेकिन कुछ व्यवहार हैं

Question

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

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

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

एक तरीका जिस तरह से मैं आ सकता हूं, उपयोगकर्ता के समान संबंध का परिचय देना है, UserLikeItem कहें, और विधि उपयोगकर्ता जैसा है (आइटम) UserLikeItem का एक उदाहरण देता है जिसे मैं जारी रखने के लिए UserLikeItemRepository का उपयोग कर सकता हूं।

क्या यह एक वैध समाधान है? डीडीडी में इस प्रकार के बड़े लेकिन गैर व्यवहार संबंधी संबंधों का मॉडल करने का प्राकृतिक तरीका क्या है?

Answer 1

मैं इस पर एक खुदाई करूँगा :), आईएमओ अगर व्यवहार नहीं करता है तो यह "डोमेन मॉडल" में नहीं रहता है, और यदि आपकी अवधारणाओं में से अधिकांश में व्यवहार नहीं होता है तो आपको " डोमेन मॉडल ", आपको शायद डोमेन मॉडल के बजाय transaction script पैटर्न की तरह देखना चाहिए।

मैं आपके प्रश्न को "प्रदर्शन करने वाले तरीके से कई रिश्तों में कैसे बरकरार रखता हूं" इस प्रश्न के बारे में बताता हूं कि इस प्रश्न के लिए हमारे पास कई उत्तर हैं, एक ऐसा है जिसे आपने अन्य बताया है, बस आईडी की सूची को स्टोर कर सकता है कक्षाएं।

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

लेकिन जब आपके पास डोमेन मॉडल का मामला होता है तो यह मुश्किल हो जाता है, लेकिन केवल कुछ अवधारणाएं एनीमिक और कमी का व्यवहार करती हैं लेकिन यह एक एक और दिन के लिए प्रश्न :)

Answer 2

'पसंद' डोमेन तथ्य है, जिसे इकाई द्वारा दर्शाया जा सकता है।
आइटम पसंद हैं -> आइटम में पसंद का संग्रह शामिल है।
यह संग्रह केवल पसंदों को जोड़ने और हटाने के लिए आवश्यक है -> आइटम में LikeCount प्रॉपर्टी है और पसंद का संग्रह रेपोजिटरी क्वेरी के लिए वैकल्पिक है (केवल आइटम में उपयोग किया जाता है। AddLikeFrom (उपयोगकर्ता) और Item.RemoveLikeFrom (उपयोगकर्ता) विधियों)।

यह देख सकता है कि संबंध गैर-व्यवहारिक है, लेकिन वास्तव में यह संबंध पक्षों में से एक का व्यवहार है।

Answer 3

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

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

एलएस बस उपयोगकर्ता आईडी और अन्य आइटम का एक संघ रखता है एक निश्चित प्रकार का आईडी (जो एक स्ट्रिंग हो सकता है, यदि आप चाहते हैं कि एलएस को कोई आइटम न हो)। हर बार जब कोई उपयोगकर्ता कुछ कमांड की तरह जारी होता है: RegisterLikeForItem {UserId, ItemId, ItemType}। एक एलएस हैंडलर उस जानकारी को स्टोर करेगा, फिर एक ईवेंट उपयोगकर्ताLikedItem प्रकाशित करेगा। इसके हैंडलर में से एक काउंटर होगा जो यह गिना जाएगा कि कितने उपयोगकर्ताओं को उस आइटम को पसंद आया। एक और हैंडलर एक उपयोगकर्ता द्वारा कौन सी वस्तुओं को पसंद किया गया था इसकी एक सूची बना सकता है (यह यूआई द्वारा पूछे जाने वाले प्रश्न)।

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