2013-06-04 8 views
5

हम पहली बार हमारी परियोजना में डोमेन-संचालित डिजाइन को अपनाने की कोशिश कर रहे हैं। मेरे पास समस्याएं संस्थाओं के बीच संघों के साथ है। आप उन्हें सही कैसे करते हैं?डीडीडी में संघों को लागू करने का सही तरीका?

कहें, मुझे Employee और Contract मिल गया है, जो कि एक साधारण से-कई संगठन हैं। मैं इसे कैसे मॉडल करूं?

विकल्प 1: कुल।

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

विकल्प 2: भंडार (जैसे ContractRepository.GetContractsForEmployee()) का उपयोग कर और Contract वर्ग के लिए EmployeeId संपत्ति जोड़कर एक कर्मचारी के ठेके ला रहा है।

समस्या: यह किसी भी व्यावसायिक तर्क को संस्थाओं में रखना मुश्किल बनाता है। मैं एक विधि कहना चाहूंगा, Employee.Dismiss(), लेकिन उसे कर्मचारी के अनुबंध को अपडेट करने की भी आवश्यकता होगी। इसका मतलब है कि मुझे इस तर्क को एक सेवा में रखना होगा। समस्या यह है कि, मैं केवल Employee पर अधिक तर्क परिचालन के बारे में नहीं सोच सकता और इस प्रकार मॉडल कुछ हद तक एनीमिक बन जाएगा, जिसमें अधिकांश तर्क सेवाओं के साथ।

डीडीडी में इन मुद्दों से आप कैसे निपटते हैं?

+1

एक बार जब आप 'सरल एक से कई संगठन' सोच रहे हैं तो आप डीडीडी नहीं कर रहे हैं, आप डेटाबेस स्कीमा डिज़ाइन कर रहे हैं। संस्थाओं के बीच संबंध व्यवहार होना चाहिए। एक कर्मचारी खुद को खारिज नहीं कर सकता है, इसे खारिज कर दिया जाना चाहिए (किसी अन्य इकाई द्वारा जिसके पास ऐसा करने का अधिकार है)। विकल्प 2 सही है। आपको एक संस्था के लिए बहुत सारे व्यवहार के साथ आने की ज़रूरत नहीं है। यदि वास्तविक व्यवसाय में कोई डोमेन ऑब्जेक्ट बहुत आसान है, तो इसे इस तरह से मॉडल करें। यह मायने रखता है कि डोमेन अवधारणा को परिभाषित करता है (अर्थशास्त्र) और ऑब्जेक्ट के कितने तरीकों से नहीं है। – MikeSW

+0

माइकएसडब्ल्यू सही है। डीडीडी का एक बहुत ही महत्वपूर्ण पहलू सर्वव्यापी भाषा है। जिस तरह से आप डोमेन के बारे में बात करते हैं, वह डोमेन विशेषज्ञ डोमेन के बारे में बोलने का तरीका होना चाहिए अन्यथा कोड अजीब और अनजान हो जाता है। यह मामूली लगता है लेकिन यदि आपको यह अधिकार मिलता है तो संस्थाएं व्यवहार का सुझाव देना शुरू कर देती हैं। जैसे Employee.Resign(); Contract.Terminate(); – Asher

उत्तर

2

यह सिर्फ मेरा लेना है ... आपके डोमेन को जानने के बिना।

पहला, here पढ़ने के लिए एक अच्छा संसाधन है (समेकन और रूट्स के बारे में हिस्सा)।

DDD शब्दावली में, Employee और Contract दोनों संस्थाएं हैं (क्योंकि वे दोनों एक पहचान है)। । प्रत्येक सकल एक रूट इकाई है, जो सकल का एकमात्र सदस्य है कि सकल बाहर किसी भी वस्तु के लिए एक संदर्भ पकड़ करने के लिए अनुमति दी है है:

"समुच्चय एक या अधिक संस्थाओं और भी चारों ओर एक सीमा बनाने के।"

सवाल यह है:? Employee जड़ इकाई जा रहा है जाहिर है नहीं, क्योंकि अन्य डोमेन संस्थाओं को भी एक contract के लिए एक संदर्भ हो सकता था के साथ एक समग्र Employee और Contract प्रपत्र करते हैं, और अनुबंध आईडी के विश्व स्तर पर अद्वितीय नहीं होते, । केवल

तो भीतर एक Customer, इन नियमों को ध्यान में रखते, Employee और Contract दोनों कुल जड़ों तो हैं

:। "केवल सकल जड़ें सीधे प्रश्नों के साथ प्राप्त किया जा सकता है; तो इसका मतलब यह है कि हम कुल जड़ प्रति भंडार होना चाहिए। "

इस मामले में

तो, हम एक EmployeeRepository और एक ContractRepository है।

खाते में यह सब ले रहा है, मैं के बीच एक रिश्ता जोड़ नहीं होगा कर्मचारियों और डोमेन मॉडल में ठेके, लेकिन उन्हें इलाज के लिए अलग से सब के बाद, अगर आप एक Employee की जरूरत है, वहीं यह आवश्यक नहीं उसकी contracts भी, वे दोनों हैं अलग-अलग पहलू की जरूरत नहीं है

विकल्प 2 है मैं क्या चुनना होगा।।: उन अनुबंधों को प्राप्त करने के लिए ContractRepository का उपयोग करें। और यदि आवश्यक हो तो आप सह uld एक डोमेन सेवा जोड़ें जो आवश्यकतानुसार कर्मचारियों और अनुबंधों को एकत्रित करने के लिए ज़िम्मेदार है।

यदि आप Company इकाई को भी परिभाषित करते हैं, तो कर्मचारी को खारिज करना उस इकाई का काम हो सकता है।

0

आपको अपने असली इनवेंटर्स को खोजने की ज़रूरत है।

यहां आपके पास एक invariant हो सकता है जैसे: आप Employee को बर्खास्त नहीं कर सकते हैं जिसे पहले से ही खारिज कर दिया गया है।

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

Contract एक और कुल (यदि आवश्यक हो) होगा।

यदि खारिज() विधि सफल हो जाती है, तो आप आवश्यक अनुबंध लोड कर सकते हैं और आवश्यक परिवर्तन कर सकते हैं।

1

हम हाल ही में डीडीडी दृष्टिकोण में भी शामिल हुए हैं। अगर मैं यह करने के लिए थे, मैं होता (विशेषताओं संक्षिप्तता के लिए सरल बनाया जाता है) के बाद:

public class Employee() { 

    String name; 
    Set<ContractNumber> contracts; 

    public void addContract(ContractNumber contractNumber) { 
     this.contracts.add(contractNumber); 
    } 

} 

public class Contract() { 
    ContractNumber contractNumber; 
    Date effectiveDate; 
} 

public class ContractNumber() { 
    String contractNumber; 
} 

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

जैसा कि अन्य उत्तरों में चर्चा की गई है, कर्मचारी और अनुबंध दोनों के लिए भंडार होंगे।

संबंधित मुद्दे