डोमेन संचालित डिज़ाइन: बहुत से डेटा फ़ील्ड वाले जटिल मॉडल से कैसे निपटें?

Question

वैसे मैं अपने एप्लिकेशन के लिए डोमेन संचालित डिज़ाइन सिद्धांतों को लागू करने की कोशिश कर रहा हूं, एक समृद्ध डोमेन मॉडल जिसमें डेटा फ़ील्ड और व्यावसायिक तर्क दोनों शामिल हैं। मैंने कई डीडीडी किताबें पढ़ी हैं, लेकिन ऐसा लगता है कि उनके डोमेन मॉडल (इकाइयों कहा जाता है) बहुत ही सरल हैं।

class Job extends DomainModel{ 

    protected int id; 
    protected User employer; 
    protected string position; 
    protected string industry; 
    protected string requirements;  
    protected string responsibilities;  
    protected string benefits; 
    protected int vacancy; 
    protected Money salary; 
    protected DateTime datePosted; 
    protected DateTime dateStarting; 
    protected Interval duration; 
    protected String status; 
    protected float rating; 

    //business logic below 
} 

जैसा कि आप देख, इस डोमेन मॉडल डेटा फ़ील्ड का एक बहुत होते हैं, और उन सभी को महत्वपूर्ण हैं: जब मैं इस तरह के नीचे एक के रूप में 10-15 डेटा फ़ील्ड, के साथ एक डोमेन मॉडल है यह एक समस्या बन जाता है और दूर नहीं किया जा सकता है। मुझे पता है कि एक अच्छे समृद्ध डोमेन मॉडल में सेटर विधियों को शामिल नहीं किया जाना चाहिए, बल्कि इसके डेटा को कन्स्ट्रक्टर को पास करना चाहिए, और व्यवसाय तर्क का उपयोग करके राज्यों को बदलना चाहिए। हालांकि, उपरोक्त डोमेन मॉडल के लिए, मैं सबकुछ कन्स्ट्रक्टर को पास नहीं कर सकता, क्योंकि इससे कन्स्ट्रक्टर विधि में 15+ पैरामीटर होंगे। एक विधि में 6-7 से अधिक पैरामीटर नहीं होना चाहिए, आपको नहीं लगता?

तो मैं कई डेटा फ़ील्ड वाले डोमेन मॉडल से निपटने के लिए क्या कर सकता हूं? क्या मुझे इसे विघटित करने की कोशिश करनी चाहिए? यदि हां, तो कैसे? या शायद, मुझे केवल एक बिल्डर क्लास या प्रतिबिंब का उपयोग तत्कालता पर अपनी संपत्तियों को शुरू करने के लिए करना चाहिए, इसलिए मैं इतने सारे तर्कों के साथ कन्स्ट्रक्टर को प्रदूषित नहीं करूंगा? क्या कोई सलाह दे सकता है? धन्यवाद।

Answer 1

जो आपने याद किया है वह वैल्यू ऑब्जेक्ट की अवधारणा है। मूल्य वस्तुएं संबंधित डोमेन में अर्थ के साथ छोटी, अपरिवर्तनीय वस्तुएं होती हैं।

मैं आपके डोमेन की बारीकियों पता नहीं है, लेकिन अपने Job इकाई को देखते हुए, वहाँ एक मूल्य वस्तु JobDescription कि इस तरह दिखता है हो सकता है:

class JobDescription { 
    public JobDescription(string position, string requirements, string responsibilities) { 
     Position = position; 
     Requirements = requirements; 
     Responsibilities = responsibilities; 
    } 

    public string Position {get;} 
    public string Requirements {get;} 
    public string Responsibilities {get;} 
} 

यह सी # कोड है, लेकिन मुझे लगता है कि आप जिस भाषा का उपयोग कर रहे हैं उसके बावजूद विचार स्पष्ट होना चाहिए।

