मैं अपने पहले "वास्तविक" डीडीडी आवेदन पर काम कर रहा हूं।डीडीडी। उपयोगकर्ता कॉन्फ़िगर करने योग्य सेटिंग्स कहां से संबंधित हैं?
वर्तमान में मेरे क्लाइंट के पास मेरी डोमेन परत तक पहुंच नहीं है और आदेश जारी करके डोमेन में परिवर्तनों का अनुरोध करता है।
मेरे पास जानकारी प्रदर्शित करने के लिए एक अलग (फ़्लैटेड) पढ़ा गया मॉडल है (जैसे सरल सीक्यूआरएस)।
अब मैं कॉन्फ़िगरेशन पर काम कर रहा हूं, या विशेष रूप से, उपयोगकर्ता कॉन्फ़िगरेशन सेटिंग्स। एक उदाहरण के रूप में एक ब्लॉग अनुप्रयोग का उपयोग, सेटिंग्स ब्लॉग शीर्षक या लोगो हो सकता है।
मैंने एक सामान्य कॉन्फ़िगरेशन बिल्डर विकसित किया है जो एक सरल कुंजी मान जोड़ी संग्रह के आधार पर दृढ़ता से टाइप की गई कॉन्फ़िगरेशन ऑब्जेक्ट (उदा। ब्लॉगसेटिंग) बनाता है। मैं इस बात पर अटक गया हूं कि ये कॉन्फ़िगरेशन ऑब्जेक्ट्स मेरे डोमेन का हिस्सा हैं या नहीं। मुझे क्लाइंट और सर्वर से उनकी पहुंच की आवश्यकता है।
मैं एक "साझा" लाइब्रेरी बनाने पर विचार कर रहा हूं जिसमें इन कॉन्फ़िगरेशन ऑब्जेक्ट्स हैं। क्या यह सही दृष्टिकोण है?
अंत में ऐसी कॉन्फ़िगरेशन सेटिंग्स को सहेजने के लिए कोड कहां रहना चाहिए? एक आसान समाधान यह कोड मेरे डोमेन में डालना होगा। पर्सिस्टेंस प्रोजेक्ट, लेकिन फिर, यदि वे डोमेन का हिस्सा नहीं हैं, तो क्या वे वास्तव में वहां रहना चाहिए?
धन्यवाद,
बेन
यह देखने का एक और तरीका यह हो सकता है कि आपके पास एक अलग "कॉन्फ़िगरेशन" या "सेटिंग्स" बाध्य संदर्भ हो। यह एक तार्किक अलगाव है, भौतिक नहीं। इस प्रकार आप अभी भी विभिन्न तकनीक (क्लाइंट बनाम सर्वर) का उपयोग कर संदर्भ प्रदान करने का पीछा कर सकते हैं। हालांकि, ऐसा करने के लिए सभी कोड संदर्भ से संबंधित हैं। –
@YvesRenout यह वह मार्ग है जिस पर हम आगे बढ़ रहे थे, जिसमें कॉन्फ़िगरेशन संदर्भ है जिसके साथ हम बातचीत करते हैं। हालांकि हमने कॉन्फ़िगरेशन ऑब्जेक्ट्स को साझा किया था - इस मामले में, अलगाव ने कोड के अनावश्यक डुप्लिकेशन को आसानी से जन्म दिया होगा। –
ओह, लेकिन तार्किक अलगाव कोड डुप्लिकेशन का कारण नहीं है। इसका मतलब है कि बाध्य संदर्भ कोड के लिए ज़िम्मेदार है। बाध्य संदर्भ का कोड कैसे तैनात किया जाता है, उस तथ्य के लिए पूरी तरह से ऑर्थोगोनल है (इसे अन्य बाध्य संदर्भों के कोड के साथ पूरी तरह से एक प्रक्रिया के अंदर होस्ट किया जा सकता है)। –