DDD को लागू करना: उपयोगकर्ता और अनुमतियाँ

Question

मैं एक छोटे से अनुप्रयोग पर काम कर रहा हूँ जो डोमेन-संचालित डिज़ाइन के सिद्धांतों को समझने की कोशिश कर रहा है। यदि सफल रहा, तो यह एक बड़ी परियोजना के लिए एक पायलट हो सकता है। मैं "इंप्लीमेंटिंग डोमेन-ड्रिवेन डिज़ाइन" पुस्तक (वॉन वर्नोन द्वारा) का पालन करने की कोशिश कर रहा हूं और एक समान, सरल चर्चा मंच को लागू करने की कोशिश कर रहा हूं। मैंने गिडब पर IDDD के नमूने भी जांचे हैं। मुझे अपने मामले की पहचान और पहुँच को अपनाने में कुछ कठिनाइयाँ हैं। मुझे कुछ पृष्ठभूमि की जानकारी दें:

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

• डोमेन संचालन को एक संबंधित भूमिका के साथ एक पैरामीटर के रूप में कहा जाता है: जैसे:

  ModeratePost( ..., moderator);

• डोमेन ऑब्जेक्ट की विधि यह जांचती है कि क्या दिए गए मॉडरेटर का उदाहरण शून्य नहीं है (यदि उपयोगकर्ता पहचान और एक्सेस के संदर्भ में मॉडरेटर की भूमिका नहीं करता है, तो मॉडरेटर का उदाहरण शून्य होगा)।

• एक मामले में, यह एक पोस्ट को बदलने से पहले एक अतिरिक्त जांच करता है:

  if (forum.IsModeratedby(moderator))

मेरे प्रश्न हैं:

• बाद के मामले में सुरक्षा चिंताओं को फिर से कोर डोमेन में मिश्रित नहीं किया गया है? पहले किताबें बताती हैं कि "कौन किसी विषय को पोस्ट कर सकता है, या किन शर्तों के तहत अनुमति दी जा सकती है। एक फोरम को बस यह जानना होगा कि एक लेखक अभी ऐसा कर रहा है"।

• पुस्तक में भूमिका आधारित कार्यान्वयन काफी सीधा है: जब एक मॉडरेटर एक कोर डोमेन होता है, तो वर्तमान उपयोगकर्ता को एक मॉडरेटर आवृत्ति में या एक लेखक को एक लेखक में बदलने की कोशिश करता है जब उसे इसकी आवश्यकता होती है। यदि उपयोगकर्ता की आवश्यक भूमिका नहीं है, तो सेवा उपयुक्त उदाहरण या अशक्त के साथ प्रतिक्रिया करेगी। हालाँकि, मैं यह नहीं देख सकता कि मैं इसे और अधिक जटिल सुरक्षा मॉडल में कैसे अनुकूलित कर सकता हूं; हमारे वर्तमान प्रोजेक्ट मैं समूहों, ACLs, आदि के साथ एक जटिल मॉडल है।

यहां तक ​​कि नियमों के साथ जो बहुत अधिक जटिल नहीं हैं, जैसे: "एक पोस्ट को केवल उसके स्वामी या संपादक द्वारा संपादित किया जाना चाहिए", यह दृष्टिकोण टूटने लगता है, या कम से कम मुझे इसे लागू करने का सही तरीका नहीं दिखता है।

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

कोर डोमेन के लिए अनुमतियों को खींचकर और डोमेन ऑब्जेक्ट्स या सेवाओं के तरीकों में उनकी जांच करके, मैं वर्ग एक पर समाप्त करूँगा: डोमेन के साथ सुरक्षा चिंताओं का मिश्रण।

मैंने कहीं पढ़ा है (और मैं इससे सहमत हूं) कि ये अनुमति संबंधित चीजें कोर डोमेन का हिस्सा नहीं होनी चाहिए, जब तक कि सुरक्षा और अनुमतियां कोर डोमेन ही न हों। क्या ऊपर दिया गया एक साधारण नियम सुरक्षा को मुख्य डोमेन का हिस्सा बनाने को सही ठहराता है?

