7

मैं डीडीडी के लिए नया हूं, लेकिन मैं अपने वर्तमान प्रोजेक्ट में डीडीडी अवधारणाओं को शामिल करने की कोशिश कर रहा हूं।सीआरयूडी?

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

क्या ये एप्लिकेशन-सेवाएं भंडार के रूप में अनुप्रयोग सेवा पैटर्न का एक "सही" अनुप्रयोग है? या सीआरयूडी-केवल विधियों को आवेदन सेवाओं से बाहर रहना चाहिए? यदि हां, तो इंटरफेस परत पर एक भंडार मुखौटा होना चाहिए?

उत्तर

6

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

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

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

एक विकल्प है कि यह जिम्मेदारी होस्टिंग पर्यावरण के बुनियादी ढांचे, जैसे कि एएसपी.नेट एमवीसी अनुप्रयोग में एक्शन फ़िल्टर के लिए।


+3

कृपया अनुच्छेदों का उपयोग करें, यह पाठ को पढ़ने में बहुत आसान बनाता है। – jgauffin

+0

माफी, क्या करेंगे! – eulerfx

+0

मामले के मामले में CRUDy हैं और ग्राहक सीधे भंडार कॉल कर रहे हैं, क्या भंडार होना चाहिए Ippl लेनदेन को संभालना नहीं है? – redzedi

1

आपकी एप्लिकेशन सेवाओं में आपके तरीकों में ऐसे नाम होने चाहिए जो आपके उपयोग के मामलों का प्रतिनिधित्व करते हैं। अक्सर डीडीडी में कहा जाता है कि आपको सीआरयूडी से बचना चाहिए, लेकिन मेरे अनुभव में, उत्पाद मालिक/डोमेन विशेषज्ञ अक्सर 'निर्माण' या 'जोड़ना' इकाई के संदर्भ में बात करते हैं, और 'अद्यतन', 'संपादन' या 'संशोधन' और इकाई। यदि वे उपयोग के मामले हैं तो आपको कार्यान्वयन के साथ काम सौंपा गया है, तो वे निश्चित रूप से आपके आवेदन पत्र में होंगे।

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

3

यदि आपके डोमेन को CRUD-शैली के उपयोग के मामलों की आवश्यकता है, तो वे सही हैं।

मेरी राय में, रिपॉजिटरीज़ को सीधे प्रकट करना गलत होगा, क्योंकि आवेदन सेवाओं की जिम्मेदारियों में कार्यात्मक उपयोग के मामले में "बस" से अधिक शामिल है; वह लेनदेन नियंत्रण, सुरक्षा, और बुनियादी इनपुट सत्यापन है।

संबंधित मुद्दे