डीडीडी के साथ विस्तार: एमडीएफ

Question

के साथ डीडीडी में मॉड्यूल बनाम बढ़ाया संदर्भ मॉड्यूल के विषय को छूता है। वह उदाहरण के साथ बाध्य संदर्भों के लिए मॉड्यूल की संरचना के संबंध के बारे में भी बात नहीं करता है। क्या बढ़ाए गए संदर्भों में मॉड्यूल या मॉड्यूल में बाध्य संदर्भ होते हैं? जब किसी एप्लिकेशन में डीडीडी होता है, तो इसे कितना आसान किया जा सकता है?

जब हम एक्स्टेंसिबल अनुप्रयोगों को डिज़ाइन करते हैं तो एप्लिकेशन की संरचना बहुत महत्वपूर्ण होती है। माइक्रोसॉफ्ट एमईएफ ढांचा एक डीएल से मॉड्यूल/घटकों को स्वत: खोज सकता है।

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

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

हम इस विस्तारशीलता समस्या को डीडीडी के साथ कैसे संभाल सकते हैं? भुगतान प्रसंस्करण, एक बीसी और मॉड्यूल के रूप में इसके नीचे विभिन्न फ़ोल्डर्स, पेपैल आदि के लिए एक ... या क्या हमें किसी अन्य बीसी के अंदर उप-बीसी की आवश्यकता है?

Answer 1

एरिक अपनी पुस्तक में मॉड्यूल के विषय को बहुत कम करता है। वह उदाहरण के साथ बाध्य संदर्भों के लिए मॉड्यूल की संरचना के संबंध के बारे में बात नहीं करता है।

हाँ, मैं मानता हूं कि मॉड्यूल और बीसी संरचना को पुस्तक में पर्याप्त कवरेज नहीं मिलता है। मैं इस पर अधिक के लिए Implementing Domain-Driven Design by Vaughn Vernon की सलाह देते हैं।

क्या बढ़ाए गए संदर्भों में मॉड्यूल या मॉड्यूल में संदर्भ शामिल हैं?

बीसी में मॉड्यूल होते हैं। एक मॉड्यूल एक हल्के बीसी की तरह है और यह सर्वव्यापी भाषा में भी है।

जब किसी एप्लिकेशन में डीडीडी होता है, तो यह कितना आसान हो सकता है?

यह इस बात पर निर्भर करता है कि आप इसे कैसे प्रबंधित करते हैं। डीडीडी के बारे में कुछ भी नहीं एक्स्टेंसिबिलिटी को रोक देगा।

मॉड्यूल, Paypal आदि के लिए एक के रूप में भुगतान संसाधन, एक ईसा पूर्व और उसके अंतर्गत विभिन्न फ़ोल्डर है ... या हम एक और ईसा पूर्व के अंदर उप ईसा पूर्व की जरूरत है?

मैं एक भुगतान प्रक्रिया प्रसंस्करण बीसी के भीतर एक मॉड्यूल के रूप में प्रत्येक भुगतान प्रोसेसर एकीकरण मॉडल करेगा। इसके अतिरिक्त, प्रत्येक एकीकरण आपके भुगतान प्रसंस्करण मॉडल और पेपैल जैसी तीसरी पार्टी के बीच ACL है।

या क्या हमें अन्य बीसी के अंदर उप-बीसी की आवश्यकता है?

नहीं, लेकिन यह उप-बीसी की एक दिलचस्प धारणा पर छूता है। मुझे नहीं लगता कि उप-बीसी एक अच्छा विचार है क्योंकि मेरा मानना ​​है कि पदानुक्रमित संगठन कठोर डिज़ाइन की ओर अग्रसर खतरनाक हो सकते हैं (उदाहरण के लिए स्पष्ट प्रकार पदानुक्रमों के साथ ओओपी देखें - समस्याग्रस्त हो सकता है)। इसके बजाय, संभावित रूप से अधिक बीसी के साथ एक चापलूसी मॉडल का चयन करें। इसके अलावा, आपके मामले में, वांछित संरचना मॉड्यूल के साथ हासिल की जा सकती है।