Comments

शायद आप पा सकते हैं कि आपको यहां क्या चाहिए: stackoverflow.com/a/23485141/329660 इसके अलावा, सिर्फ इसलिए कि एक्सेस कंट्रोल संदर्भ एक संसाधन आईडी के बारे में जानता है, इसका मतलब यह नहीं है कि उस संसाधन के बारे में किस तरह का डोमेन ज्ञान है या वह क्या है कर देता है।

— गुइलूम 31

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

— LittlePilgrim

कम से कम उत्तर में कोड के नमूने न लें "मैं यह नहीं देख सकता कि मैं इसे और अधिक जटिल सुरक्षा मॉडल के लिए कैसे अनुकूलित कर सकता हूं" ?

— guillaume31

मेरी समस्या स्वयं सुरक्षा मॉडल के कार्यान्वयन के साथ नहीं है, मैं यह नहीं देख सकता कि मुझे इन जटिल नियमों को डोमेन में कैसे मैप करना चाहिए। यदि उपयोगकर्ता सुरक्षा पक्ष पर एक साधारण भूमिका आधारित मॉडल नहीं है, तो उपयोगकर्ता को कैसे बदलना चाहिए? संसाधन आईडी को अन्य संदर्भ में पास करना काम कर सकता है, जैसे कि HasPermissionToEdit(userId, resourceId)लेकिन मुझे इन कॉल के साथ डोमेन लॉजिक को दूषित करना सही नहीं लगता। संभवतः डोमेन लॉजिक को लागू करने से पहले मुझे एप्लिकेशन सेवा विधियों में इनकी जांच करनी चाहिए?

— LittlePilgrim

बेशक यह आवेदन सेवाओं में होना चाहिए ... मुझे लगा कि यह कोड के कुछ हिस्सों से स्पष्ट था जैसे UserService @AccessControlList[inf3rno]कि मैं जिस उत्तर से जुड़ा था।

— गुइलुमे 31

Answer 1

कभी-कभी वास्तविक अभिगम नियंत्रण नियमों और अभिगम नियंत्रण पर सीमावर्ती डोमेन आक्रमणकारियों के बीच अंतर करना मुश्किल होता है।

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

वॉन वर्नोन का assert (forum.IsModeratedBy(moderator))उदाहरण शायद डोमेन के बाहर होना चाहिए था, लेकिन यह हमेशा संभव नहीं है।

मुझे सुरक्षा के संदर्भ में न केवल userId, बल्कि संरक्षित संसाधन (पोस्ट, फ़ोरम, आदि की आईडी) की पहचान करने की आवश्यकता होगी, जो शायद इन बातों की परवाह नहीं करनी चाहिए (क्या यह सही है?)

यदि कोई सुरक्षा ई.पू. है और आप चाहते हैं कि वह उस तर्क को संभाल ले, तो उसे यह जानने की जरूरत नहीं है कि फोरम क्या है, लेकिन:

• यह सिर्फ "द्वारा संचालित" जैसी अवधारणाओं का ज्ञान हो सकता है और तदनुसार पहुँच अधिकार प्रदान या अस्वीकार कर सकता है।
• आपके पास एडाप्टर तर्क हो सकते हैं जो कोर डोमेन घटनाओं की सदस्यता लेते हैं और उन्हें सुरक्षा बीसी के स्टोर और उपयोग करने के लिए सरल (संसाधन, अधिकृत) कुंजी मूल्य जोड़े में अनुवाद करते हैं।

Comments

जैसा कि दोनों उत्तर उपयोगी हैं और कमोबेश उसी दिशा की ओर इशारा कर रहे हैं जो मैंने उन दोनों को उकेरा है। मैंने इसे स्वीकार कर लिया है, जैसा कि @ guillaume31 ने वर्नोन के कार्यान्वयन के बारे में मेरे प्रश्न का उत्तर दिया है और मैं सुरक्षा बीसी में संसाधनों का उपयोग करने के बारे में उनके संकेत के आधार पर अपने कार्यान्वयन को जारी रखूंगा।