मूल विचार समूह मानों को इस तरह से है जो संबंधित डोमेन में समझ में आता है। इसका मतलब यह है कि मूल्य वस्तुओं में अन्य मूल्य वस्तुएं भी हो सकती हैं।

आपको यह भी सुनिश्चित करना चाहिए कि मूल्य वस्तुओं को संदर्भ के बजाय मूल्य से तुलना की जाती है, उदा। सी # में IEquatable<T> लागू करके।

यदि आप इस दृष्टिकोण के साथ अपने कोड को दोबारा प्रतिक्रिया देते हैं, तो आपको अपनी इकाई पर कम फ़ील्ड मिलेंगे, इसलिए कन्स्ट्रक्टर इंजेक्शन (जिसे अत्यधिक अनुशंसा की जाती है) का उपयोग करके फिर से व्यवहार्य हो जाता है।

---

अपने उदाहरण कोड के बारे में आगे कहते हैं कि सीधे सवाल से जुड़े नहीं हैं:

• डोमेन मॉडल पूरी बात है, एक इकाई यह का हिस्सा है। तो आपकी बेस क्लास को Entity कहा जाना चाहिए और DomainModel नहीं होना चाहिए।

• आपको अपनी कक्षा private के क्षेत्र बनाना चाहिए और protected एक्सेसर्स प्रदान करना चाहिए जहां encapsulation बनाए रखने की आवश्यकता है।

Answer 2

वहाँ एक भयंकर बहुत अपनी नौकरी डोमेन मॉडल वस्तु में चल रहा है - (मेरे लिए कम से कम) यह चिंताओं में से एक बड़ी संख्या मिश्रण करने लगता है, और घिरे संदर्भों की एक संख्या से पता चलता है, जिनमें से कुछ करने के लिए आसान कर रहे हैं उदाहरण बनाने के लिए समझें।

1. पारिश्रमिक (वेतन, लाभ)
2. संगठनात्मक स्थिति (रिपोर्टिंग लाइन)
3. व्यक्ति कल्पना (कौशल)
4. नौकरी विनिर्देश (जिम्मेदारियों)
5. आदि

जब आप उन चीज़ों पर विचार करें जो आपके 'जॉब' मॉडल से बातचीत करते हैं, क्या कोई ऐसी है जिसके लिए परीक्षा के लिए वेतन संपत्ति और उद्योग संपत्ति का निरीक्षण या उत्परिवर्तन करना आवश्यक है मिसाल?

डोमेन की पूर्ण बारीकियों को जानने के बिना, आप जिस स्थिति में काम करते हैं, वह वेतन और वास्तव में आप जिस उद्योग में काम करते हैं, वह वास्तव में जुड़े नहीं हैं, है ना? एक उदारवादी बिंदु नहीं; ये वे प्रश्न हैं जिन्हें आपको डोमेन विशेषज्ञों से पूछने की आवश्यकता है।

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

जीवन बीमा के बारे में सोचें कि एक व्यक्ति कैसे कर्मचारी बनता है; एक व्यक्ति नौकरी के लिए आवेदन करता है। नौकरी में एक विनिर्देश, वेतन सीमा है। व्यक्ति एक साक्षात्कार में भाग लेता है। किरायेदार व्यक्ति को स्थिति की पेशकश करते हैं। व्यक्ति स्वीकार करता है। व्यक्ति अब एक कर्मचारी है, उम्मीदवार नहीं है। नया कर्मचारी अब छुट्टी और लाभ अर्जित कर रहा है और इसकी शुरुआत तिथि आदि है।

डीडीडी हमें सिखाता है कि दुनिया का एक एकल, एकीकृत दृश्य शायद ही कभी किसी भी चिंताओं को सही तरीके से सेवा देता है। कृपया BOUNDED CONTEXTS का पता लगाएं - परिणामस्वरूप आपका सॉफ़्टवेयर अधिक व्यवहार्य और लचीला होगा।