डोमेन ऑब्जेक्ट्स का नामकरण जो डीडीडी बिल्डिंग ब्लॉक जैसे कि रिपॉजिटरीज

Question

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

एक और ठोस उदाहरण देने के लिए कहें कि हम डीडीडी की भावना में एक समय ट्रैकिंग अनुप्रयोग तैयार कर रहे हैं और कुछ ऐसा सामना करते हैं जो डोमेन विशेषज्ञों को "टाइम लॉग" के रूप में संदर्भित किया जाता है, जो कि लॉग होता है सभी कर्मचारियों के लिए -इन और संबंधित पंच-आउट समय।

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

अब हम जो सर्वव्यापी भाषा या की DDD अवधारणा के साथ लाइन में और अधिक लगता है या तो के रूप में हमारे भंडार नामकरण TimeLog के विकल्प के साथ छोड़ दिया जाता है कि हम इसे TimeLogEntryRepository जो नामकरण के लिए अधिक सामान्य सम्मेलन फिट करने के लिए लगता है कह सकते हैं कुल रूट के बाद रिपोजिटरीज जो वे क्वेरी/जारी रखते हैं। मैं टाइमलॉग का उपयोग करने के विचार की ओर झुका रहा हूं क्योंकि यह डोमेन मॉडल में वास्तविक भूमिका के बारे में अधिक वर्णनात्मक है, जो बदले में डोमेन विशेषज्ञों को डिज़ाइन संचार में मदद करनी चाहिए। दूसरी ओर टाइमलॉग एंटर्री रिपोजिटरी का उपयोग करने का विकल्प मौजूदा डीडीडी सम्मेलनों का पालन करता है और इस प्रकार डेवलपर्स के लिए डिज़ाइन को आसान बनाना होगा। टाइमलॉग नामकरण के साथ एक समझौता भी हो सकता है लेकिन सभी रिपॉजिटरीज एक आईआरपोजिटरी इंटरफ़ेस को लागू करने के लिए या एक सामान्य रिपोजिटरी बेस क्लास से प्राप्त होते हैं ताकि डेवलपर्स को डोमेन मॉडल बनाने वाले अन्य लोगों से रिपोजिटरी कक्षाओं को ढूंढने और अलग करने में सहायता मिल सके। बेस क्लास का उपयोग करने के साथ मेरी मुख्य चिंता यह है कि यह केवल संगठन के उद्देश्य के लिए मार्कर इंटरफेस या कमजोर अनावश्यक बेस क्लास के उपयोग को प्रोत्साहित कर सकता है, न कि व्यवहारिक कारकों के कारण।

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

Answer 1

मैं व्यक्तिगत रूप से TimeLog पसंद करता हूं।

यह वास्तव में आश्चर्यजनक है कि तकनीक के बजाए व्यवसाय पर ध्यान केंद्रित करने के बाद यह कितना आसान हो जाता है। उस फोकस को तेज रखने के लिए उचित नामकरण मुख्य हथियार है।

यह सेवाओं के लिए जाता है - ApplicationRegistrationService के बजाय, मैं ApplicationRegistrator का उपयोग करता हूं।

यहां repositories के बारे में काफी अच्छा लेख है।

Answer 2

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