— LittlePilgrim

मुझे कहना है कि मुझे लगता है कि यह मेरे उत्तर के पूर्ण विपरीत है।

— इवान

शायद मैं अब तक बहुत उलझन में हूं, लेकिन मेरी व्याख्या थी (दोनों उत्तरों के लिए): 1. सुरक्षा चिंताओं को डोमेन से बाहर रखें और सुरक्षा बीसी को सेवा के रूप में उपयोग करें 2. किसी भी डोमेन ऑब्जेक्ट को लागू करने से पहले सेवा को कॉल करें 3. सेवा उपयोगकर्ताओं / acls से मध्यस्थों, लेखकों, आदि के लिए मानचित्रण करेंगे। moderator = securityService.GetModerator(userId, forumId) 4. डोमेन लॉजिक को मॉडरेटर की तरह इन ऑब्जेक्ट्स में लागू किया जाएगा। EditPost () 5. EditPost जैसे तरीकों से सुरक्षा अवधारणाओं के बारे में कुछ भी पता नहीं चलेगा, कोई अतिरिक्त जांच नहीं होगी। वहाँ

— LittlePilgrim

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

— जॉर्डन

जब तक आपके पास एक बहुत ही जटिल सहयोगी संदर्भ है, तो आप शायद संस्करण का उपयोग करके यहां एक आशावादी संगामिति मॉडल को लागू करने का जोखिम उठा सकते हैं, लेकिन यदि आपके चेक किसी विशेष उदाहरण के भीतर या कम से कम नहीं किए जाते हैं, तो आपके चेक वास्तविक के अनुरूप होने में विफल हो सकते हैं। जब तक आप अपने परिवर्तन जारी रखते हैं, तब तक वस्तु की स्थिति।

— जॉर्डन

Answer 2

प्रमाणीकरण और प्राधिकरण DDD के लिए एक बुरा उदाहरण है।

जब तक आपकी कंपनी सुरक्षा उत्पाद नहीं बनाती है, तब तक इनमें से कोई भी चीज़ एक डोमेन का हिस्सा नहीं है।

व्यवसाय या डोमेन की आवश्यकता है, या होना चाहिए, "मुझे भूमिका आधारित प्रमाणीकरण की आवश्यकता है"

आप तब डोमेन फ़ंक्शन को कॉल करने से पहले भूमिका की जांच करते हैं।

जहाँ आपकी जटिल आवश्यकताएं हैं जैसे कि 'मैं अपने स्वयं के पदों को संपादित कर सकता हूं लेकिन दूसरों को नहीं' यह सुनिश्चित करें कि आपका डोमेन संपादन कार्य को अलग कर दे EditOwnPost()और EditOthersPost()ताकि आपके पास मैपिंग करने के लिए एक सरल कार्य हो

आप डोमेन ऑब्जेक्ट में कार्यक्षमता को भी अलग कर सकते हैं, जैसे कि Poster.EditPost()और Moderator.EditPost()यह एक अधिक ओओपी दृष्टिकोण है, हालांकि आपकी पसंद इस बात पर निर्भर कर सकती है कि आपका तरीका डोमेन सेवा या डोमेन ऑब्जेक्ट में है या नहीं।

हालाँकि आप उस कोड को अलग करने के लिए चुनते हैं जिसका रोल मैपिंग डोमेन के बाहर होगा। उदाहरण के लिए यदि आपके पास वेबपी नियंत्रक है:

PostController : ApiController
{
    [Authorize(Roles = "User")]
    public void EditOwnPost(string postId, string newContent)
    {
        this.postDomainService.EditOwnPost(postId, string newContent);
    }

    [Authorize(Roles = "Moderator")]
    public void EditOtherPost(string postId, string newContent)
    {
        this.postDomainService.EditOtherPost(postId, string newContent);
    }
}

