डीडीडी डोमेन सेवाएं: सेवा कक्षा में क्या होना चाहिए?

Question

डोमेन संचालित डिजाइन में, डोमेन सेवाओं में ऐसे ऑपरेशन होना चाहिए जो स्वाभाविक रूप से किसी इकाई के अंदर न हों।

मैं को आदत इसके अंदर इकाई और समूह के कुछ तरीकों प्रति एक सेवा (Organization इकाई और OrganizationService सेवा) बना लिया है।

लेकिन अधिक मैं इसके बारे में सोचो: OrganizationService कुछ भी मतलब नहीं है कि, "संगठन" है नहीं एक सेवा है, यह एक बात है।

तो अभी मुझे एक संगठन गहरी प्रति कार्यक्षमता जोड़नी है जो पूरे संगठन को कुल मिलाकर डुप्लिकेट करेगी, इसलिए मैं इसे एक सेवा में रखना चाहता हूं।

मुझे क्या करना चाहिए: OrganizationService::copyOrganization(o)?

या मुझे करना चाहिए: OrganizationCopyService::copyOrganization(o)?

अधिक आम तौर पर: एक "सेवा" एक अमूर्त अवधारणा है जिसमें कई परिचालन होते हैं, या एक सेवा एक ठोस संचालन है?

संपादित: अधिक पहले एक दिया उदाहरण है कि अच्छा नहीं था:

• StrategyService::apply()/cancel() या StrategyApplicationService::apply()/cancel()? (यहां "एप्लिकेशन" एप्लिकेशन परत से संबंधित नहीं है;)
• CarService::wash() या CarWashingService::wash()?

इन सभी उदाहरणों में सबसे विशिष्ट सेवा नाम सबसे उपयुक्त लगता है। आखिरकार, वास्तविक जीवन में, "कार धोने की सेवा" कुछ ऐसा है जो समझ में आता है। लेकिन मैं कई सेवाओं के साथ समाप्त हो सकता हूं ...

* नोट: यह राय के बारे में कोई सवाल नहीं है! यह डोमेन संचालित डिजाइन पद्धति के बारे में एक सटीक, उत्तरदायी प्रश्न है। "मुझे चाहिए" पूछते समय मैं हमेशा करीबी वोटों से थक जाता हूं, लेकिन चीजों को करने का एक डीडीडी तरीका है। *

Answer 1

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

Answer 2

यह थोड़ा सा राय है, मैं इसे एक टिप्पणी के रूप में जोड़ना चाहता था लेकिन अंतरिक्ष समाप्त हो गया ।

I पर विश्वास करें कि इस मामले में विभिन्न विधियों के साथ एक अलग संगठन फैक्ट्री-सेवा में विधियों को समूहित करने के लिए यह समझदारी होगी।

interface OrganizationFactory{ 
     Organization createOrganization(); 
     Organization createOrganizationCopy(Organization organization); 
    } 

मैं इसके साथ जानकारी विशेषज्ञ पैटर्न और सूखी सिद्धांत अनुसार किया जाएगा लगता है - एक वर्ग विशेष वस्तु निर्माण के बारे में सभी जानकारी है और मैं अलग में इस तर्क को दोहराने के लिए किसी भी कारण नहीं दिख रहा है स्थानों।

फिर भी, एक दिलचस्प बात यह है कि कारखाना पैटर्न

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

शब्द "वस्तु" में एक सामान्य अर्थ भी एक अलग वर्ग होने की जरूरत नहीं है, लेकिन यह भी एक कारखाने तरीका हो सकता है (मैं दोनों एक वर्ग की विधि और पैटर्न कारखाने विधि मतलब है) - बाद में इवांस Brokerage Account की फैक्ट्री विधि का एक उदाहरण देता है जो Trade Order के उदाहरण बनाता है।

पुस्तक गोफ कारखाने के पैटर्न के परिवार के संदर्भ में है और मुझे नहीं लगता कि फैक्ट्री अपघटन का एक विशेष डीडीडी तरीका है - मुख्य बिंदु यह है कि बनाई गई वस्तु आधा बेक्ड नहीं है और कारखाने की विधि को जोड़ना चाहिए संभवतः कुछ निर्भरताएं।

अद्यतन DDD, किसी विशेष प्रोग्रामिंग प्रतिमान से जुड़ी नहीं है, जबकि प्रश्न, के बारे में वस्तु उन्मुख अपघटन है तो फिर मुझे नहीं लगता कि DDD वस्तु प्रति तरीकों की संख्या पर कोई विशेष सुझाव प्रदान कर सकते हैं ।

कुछ लोग strange rules of thumb का उपयोग करते हैं, लेकिन मेरा मानना ​​है कि आप High Cohesion principle के साथ जा सकते हैं और साथ ही साथ अत्यधिक संबंधित जिम्मेदारियों के साथ विधियां भी डाल सकते हैं। चूंकि यह एक डीडीडी सवाल है, इसलिए मुझे लगता है कि यह डोमेन सेवाओं के बारे में है (यानी बुनियादी ढांचा सेवाएं नहीं)। मुझे लगता है कि सेवाओं को डोमेन में उनकी जिम्मेदारियों के अनुसार विभाजित किया जाना चाहिए।

अपडेट 2 वैसे भी CarServiceCarService::wash()/CarService::repaint()/CarService::diagnoseAirConditioningProblems() कर सकते हैं, लेकिन यह अजीब है कि CarWashingServiceCarWashingService::diagnoseAirConditioningProblems() करना होगा ऐसा लगता है जैसे चोमस्की के उत्पादक व्याकरण में है होगा - भाषा मेकअप अर्थों में कुछ बयान (वाक्य), और कुछ नहीं। लेकिन अगर आपकी वाक्य में बहुत अधिक विषय हैं (5-7 से अधिक कहें) तो यह समझना मुश्किल होगा, भले ही यह भाषा में मान्य वाक्य हो।