डोमेन-संचालित डिजाइन

Question

में बाध्य संदर्भों में इकाइयां मैं समझने की कोशिश कर रहा हूं कि कई बाध्य संदर्भों में संस्थाएं कैसे काम करती हैं।

किसी कंपनी के कर्मचारी को देखते हुए। (उदाहरण के लिए) मानव संसाधन संदर्भ में, इस व्यक्ति का नाम, उपनाम, पता, वेतन संदर्भ संख्या, और बैंक खाता है। लेकिन लेखांकन संदर्भ में जो प्रासंगिक है वह वेतन संदर्भ संख्या और बैंक खाता है।

क्या आपके पास लेखा संदर्भ में एचआर संदर्भ में एक कर्मचारी इकाई और मूल्य-प्रकार (उदा। SalariedEmployee) है?

class Employee 
{ 
    public BankAccount BankAcountDetails { get; set; } 
    public string FullName { get; set; } 
    public Address ResidentialAddress { get; set; } 
    public string SalaryRef { get; set; } 
} 

SalariedEmployee वर्ग (??): कर्मचारी का मूल्य प्रकार

class SalariedEmployee 
{ 
    public SalariedEmployee(string salaryRef, BankAccount bankAcountDetails) 
    { 
     ... 
    } 

    public string SalaryRef { get; } 
    public BankAccount BankAcountDetails { get; } 
} 

घिरे संदर्भ में HRService इस जानकारी वापसी करता है? या आप दोनों संदर्भों में कर्मचारी वर्ग का उपयोग करते हैं?

Answer 1

मुझे लगता है कि मैं दोनों संदर्भ में एक ही इकाई का उपयोग नहीं करूंगा। उन्हें बाध्य किया जाना चाहिए। क्या होगा यदि मुझे अपने कर्मचारी वर्ग को एक संदर्भ की जरूरतों के लिए बदलना है? ... "संदर्भित होना चाहिए" अब सीमाबद्ध नहीं है।

मैं एक मूल्य वस्तु का उपयोग करूंगा। यह चाल उचित रूप से मूल्य वस्तु को परिभाषित करना है। मैं देखता हूं कि वे "डेटा प्रकार" ऑब्जेक्ट के बराबर हैं, जैसे पूर्णांक एक पूर्णांक है। यह निश्चित रूप से चुनौतीपूर्ण है (int16, int32 ...)। लेकिन मान लें कि यह मामला है। क्या कर्मचारी मूल्य वस्तु के लिए एक अच्छा उम्मीदवार है? .... मुझे ऐसा नहीं लगता है: (... आपको कर्मचारी के संदर्भ में जानकारी के समान सेट की आवश्यकता नहीं हो सकती है। दूसरे नाम में कर्मचारी की पहचान जानकारी एक है बेहतर उम्मीदवार (पहला नाम, अंतिम नाम, middlename ...) यह आप बाध्य संदर्भ में पुन: उपयोग कर सकते हैं।

अब सेवा परत इस मूल्य वस्तु को वापस कर देगी? ... Personnaly मैं यह नहीं करना चाहूंगा। मैं यह करना पसंद करूंगा पुनर्प्रयोग Nhibernate में मेरे खजाने में परिभाषित किया। शेयरिंग मैपिंग या एक ही प्रक्षेपण/नक्शाकार वर्ग को बांटने।

आशा इस मदद करता है :)

Answer 2

यदि एक से अधिक संदर्भ आवश्यक हैं, निश्चित रूप से कुछ चीजों को कुछ संदर्भों में एक इकाई के रूप में मॉडलिंग किया जा सकता है और किसी अन्य मूल्य में वस्तु वस्तु के रूप में मॉडलिंग किया जा सकता है। किसी इकाई से किसी मान ऑब्जेक्ट में अनुवाद करना आमतौर पर सीधा होता है, लेकिन किसी मान ऑब्जेक्ट से किसी इकाई तक इतना सरल नहीं हो सकता है। Domain Driven Design से, पी। 337:

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

मानव संसाधन संदर्भ कभी लेखा संदर्भ एक विशेष कर्मचारी के बारे में एक सवाल पूछने की जरूरत है, यह एक भ्रामक सवाल बन जाएगा ।

Answer 3

वे सख्ती से अलग हैं, तो मैं उन्हें कड़ाई से अलग होगा। विभिन्न नामस्थानों में दो अलग-अलग वर्ग। प्रत्येक में अलग-अलग गुण होते हैं।

यदि एचआर एक एचआरएम बनाता है। कर्मचारी, एक घटना उठाई जा सकती है कि लेखांकन चुनता है और एक लेखा बनाता है। कर्मचारी।

Answer 4

http://msdn.microsoft.com/en-us/library/jj554200.aspx से:

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

आप एक घिरे संदर्भ में CQRS pattern कार्यान्वित कर रहे हैं, तो आप संचार के इस प्रकार के लिए घटनाओं का उपयोग करना चाहिए: अपने घिरा संदर्भ घटनाओं घिरे संदर्भ के बाहर उठाया जाता है का जवाब कर सकते हैं, और अपने घिरा संदर्भ घटनाओं प्रकाशित कर सकते हैं कि अन्य बाध्य संदर्भों की सदस्यता ले सकते हैं। घटनाक्रम (एक तरफा, असिंक्रोनस संदेश जो पहले से ही हो चुके कुछ के बारे में जानकारी प्रकाशित करते हैं), आपको अपने बाध्य संदर्भों के बीच ढीले युग्मन को बनाए रखने में सक्षम बनाता है।