डीडीडी

Question

में इकाइयों के बीच संबंध मैं डिजाइन के सभी सिद्धांतों पर अपना सिर प्राप्त करने के लिए छोटे, सरल डोमेन के आसपास काम कर रहा हूं, डीडीडी पर एक नौसिखिया हूं।

मेरे पास यह सरल डोमेन है: संस्थान (Institution) और उनके उपलब्ध वाईफाई स्पॉट (Place) डेटाबेस में रखे जाते हैं। एक संस्था के बिना कोई जगह मौजूद नहीं हो सकती है। संस्थान में प्रबंधक उपयोगकर्ता - असाइनर (User) है, जिसके पास नए स्थान जोड़ने, मौजूदा स्थान को पुन: आवंटित करने या हटाने का अधिकार है।

Code can be found here। मूल्य वस्तुओं पर सत्यापन अब के लिए पीछे छोड़ दिया गया है।

यह Mathias Verraes on child entities से प्रभावित है।

क्या यह एक सही डीडीडी डिजाइन है? या कम से कम इसके करीब?

डेटा-केंद्रित प्रोग्रामर होने के बावजूद, मुझे अभी भी आश्चर्य है कि अगर मैं अंगूठे का नियम कुल रूट के माध्यम से समेकन तक पहुंच रहा हूं, तो मैं सभी संस्थानों के लिए सभी जगहों को कैसे सूचीबद्ध करूं?

क्या इकाई के अंदर Uuid उत्पन्न करने का विचार है (Place::create) अच्छा?

क्या एक विचार होना चाहिए, केवल असाइनी (User) डोमेन को स्वयं ही डोमेन पर व्यक्त/हटाया जा सकता है या यह ग्राहक की ज़िम्मेदारी होनी चाहिए? इस मामले में यह बुद्धिमान होगा यदि असाइनर को अपने प्रबंधित संस्थान (institutionIdUser में) के बारे में पता चलेगा?)।

Institution::placeById डीडीडी के किसी भी सिद्धांत को तोड़ने नहीं है? शायद यह भंडार की ज़िम्मेदारी है?

Answer 1

कुल रूट नियम केवल लेखन पक्ष पर लागू होता है। यदि समर्पित पठन मॉडल है तो यह समस्या दूर हो जाएगी। आप अपने उपयोगकर्ता परिदृश्य के अनुकूल मॉडल को पढ़ने के लिए प्रोजेक्ट करने के लिए स्वतंत्र हो जाते हैं।

अन्यथा आप संस्थानों से सभी स्थानों को एक हैश में जोड़ सकते हैं जो एक लौटा हुआ सूची है।

जब समग्र जड़ें डिज़ाइनिंग अद्यतन परिदृश्य के बारे में सोचती हैं। संस्थान से स्वतंत्र रूप से अद्यतन किया जा सकता है? अगर हाँ। तो यह अपने आप की एक समग्र जड़ हो सकती है।

आम तौर पर भंडार को अगले आईडी निर्धारित करना चाहिए।

अनुमतियों की एक सूची वाली भूमिकाओं के माध्यम से उपयोगकर्ता अधिकारों को व्यक्त करें प्रत्येक विधि प्रेषक को पास करती है और विधियों के भीतर पहुंच की जांच करती है। यह एक्सेस अधिकारों के आसान परीक्षण की भी अनुमति देता है।