मुझे डोमेन ड्रिवेन डिज़ाइन में प्रस्तुति और एप्लिकेशन परत के बीच एक स्पष्ट रेखा खींचने में समस्या है।
नियंत्रक, दृश्य, लेआउट, जावास्क्रिप्ट और CSS फाइलें कहां जानी चाहिए?
यह अनुप्रयोग या प्रस्तुति परत में है?
और अगर वे सभी एक ही परत में एक साथ जाते हैं, तो दूसरे में क्या है? क्या यह खाली है?
जवाबों:
सिर्फ इसलिए कि किसी ने "एप्लिकेशन लेयर" और "प्रेजेंटेशन लेयर" नाम बनाया और इसका मतलब यह नहीं है कि आपके आवेदन में उनके पास होना चाहिए। आपको परतों का निर्माण करना चाहिए जब आप एक से अधिक मात्रा में कोड बना लेते हैं जो आप एक साथ समूहीकृत करते हैं और डेवलपर्स के बीच संचार और कोड की स्पष्टता के लिए इस समूह का नाम देना चाहते हैं।
DDD के बिंदु से। एप्लीकेशन लेयर वह सब कुछ है जो डोमेन लेयर नहीं है। जिसमें एप्लिकेशन लॉजिक, प्रेजेंटेशन और एप्लिकेशन सर्विसेज शामिल हैं।
डीडीडी व्यू पॉइंट से एप्लिकेशन लेयर और प्रेजेंटेशन लेयर के बीच एक बड़ा अंतर है।
हालांकि डीडीडी केंद्रों के बारे में बताता है कि डीडीडी बिल्डिंग ब्लॉकों और बंधे हुए संदर्भों, सर्वव्यापी भाषा जैसे अवधारणाओं का उपयोग करके डोमेन को कैसे मॉडल किया जाए, और यह अभी भी आपके ऐप में विभिन्न परतों को स्पष्ट रूप से पहचानने और अलग करने के लिए महत्वपूर्ण है।
सफल DDD ऐप को लागू करने में आर्किटेक्चर एक बड़ी भूमिका निभाता है। एक प्रसिद्ध वास्तुकला जिसने बहुत अधिक प्रचार प्राप्त किया, वह है प्याज वास्तुकला:
इस डिज़ाइन में UI / प्रेजेंटेशन लेयर और एप्लिकेशन लेयर स्पष्ट रूप से अलग हो गए हैं। 2 को एक साथ मर्ज करना 2 परतों के बीच तंग युग्मन का परिचय देता है जिसमें स्पष्ट अलग-अलग चिंताएं और जिम्मेदारियां होती हैं।
प्रेजेंटेशन लेयर में केवल हाउस प्रेजेंटेशन लॉजिक होना चाहिए। स्मार्ट UI से बचें जो बहुत अधिक जानते हैं। यह मुख्य रूप से सीवीसी, जेएस, टेम्प्लेट, फ़ॉर्म और सब कुछ के अलावा एमवीसी के नियंत्रकों और विचारों को शामिल करता है, जो प्रतिक्रिया और वस्तुओं का अनुरोध करने से संबंधित है।
प्रस्तुतिकरण के माध्यम से जारी किए गए कार्यों को आदेशों के माध्यम से आवेदन परत को सौंप दिया जाता है। एप्लिकेशन लेयर में एप्लिकेशन लॉजिक होता है। यह आमतौर पर उपयोग के मामले में मैप करता है। इसमें ऐसा क्या है कि सिस्टम को उपयोग के मामले को संतुष्ट करने के लिए क्या करना चाहिए। एक विशिष्ट एप्लिकेशन सेवा एक संग्रह को वापस एकत्र करने के लिए एक भंडार के लिए कहेगी और फिर उस समुच्चय पर कार्रवाई शुरू करेगी।
वॉन वर्नोन के IDDD से नमूना परियोजना पर एक नजर है
entry pointऔर कैसे composition rootरखे गए हैं। मैंने हमेशा सोचा कि यह Applicationपरत की जिम्मेदारी थी । लेकिन अब ऐसा लग रहा है कि यह Presentationपरत है।
Domain Driven Design का Presentation layer या Application layer से कोई लेना देना नहीं है। डीडीडी एक कार्यप्रणाली है जिसका मुख्य ध्यान डोमेन परत पर है। अर्थात, DDD डोमेन लेयर को छोड़कर किसी अन्य लेयर के संबंध में कोई अड़चन नहीं डालता है और आपका प्रश्न किसी भी अन्य कार्यप्रणाली के संदर्भ में पूछा जा सकता है।
कहा जा रहा है, डीडीडी अनुप्रयोगों के लिए चार-परत वास्तुकला का उपयोग करना बहुत आम है। यहां परतों और उनके इच्छित उपयोग को दर्शाने वाले ऐसे ही एक एप्लिकेशन का एक उदाहरण है: DDDSample Architecture । इसलिए, यदि आप इस वास्तुकला का उपयोग करना चुनते हैं, तो आपके विचार और लेआउट इंटरफेस की परत पर चले जाएंगे और नियंत्रक, यदि इंटरफ़ेस-स्वतंत्र हैं, तो एप्लिकेशन परत पर जाएंगे।
आप किसी भी अन्य प्रकार की वास्तुकला का चयन कर सकते हैं, जैसा कि मैंने कहा है कि डीडीडी बाधाओं को लागू नहीं करता है। वहाँ कई एमवीसी रूपरेखाएं हैं जिनके पास अलग-अलग संरचनाएं हैं और फिर भी डीडीडी अनुप्रयोगों के लिए उपयोग किया जा सकता है। फिर, निश्चित रूप से, आप अपने विचारों और लेआउट को उसी के अनुसार रखेंगे।