डीडीडी और कॉन्फ़िगरेशन

Question

मैं डीडीडी में उपयोगकर्ता कॉन्फ़िगरेशन सेटिंग्स तक पहुंच कैसे प्राप्त करूं?

हमारे पास एक कॉन्फ़िगरेशन डेटाबेस है जो आइटम को कुंजी-मूल्य जोड़े के समूह के रूप में संग्रहीत करता है। यह वास्तव में रिपोजिटरी पैटर्न में फिट नहीं प्रतीत होता है, तो मैं उपयोगकर्ता को इन कॉन्फ़िगरेशन मानों तक पहुंचने में सक्षम कैसे करूं?

आदर्श रूप में मैं कॉन्फ़िगरेशन के विभिन्न समूहों के लिए अलग-अलग कक्षाएं रखना चाहता हूं, यानी .. बिलिंग सेटिंग, रिपोर्ट सेटिंग्स, कर सेटिंग।

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

डीडीडी में कॉन्फ़िगरेशन तक पहुंच को सक्षम करने का सही तरीका क्या है?

Answer 1

जो मैं आम तौर पर करता हूं वह इंटरफ़ेस का उपयोग करके कॉन्फ़िगरेशन को सार तत्व बनाता है, उदा। IBillingConfiguration, IReportConfiguration, आदि। इनके कार्यान्वयन तब प्रासंगिक तरीकों (या प्रासंगिक वस्तुओं में इंजेक्शन) में पारित होते हैं।

जहां मूल्य आता है तो वास्तव में कोई फर्क नहीं पड़ता। ऐसे समय होते हैं जब मैं डेटाबेस में मान संग्रहीत करते समय एक भंडार का उपयोग करता हूं और फिर मेरे पास IConfigurationPropertyRepository जैसा कुछ होगा। ConfiruationProperty एंटिटी दुनिया में प्रथम श्रेणी के नागरिक की तरह महसूस नहीं करता है, लेकिन ऐसा लगता है कि यह काम पूरा हो रहा है, लेकिन यह कुछ अजीब फिट है।

मैं IBillingConfiguration के कुछ कार्यान्वयन को वापस कर दूंगा जो केवल अंतर्निहित संग्रह या ConfigurationProperty ऑब्जेक्ट्स से आवश्यक संपत्ति प्राप्त करता है।

प्रासंगिक Get और Save प्रत्येक I{Some}Configuration के लिए तरीके ConfigurationPropertyRepository पर लागू किया जाएगा ताकि मैं केवल मिल/गुण लागू किया जाना चाहिए कि उस सबसेट को बचाने।

Answer 2

क्या बिलिंग डोमेन वास्तव में आपके डोमेन मॉडल में एक कुल (या यहां तक ​​कि एक डोमेन ऑब्जेक्ट) है? यदि नहीं, तो यह एक संबंधित भंडार नहीं होना चाहिए।

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

@ क्रिस्टोफ जोज़सा की टिप्पणी के लिए अद्यतन।

सेटिंग्स का उपयोग डोमेन अवधारणा का समर्थन करने के लिए किया जाता है। डोमेन अवधारणा सार है, और सेटिंग्स का उपयोग कैसे करें एक कार्यान्वयन विवरण है। आपको एक उदाहरण देता है कि कैसे एक व्यवसाय शब्द "समाप्ति" और इस जैसे के लिए एक प्रणाली-विन्यास मूल्य के बारे में -

class ExpirationSpecification { 
    private int days 
    //other settings?   

    public ExpirationSpecification(int days) {...} 

    public boolean isSatisfied(Order order) {...} 
} 

public class ExpirationServiceImpl implements ExpirationService { 
    //private int days;//inject using placeholder in spring 
    private ConfigurationService configService;//if settings are stored in database 

    ExpirationSpecification spec() { 
     //return new ExpirationSpecification(days); 
     return new ExpirationSpecification(configService.orderExpirationDays()); 
    } 

    void cancel(Order order) {...} 
}