2015-09-05 8 views
8

प्लुरसाइट कोर्स Domain-Driven Design Fundamentals में, एक उदाहरण है कि कुल मिलाकर डिज़ाइन आकार कैसे लेता है। उदाहरण में क्लिनिक में रोगी नियुक्तियां शामिल हैं। नियुक्ति के संबंध हैं उदाहरण एक डॉक्टर, या एक परीक्षा कक्ष में। और उदाहरण पहले एक विश्लेषण द्वारा निष्कर्ष निकाला गया है कि नियुक्ति डॉक्टर और परीक्षा के लिए एक समग्र जड़ नहीं होनी चाहिए। और डिज़ाइन विकास में एक कदम नियुक्ति से जा रहा है जिसमें डॉक्टर और परीक्षा रूम ऑब्जेक्ट्स के ऑब्जेक्ट संदर्भ हैं, इन अन्य इकाइयों, डॉक्टर आईडी और परीक्षा RoomId के आदिम आईडी को रखने के लिए। वे यह कहते हुए इस परिवर्तन को प्रेरित करते हैं: "ऑब्जेक्ट संदर्भों के बजाय संबंधित अवधारणाओं की आईडी को शामिल करके हम यह सुनिश्चित करने में सक्षम हैं कि नियुक्ति को बदलने और बदलने पर हमारे सिस्टम पर कम प्रभाव पड़ता है जब हम अपनी नियुक्ति जारी रखते हैं"डीडीडी समेकन में आईडी द्वारा ऑब्जेक्ट रेफरेंस बनाम संदर्भ

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

मेरा दूसरा प्रश्न: क्या डीडीडी के साथ ऐसा कुछ भी है? मेरा मतलब यह है कि नियुक्ति डॉक्टर की कुल जड़ नहीं होनी चाहिए, इसका मतलब यह नहीं है कि इसमें ऑब्जेक्ट संदर्भ नहीं हो सकते हैं, या क्या मुझे कुछ याद आ रहा है?

+0

पहले यही प्रश्न था और तीन श्रृंखला श्रृंखला के कुल डिजाइन ने कुछ प्रकाश डाला था। लेकिन मैं विकल्पों को जानने के लिए विषय की समीक्षा कर रहा हूं और नियम तोड़ना ठीक है :) –

उत्तर

5
  1. मुझे लगता है कि यह कम से कम डीडीडी ब्रह्मांड में एक आम डिजाइन पैटर्न है। इवांस DDD में कहते हैं:

जड़ समग्र के एकमात्र सदस्य है कि बाहर की वस्तुओं

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

समेकन की अवधारणा को बेहतर ढंग से समझने के लिए this QA पर एक नज़र डालें। व्यक्तिगत रूप से मुझे आश्वस्त है कि स्पष्ट रूप से परिभाषित कुल सीमाएं आपके वास्तुकला में सुधार करती हैं।

  1. यदि आप कुल सीमाओं को लागू करते हैं, तो आपके अपॉइंटमेंट प्रकार में डॉक्टर के प्रत्यक्ष ऑब्जेक्ट संदर्भ नहीं होंगे।

अद्यतन: वॉन वेरनॉन बात करती है के बारे में rules that spell out the current consensus view of DDD leaders on the style of aggregates (भाग द्वितीय देखें):

[DDD] कहा गया है कि एक कुल अन्य समुच्चय की जड़ के लिए संदर्भ पकड़ सकता है। हालांकि, हमें यह ध्यान में रखना चाहिए कि यह की स्थिरता सीमा के अंदर संदर्भित कुल स्थान को संदर्भित करता है। संदर्भ केवल एक, कुल योग का गठन नहीं करता है।

वह जारी है:

आप एक ही लेन-देन में कई उदाहरण को संशोधित कर रहे हैं, तो यह एक मजबूत संकेत है कि आपके स्थिरता सीमाओं गलत हैं हो सकता है। यदि ऐसा है, तो यह संभवतः एक मिस्ड मॉडलिंग अवसर है; आपकी सर्वव्यापी भाषा की एक अवधारणा अभी तक नहीं खोजी गई है, हालांकि यह अपने हाथों से चिल्ला रही है और आप पर चिल्ला रही है (भाग I देखें)।

मेरी समझ में नियुक्ति को डॉक्टर की तरह अन्य कुल जड़ों के प्रत्यक्ष ऑब्जेक्ट संदर्भ नहीं रखना चाहिए।

+0

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

+1

लेकिन प्रस्तुति पर, आपको हमेशा डॉक्टर और कमरे के नाम की आवश्यकता होती है। मुझे लगता है कि अतिरिक्त पठन मॉडल बहुत काम है। उस पर कोई सुझाव? –

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