यदि आप सीआरयूडी के लिए अपने डीडीडी ऐप के शीर्ष पर एक आरईएसटी परत रखना चाहते हैं, तो क्या आप आरईएसटी परत को डोमेन मॉडल (डेटा के संदर्भ में) थूक देंगे (जीईटी के लिए कहें)?क्या डीडीडी आवेदन पर आरईएसटी एपीआई से डोमेन मॉडल वापस करना अच्छा है?
आम तौर पर, आप अपने डोमेन ऑब्जेक्ट्स को बदलने के बिना, अपने डोमेन ऑब्जेक्ट्स (उदाहरण के लिए जब आप डोमेन के बारे में कुछ नया सीखते हैं) को बदलने में सक्षम होना चाहते हैं। एक ही बात दूसरी तरफ: यदि सार्वजनिक इंटरफेस में बदलाव की आवश्यकता है, तो आप अपना डोमेन मॉडल बदलना नहीं चाहते हैं।
तो इस परिप्रेक्ष्य से मैं कभी भी सार्वजनिक डोमेन इंटरफ़ेस पर अपने डोमेन ऑब्जेक्ट्स का खुलासा नहीं करूंगा। इसके बजाय मैं डेटा ट्रांसफर ऑब्जेक्ट्स (डीटीओ) बनाना चाहता हूं जो सार्वजनिक इंटरफ़ेस का हिस्सा हैं। इस तरह, मेरे डोमेन और सार्वजनिक एपीआई में परिवर्तन स्वतंत्र रूप से बदल सकते हैं।
आपको डीडीडी मॉडल का पर्दाफाश नहीं करना चाहिए। यह बिल्कुल सही है, क्योंकि एसओए फ्रंटएंड को ग्राहकों को कार्यान्वयन विवरण का खुलासा नहीं करना चाहिए। आपके उपयोगकर्ताओं को एक व्यावसायिक कार्य पर निर्भर होना चाहिए, कार्यान्वयन विस्तार नहीं ... लेकिन यह कई एसओए बस में एकजुट हो सकता है, शायद विषम, अनुप्रयोगों का एक अच्छा डिजाइन मानता है।
मैं उत्तर में जोड़ना चाहता हूं क्योंकि सीआरयूडी इंटरफेस का उल्लेख मुझे लगता है कि यह एसओए दुर्व्यवहार का मामला हो सकता है जहां एसओए सिद्धांतों का उपयोग अनुप्रयोगों के नेटवर्क की बजाय किसी अनुप्रयोग की परतों को चिपकाने के लिए किया जाता है । एसओए उद्यम के लिए अपने सिस्टम को संवाद करने का एक तरीका है, यह एमवीसी को लागू करने का एक तरीका नहीं है! इतना आसान अभी तक गलत समझा। उदाहरण के लिए, सिर्फ इसलिए कि आपका फ्रंट एंड जीयूआई बैकएंड तक पहुंचने के लिए सेवाओं का उपयोग करता है, आपके पास "एसओए एप्लीकेशन" नहीं है ... इसका क्या मतलब है।
यदि यह गोंद परतों के लिए उपयोग किए जाने वाले एसओए का मामला है, तो कृपया अपने डिजाइन को संशोधित करें और उस स्तर के अमूर्तता के लिए उचित डिजाइन आर्किटेक्चर का उपयोग करें। अन्यथा आप डीडीडी मॉडल को उजागर करने और CRUDY का उपयोग न करने के बारे में यहां दी गई सिफारिशों की गलत व्याख्या करेंगे, और आप निश्चित रूप से सेवा इंटरफ़ेस के लिए एक अलग डोमेन मॉडल बनाना समाप्त कर देंगे, तब आपको डीडीडी पर मानचित्र करना होगा, जो कि बहुत जटिल है कि आपको डोजर और चीजों को उसी नाम को अलग-अलग नामों के साथ मैप करने की आवश्यकता होगी, और तब तक जब तक हम एक ब्लोएटेड अन रखरखाव वाली गड़बड़ी के साथ समाप्त नहीं हो जाते ...
.. बस सावधान रहें।
-Alex
Redzedi तो सही है कि हम एक स्पष्टीकरण की जरूरत है ....
सब कुछ की तरह, यह काफी अधिक कहने के लिए की तुलना में ऐसा करने के लिए जटिल है। एक जटिल डोमेन मॉडल को क्रमबद्ध करना इतना कठिन हो सकता है कि आप या तो डोमेन में कोई तर्क नहीं डाल सकते हैं, एनीमिक मॉडल एंटीपाटरर्न (http://martinfowler.com/bliki/AnemicDomainModel.html), या इसके लिए एक अलग एनीमिक मॉडल है दृढ़ता, यानी डीटीओ।
मुझे नहीं पता कि सबसे खराब क्या है, लेकिन दोनों विकल्प खराब हैं। आपको मॉडल में मॉडल में जाने वाले तर्क को रखना चाहिए और आपको सीधे हर जगह क्रमबद्ध करने में सक्षम होना चाहिए।
कई वर्षों से डोमेन मॉडल का उपयोग करके मेरे अनुभव में, मेरा मानना है कि सबसे अच्छी बात मध्य में एक बिंदु है। हां, फाउलर और इवांस राज्य के रूप में, व्यवसाय वस्तुओं को तर्क रखना चाहिए, लेकिन सभी नहीं (http://codebetter.com/gregyoung/2009/07/15/the-anemic-domain-model-pattern/) एक छोटे से एनीमिया के साथ अच्छी सेवा परत सबसे अच्छी है।
उदाहरण के लिए, चालान को इसके आइटमों के बारे में पता होना चाहिए और इसकी कुल गणना करने की प्रक्रिया होनी चाहिए, जो वस्तुओं पर निर्भर करता है। लेकिन एक चालान के आइटम को चालान-प्रक्रिया के बारे में जानने की आवश्यकता नहीं है।तो क्या होता है जब कोई आइटम लागत में बदलता है, क्या उसके पास एक चालक संदर्भ के रूप में पिता चालान के लिए एक सूचक वापस होना चाहिए और चालान की कुल गणना की गणना करना चाहिए?
मुझे विश्वास नहीं है। मुझे लगता है कि यह सेवा परत के लिए एक कार्य है जिसे पहले घटना प्राप्त करनी चाहिए और फिर प्रक्रिया को ऑर्केस्ट्रेट करना चाहिए, कार्यान्वयन उद्देश्यों के लिए सभी व्यावसायिक वस्तुओं को एक साथ जोड़ना और व्यापार इंटरैक्शन नियमों का उल्लंघन करना, जो एक डोमेन मॉडल है।
-Alex
धन्यवाद एलेक्स, एसओए या डोमेन मॉडल से कुछ डीटीओ में मैपिंग डेटा का मुद्दा नहीं है ताकि दृश्य उपभोग कर सके, हमेशा नहीं? – redzedi
हैलो रेडजेदी, मेरी व्यक्तिगत राय में मैं डोमेन मॉडल को सीधे डेटाबेस पर मैप करने का प्रयास करता हूं। डोमेन मॉडल डेटा मॉडल है। तो मेरे पास उपयोगकर्ता इंटरफ़ेस और डेटाबेस दोनों के लिए केवल एक व्यावसायिक वस्तु है। –
यह एक बहुत ही महत्वपूर्ण बात है जो आप एलेक्स कह रही है, मेरे लिए बहुत आकर्षक लगती है, लेकिन मैंने इसके बारे में सभी प्रकार की चीजें सुनी हैं, जो मारिजन ऊपर बताती है कि बहुत पीपीएल विश्वास करता है, लेकिन मेरे अनुभव में, जो बहुत समान दिखता है विभिन्न परतों में जावा वर्ग जहां किसी भी बाद के जोड़े में बहुत सारे dogmatic कोड मैपिंग की ओर जाता है। – redzedi
क्या यह संभव है एनोटेट DTOs (आदेश, क्वेरी, डोमेन घटना) के आधार पर बाकी हिस्सा उत्पन्न करने के लिए, और अगर हां तो कैसे? इसे यहां उत्तर दें: http://stackoverflow.com/questions/26049934/is-it-possible-to-do-ddd-and-rest-interface-and-language- मानचित्रण – inf3rno
यह थोड़ा पक्षपातपूर्ण है। डीडीडी में डोमेन से कृत्रिम रूप से "गार्ड" उपयोगकर्ताओं की आवश्यकता नहीं है: कुछ अवधारणाएं "मॉडल के रूप में" के रूप में "गुजरती हैं", अन्य छिपी हो सकती हैं (जब तक कि मॉडल बिल्कुल सही न हो)। इसके अलावा, मूल पोस्ट में "डीडीडी पर आरईएसटी" संदिग्ध है। पहले डोमेन के शीर्ष पर कुछ प्रकार की एप्लिकेशन लेयर (अधिकांश समय) होनी चाहिए। इसका मतलब है, डोमेन ऑब्जेक्ट्स पहले ही अलग हो चुके हैं। –
@RomanSusi मुझे यकीन नहीं है कि "उपयोगकर्ता से डोमेन से रक्षा करें" का क्या मतलब है; क्या आप थोड़ा सा विस्तार कर सकते हैं? मैं पूरी तरह से सहमत हूं कि सार्वजनिक इंटरफेस डोमेन के समान अवधारणाओं से निपटेंगे। मेरा मुद्दा सार्वजनिक रीस्ट इंटरफ़ेस के उपभोक्ताओं से डोमेन को "सारणित" करने के बारे में नहीं है, यह डोमेन सार्वजनिक ऑब्जेक्ट्स में परिवर्तनों को इस सार्वजनिक आरईएसटी इंटरफ़ेस में परिवर्तन से डिकूप्लिंग करने के बारे में है। – Marijn