डीडीडी इनवेरिएंट्स बिजनेस नियम और सत्यापन

Question

मैं डोमेन संस्थाओं के लिए सत्यापन नियम जोड़ने और कार्यान्वयन के लिए सर्वोत्तम प्रथाओं को कहां पर सलाह ले रहा हूं, इस बारे में सलाह ले रहा हूं। मैंने खोज की और मुझे वह नहीं मिला जो मैं ढूंढ रहा था, या मुझे याद आया।

मैं जानता हूँ कि एक सुझाया गया तरीका मान्य है कि गुण, अशक्त नहीं हैं एक निश्चित सीमा, या लंबाई, आदि में ... मैं में लागू करने के बारे में) एक अगर है (का उपयोग कर कई तरीके और अन्य विचार विमर्श देखा है के लिए क्या है चाहते हैं कन्स्ट्रक्टर ताकि इकाई कभी भी अमान्य स्थिति में न हो, या प्रीप्रोकैसिंग और पोस्टप्रोसेसिंग का उपयोग कर, और फ्लुएंट वैलिडेशन एपीआई का उपयोग करने वाले अन्य लोग, कैसे आविष्कार डीआरवाई और एसआरपी को प्रभावित करते हैं।

क्या कोई मुझे ऐप सेवा, बाउंड कंटेक्स्ट, डोमेन सेवा, कुल रूट, इकाई लेयरिंग का उपयोग करते समय, इस प्रकार के चेक कहां रखना है, का एक अच्छा उदाहरण दे सकता है। यह कहां जाता है, और सबसे अच्छा तरीका क्या है?

धन्यवाद।

Answer 1

अपनी डोमेन इकाई को मॉडलिंग करते समय, वास्तविक दुनिया के प्रभावों पर विचार करना सबसे अच्छा है। मान लीजिए कि आप Employee इकाई से निपट रहे हैं।

कर्मचारी एक नाम

हम जानते हैं कि वास्तविक दुनिया में एक कर्मचारी हमेशा एक नाम होना आवश्यक है की जरूरत है। किसी कर्मचारी के पास नाम नहीं होना असंभव है। दूसरे शब्दों में, कोई व्यक्ति अपना नाम निर्दिष्ट किये बिना किसी कर्मचारी को 'निर्माण' नहीं कर सकता है। तो, पैरामीटरयुक्त कन्स्ट्रक्टर का उपयोग करें! हम यह भी जानते हैं कि एक कर्मचारी का नाम बदल नहीं सकता है - इसलिए हम इसे एक निजी सेटर बनाकर भी होने से रोकते हैं। अपने कर्मचारी को सत्यापित करने के लिए .NET प्रकार सिस्टम का उपयोग करना सत्यापन का एक बहुत ही मजबूत रूप है।

public string Name { get; private set; } 

public Employee(string name) 
{ 
    Name = name; 
} 

मान्य नाम कुछ नियम

अब यह दिलचस्प पाने के लिए शुरू होता है है। एक नाम के कुछ नियम हैं। आइए बस सरल मार्ग लें और मान लें कि एक मान्य नाम वह है जो शून्य या खाली नहीं है। उपरोक्त कोड उदाहरण में, निम्नलिखित व्यवसाय नियम के विरुद्ध मान्य नहीं है। इस बिंदु पर, हम अभी भी अमान्य कर्मचारियों को बना सकते हैं! के कभी हमारे सेटर में संशोधन से होने से रोकने करते हैं:

public string Name 
{ 
    get 
    { 
     return name; 
    } 
    private set 
    { 
     if (String.IsNullOrWhiteSpace(value)) 
     { 
      throw new ArgumentOutOfRangeException("value", "Employee name cannot be an empty value"); 
     } 

     name = value; 
    } 
} 

व्यक्तिगत तौर पर मैं निर्माता की तुलना में निजी सेटर में इस तर्क के लिए पसंद करते हैं। सेटर पूरी तरह से अदृश्य नहीं है। इकाई स्वयं भी इसे बदल सकती है, और हमें वैधता सुनिश्चित करने की आवश्यकता है। इसके अलावा, हमेशा अपवाद फेंक दो!

IsValid() विधि के कुछ रूपों को उजागर करने के बारे में क्या?

उपर्युक्त Employee इकाई ले लो। IsValid() विधि कार्य कहां और कैसे होगा?

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

लेकिन शायद आप नाम सत्यापन तर्क का पर्दाफाश करना चाहते हैं?

हम नियंत्रण प्रवाह के लिए अपवाद नहीं लेना चाहते हैं। अपवाद प्रणाली की विफलता के लिए अपवाद हैं।हम अपने कोडबेस में इन सत्यापन नियमों को डुप्लिकेट नहीं करना चाहते हैं। तो, शायद इस सत्यापन तर्क को उजागर करना इतना बुरा विचार नहीं है (लेकिन अभी भी महानतम नहीं है!)।

public static bool IsValidName(string name) 
{ 
    return (String.IsNullOrWhiteSpace(value)) 
} 

हमारी संपत्ति अब कुछ हद तक बदल जाएगा:

तुम कर सकते हो क्या एक स्थिर IsValidName(string) तरीका प्रदान है

public string Name 
{ 
    get 
    { 
     return name; 
    } 
    private set 
    { 
     if (!Employee.IsValidName(value)) 
     { 
      throw new ArgumentOutOfRangeException("value", "Employee name cannot be an empty value"); 
     } 

     name = value; 
    } 
} 

लेकिन इस डिजाइन के बारे में संभवत: कुछ गलत है ...

अब हम अपनी इकाई के व्यक्तिगत गुणों के लिए सत्यापन विधियों को शुरू करना शुरू कर रहे हैं। यदि किसी संपत्ति में सभी प्रकार के नियम और व्यवहार शामिल हैं, तो शायद यह एक संकेत है कि हम इसके लिए एक मूल्य वस्तु बना सकते हैं!

public PersonName : IEquatable<PersonName> 
{ 
    public string Name 
    { 
     get 
     { 
      return name; 
     } 
     private set 
     { 
      if (!PersonName.IsValid(value)) 
      { 
       throw new ArgumentOutOfRangeException("value", "Person name cannot be an empty value"); 
      } 

      name = value; 
     } 
    } 

    private PersonName(string name) 
    { 
     Name = name; 
    } 

    public static PersonName From(string name) 
    { 
     return new PersonName(name); 
    } 

    public static bool IsValid(string name) 
    { 
     return !String.IsNullOrWhiteSpace(value); 
    } 

    // Don't forget to override .Equals 
} 

अब हमारे Employee इकाई सरल किया जा सकता (मैं एक अशक्त संदर्भ जाँच बाहर रखा गया है):

public Employee 
{ 
    public PersonName Name { get; private set; } 

    public Employee(PersonName name) 
    { 
     Name = name; 
    } 
} 

हमारे ग्राहक कोड अब कुछ इस तरह देख सकते हैं:

if(PersonName.IsValid(name)) 
{ 
    employee = new Employee(PersonName.From(name)); 
} 
else 
{ 
    // Send a validation message to the user or something 
} 

तो हमने यहाँ क्या किया है?

हमने यह सुनिश्चित किया है कि हमारा डोमेन मॉडल हमेशा सुसंगत रहेगा। अत्यंत महत्वपूर्ण। एक अवैध इकाई नहीं बनाई जा सकती है। इसके अलावा, हमने आगे 'समृद्धि' प्रदान करने के लिए मूल्य वस्तुओं का उपयोग किया है। PersonName ने क्लाइंट कोड को अधिक नियंत्रण और अधिक शक्ति दी है और Employee को भी सरल बना दिया है।

Answer 2

मैंने एक लाइब्रेरी बनाई है जो आपकी मदद कर सकती है।

https://github.com/mersocarlin/ddd-validation