हालांकि भूमिका मानचित्रण होस्टिंग परत पर किया जाता है आप देख सकते हैं, जो आपके संपादन गठन के जटिल तर्क स्वयं या एक दूसरों के बाद डोमेन का हिस्सा है।

डोमेन कार्यों के अंतर को पहचानता है, लेकिन सुरक्षा की आवश्यकता केवल यह है कि "कार्यक्षमता भूमिकाओं द्वारा सीमित की जा सकती है" ।

यह संभवतः डोमेन ऑब्जेक्ट्स को अलग करने के साथ स्पष्ट है, लेकिन अनिवार्य रूप से आप उस विधि की जांच कर रहे हैं जो सेवा पद्धति को कॉल करने वाली विधि के बजाय ऑब्जेक्ट का निर्माण करती है। आपकी आवश्यकता, यदि आप अभी भी इसे आवाज देना चाहते हैं तो डोमेन के हिस्से के रूप में 'केवल मॉडरेटर ही मॉडरेटर ऑब्जेक्ट का निर्माण कर सकते हैं'

Comments

"स्टेटिकली" भूमिका की जाँच करना थोड़ा सरल है। क्या होगा यदि एक मॉडरेटर को किसी अन्य मॉडरेटर के पद को संपादित करने की अनुमति नहीं है? क्या यह चेक डोमेन का हिस्सा नहीं होना चाहिए?

— रेदा हसनी अलौई

@ RédaHousniAlaoui मैं इस बारे में भी सोच रहा हूं। मैं इस तरीके को संभालने के बारे में नहीं सोच सकता हूँ या तो डोमेन में उपयोगकर्ताओं / मध्यस्थों के कुछ उल्लेख सहित, या पोस्ट के लेखक की भूमिका पाने के लिए उस ApiController के भीतर कुछ प्रकार के तर्क प्रदर्शन कर रहा हूं। इनमें से कोई भी सही नहीं लगता है, और मेरे अनुभव में यह एक आम बात है कि कुछ स्पष्ट मार्गदर्शन बेहद मददगार होगा।

— जिमी

@ इरान, मैं जिस केस की बात कर रहा हूं वह डायनामिक है। हैलो दुनिया के उदाहरणों पर वाक्य "प्रमाणीकरण और प्राधिकरण डीडीडी के लिए एक बुरा उदाहरण है" बेईमानी है। DDD आकस्मिक जटिलता से बचने और डोमेन जटिलता का प्रबंधन करने की अनुमति देने के लिए यहां है। गतिशील अनुमतियाँ एक आकस्मिक जटिलता नहीं है और न ही ऐसा कुछ है जो वास्तविक जीवन में नहीं होता है।

— राधा गृहनी अलाउई

IMHO, आपके समाधान के साथ समस्या यह है कि यह ग्राहक को संतुष्ट नहीं करता है। ग्राहक अक्सर उन संबंधों को गतिशील रूप से बदलने में सक्षम होना चाहता है। इसके अलावा, यह भी तब होता है जब एक विक्रेता विभिन्न कंपनियों को एक ही उद्यम सॉफ्टवेयर प्रदान करता है। यदि सॉफ़्टवेयर खराब रूप से ट्विक-सक्षम है, तो विक्रेता अंततः मर जाएगा।

— राधा गृहनी अलाउई

"लेकिन यह आमतौर पर एक" बुरी चीज "के रूप में पहचाना जाता है आपकी सुरक्षा सेटिंग्स समय के साथ असहनीय हो जाती हैं जिसका प्रभावी अर्थ है कि आपका ऐप असुरक्षित हो गया है।" सही डिजाइन और परीक्षण के साथ, यह पूरी तरह से प्रबंधनीय है। लेकिन, मेरे XP से, सही डिजाइन का उत्पादन करने के लिए, डोमेन को अनुमति की जांच करनी चाहिए। विकल्प यूटोपिया है।

— राधा गृहनी अलाउई