मुझे डीडीडी में एक अनूठी जांच कहां रखनी चाहिए?

Question

मैं अपनी पहली डीडीडी परियोजना पर काम कर रहा हूं, और मुझे लगता है कि मैं संस्थाओं, डेटा एक्सेस ऑब्जेक्ट्स और उनके रिश्ते की मूल भूमिकाओं को समझता हूं। मेरे पास एक मूल सत्यापन कार्यान्वयन है जो प्रत्येक सत्यापन नियम को इसके संबंधित इकाई के साथ संग्रहीत करता है। यह उन नियमों के लिए ठीक काम करता है जो केवल मौजूदा इकाई पर लागू होते हैं, लेकिन अन्य डेटा की आवश्यकता होने पर अलग हो जाते हैं। उदाहरण के लिए, यदि मेरे पास प्रतिबंध है कि उपयोगकर्ता नाम अद्वितीय होना चाहिए, तो मैं वर्तमान नाम के साथ मौजूदा उपयोगकर्ता होने पर IsValid() कॉल को झूठी वापसी करना चाहता हूं।

हालांकि, मुझे इस सत्यापन नियम को इकाई पर रखने के लिए कोई साफ तरीका नहीं मिल रहा है। मैं इकाई पर IsNameUnique फ़ंक्शन रखना चाहता हूं, लेकिन ऐसा करने के अधिकांश समाधानों के लिए मुझे उपयोगकर्ता डेटा एक्सेस ऑब्जेक्ट इंजेक्ट करने की आवश्यकता होगी। क्या यह तर्क बाहरी सेवा में होना चाहिए? यदि हां, तो मैं अभी भी तर्क को इकाई के साथ कैसे रखूं? या यह ऐसा कुछ है जो उपयोगकर्ता इकाई के बाहर होना चाहिए?

धन्यवाद!

Answer 1

डीडीडी में, वहां एक अवधारणा है जिसे aggregate कहा जाता है। यह मूल रूप से आवेदन के भीतर स्थिरता के लिए जिम्मेदार है।

आईएमएचओ, इस मामले में विशेष रूप से, मुझे लगता है कि कस्टमर रिपोजिटरी "ग्राहक कुल" जैसी कुछ चीज़ों के अंदर होगी, ग्राहक वर्ग कुल रूट होने के नाते।

रूट इन सभी चीजों को करने के लिए ज़िम्मेदार होगा, और कोई भी ग्राहक रिपॉजिटरी विकल्प तक नहीं पहुंच सकता है।

• CustomerRepository एक अपवाद है, तो नाम अनन्य नहीं है (और या ऐसा ही कुछ ग्राहक पकड़ और त्रुटि लौटानी चाहिए,)
• CustomerRepository एक IsValidUserName हो सकता था फेंक सकता है (: और वहाँ कुछ संभावनाएं हैं), कि ग्राहक किसी और
• कोई अन्य विकल्प कुछ भी करने से पहले कहेंगे आप

Answer 2

के बारे में सोच सकते हैं मैं शमूएल की प्रतिक्रिया पसंद है, लेकिन सादगी के लिए, मैं एक Specification को लागू करने की सिफारिश करेंगे। आप एक विशिष्टता बनाते हैं जो यह देखने के लिए एक बूलियन देता है कि कोई वस्तु कुछ मानदंडों को पूरा करती है या नहीं। विशिष्टता में IUserRepository इंजेक्ट करें, जांचें कि क्या उपयोगकर्ता उस नाम से पहले से मौजूद है या नहीं, और एक बूलियन परिणाम देता है।

public interface ISpecification<T> 
{ 
    bool IsSatisfiedBy(TEntity entity); 
} 

public class UniqueUsernameSpecification : ISpecification<User> 
{ 
    private readonly IUserRepository _userRepository; 

    public UniqueUsernameSpecification(IUserRepository userRepository) 
    { 
    _userRepository = userRepository; 
    } 

    public bool IsSatisfiedBy(User user) 
    { 
    User foundUser = _userRepository.FindUserByUsername(user.Username); 
    return foundUser == null; 
    } 
} 

//App code  
User newUser; 

// ... registration stuff... 

var userRepository = new UserRepository(); 
var uniqueUserSpec = new UniqueUsernameSpecification(userRepository); 
if (uniqueUserSpec.IsSatisfiedBy(newUser)) 
{ 
    // proceed 
} 

Answer 3

मैं यह कहने जा रहा हूं कि यह डीडीडी के दायरे से बाहर है।

डीडीडी के साथ आपके पास क्या है जो एक उपयोगी मॉडल उत्पन्न करने वाली घटनाओं का एकत्रीकरण है। हालांकि, ऐसे मॉडल के बीच डेटा संबंध जरूरी नहीं हैं।

आप किस स्थिरता मॉडल का उपयोग कर रहे हैं?

यदि आप एसीआईडी ​​लेनदेन में कई कार्यक्रम कर सकते हैं तो आप यह सुनिश्चित कर सकते हैं कि समेकन के समूह में परिवर्तन परमाणु रूप से हो।

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

विशिष्टता का संदर्भ किसी संदर्भ में दिया जाना चाहिए। यदि आप मॉडल छोटे हैं (हजारों में) आप कुल मूल्यों के सेट का प्रतिनिधित्व कर सकते हैं जिन्हें आप अद्वितीय बनाना चाहते हैं। एक समूह को कुल लेनदेन मानना ​​संभव है।

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

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