लगातार अज्ञानी डोमेन लेयर

Question

मेरी प्रोग्रामिंग भाषा सी # है। मुझे अपने डोमेन मॉडल के भीतर दृढ़ता अज्ञानता के बारे में एक प्रश्न है।

मान लेते हैं मैं बहुत की तरह एक व्यक्ति वर्ग मिल गया है दो:

public class Person 
{ 
    private string email; 

    public string Email 
    { 
     get { return email; } 
     set { email = value; } 
    } 

    public Person(string email) 
    { 
     this.email = email; 
    } 
} 

अब, मेरे डोमेन मॉडल के भीतर, वहाँ एक नियम है कि वहाँ एक ही ईमेल पते होने दो व्यक्तियों को नहीं किया जा सकता है। तो जब एक नए व्यक्ति को तुरंत चालू करते हैं, तो इसे ईमेल संपत्ति बदलने के साथ-साथ मान्य होने की आवश्यकता होती है। तो मैं सोच रहा था कि आप अज्ञान डोमेन परत को दृढ़ता से अपने भीतर इस तरह के सत्यापन को कैसे हल करेंगे। मैं वर्तमान में जो करता हूं वह व्यक्ति तत्कालता के लिए फैक्ट्री पैटर्न का उपयोग कर रहा है जिसमें मैं एक व्यक्ति भंडार इंजेक्ट करता हूं। वहां मैं एक ही ईमेल पते के साथ दूसरे व्यक्ति की तलाश कर सकता हूं। इसलिए जैसा:

public class PersonFactory 
{ 
    private static readonly IPersonRepository personRepository; 

    public Person CreateNewPerson(string email) 
    { 
     Person personWithSameMail = personRepository.GetPersonByEmail(email); 

     if (personWithSameMail != null) 
      throw new ApplicationException("Email already exists."); 

     return new Person(email); 
    } 

    public PersonFactory(IPersonRepository personRepository) 
    { 
     this.personRepository = personRepository; 
    } 
} 

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

इस के लिए कोई भी अभ्यर्थी समाधान?

पीएस

शायद इस पूरे प्रश्न अप्रचलित वैसे भी है:;: सभी डेटा केंद्रित लोगों के लिए)

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

Answer 1

मैं डीडीडी विशेषज्ञ नहीं हूं लेकिन मेरा लेना इस तरह है।

सबसे पहले, मेरे लिए आपके डिजाइन में सबसे बड़ी गड़बड़ी इकाई पर सेटर्स की अनुमति दे रही है। इसका मतलब है कि आप बदल सकते हैं आपकी इकाई की स्थिति कुल रूट के बिना इसके बारे में जानता है। मैं इसे सेटर्स को हटाने और ऑब्जेक्ट सृजन पर कन्स्ट्रक्टर के माध्यम से बस इसे सेट करने की प्रतिक्रिया देता हूं।

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

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

आपको क्या लगता है?