इसे किस प्रकार की वास्तुकला कहा जाता है?

Question

वेब अनुप्रयोग के लिए (ASP.NET MVC) मैं वर्तमान में विकसित कर रहा हूँ, हम जगह में निम्नलिखित वास्तुकला है:

• Data Access Layer: डाटा मॉडल: एक मनमाना db
• Domain करने के लिए डेटा बने के लिए तर्क
• Service Layer: व्यापार तर्क (जैसे आदेश संसाधन, खाता प्रबंधन, आदि)
• Controller: खपत सेवाओं और/देखें से/डेटा प्राप्त प्रदान करता है
• View: उपयोगकर्ता

संक्षेप में के लिए यूजर इंटरफेस, मैं Model ले लिया और उसे विभाजित DAL, Service Layer और Domain में। मुझे लगा कि Model के भीतर सभी तर्कों को भरने से मेरा कोड अत्यधिक जटिल हो गया। इसके अलावा, मुझे लगा कि यह नियंत्रक को बहुत अधिक काम करने के बिना स्पष्ट रूप से मेरे व्यापार तर्क को व्यक्त करने देता है।

मेरा प्रश्न तब है: इस प्रकार की वास्तुकला क्या कहा जाता है?

द्वितीयक प्रश्न के रूप में: क्या इस प्रकार की वास्तुकला समझ में आता है? यदि नहीं, तो क्या मैं कुछ गलत कर रहा हूँ?

Answer 1

डोमेन & सेवा परतों के पतले/मोटी के आधार पर आप डीडीडी के बारे में सही रास्ते पर हैं। डीडीडी का कहना है कि ज्ञान (यानी व्यवसाय तर्क) डोमेन मॉडल में crunched किया जाना चाहिए। डीएएल को डेटा एक्सेस चिंताओं को स्थानांतरित करना डीडीडी के अनुरूप है, लेकिन मुझे लगता है कि एक व्यापार परत में व्यापार तर्क को आगे बढ़ाना नहीं है। यदि आपके पास पतली डोमेन "डेटा मॉडल" परत (ज्यादातर इकाइयों के लिए) और मोटी सेवा परत (ज्यादातर "व्यापार तर्क" के लिए) है, तो आपके पास anemic domain हो सकता है।

इसके अलावा, डीडीडी में तकनीकी रूप से कोई "सेवा परत" नहीं है। एक "एप्लिकेशन लेयर" हो सकता है, लेकिन यह पतला होना चाहिए, और केवल आवेदन प्रवाह/प्रबंधन डोमेन क्लास जीवनकाल के लिए ज़िम्मेदार होना चाहिए। यह अनिवार्य रूप से नियंत्रक एनईटी एमवीसी में करते हैं, वेब http के संदर्भ में अनुप्रयोग प्रवाह का प्रबंधन करते हैं।

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

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

यहां एक आर्क का एक उदाहरण है जिसे मैं अपनी नई परियोजनाओं में उपयोग करना शुरू कर रहा हूं।

• API परियोजना/विधानसभा: सामान्य इंटरफेस, enums, वर्ग, और विस्तार अन्य सभी परतों के द्वारा इस्तेमाल किया तरीकों यह प्याज + DDD का एक संयोजन है। डोमेन से अलग नहीं होना चाहिए, लेकिन हो सकता है।

• Domain परियोजना/असेंबली: सभी संस्थाएं और व्यावसायिक तर्क। केवल API पर निर्भर करता है। कारखाने, सेवा, विनिर्देश, भंडार इत्यादि जैसे डीडीडी पैटर्न का उपयोग करता है। इसमें डोमेन-विशिष्ट इंटरफेस भी शामिल हैं जिन्हें API में परिभाषित नहीं किया गया है।

• Impl परियोजना/असेंबली: API और Domain में परिभाषित इंटरफेस के कार्यान्वयन। यह वह जगह है जहां ईएफ डीबीकॉन्टेक्स्ट लागू किया गया है, साथ ही साथ लॉगिंग, ईमेल भेजने आदि जैसी चीज़ें भी शामिल हैं। इन सभी कार्यान्वयन निर्भरता-इंजेक्शन हैं, इसलिए तकनीकी रूप से आपके पास कई आईएमएल परियोजनाएं/असेंबली हो सकती हैं।

• UI परियोजना/असेंबली: यह एमवीसी परियोजना है। नियंत्रक सीधे डोमेन की सतह का उपभोग करते हैं, और किसी एप्लिकेशन या सेवा परत से नहीं जाते हैं। कारखानों, सेवाओं, भंडारों आदि में किसी भी इंटरफेस निर्भरता, एमवीसी आईओसी (कन्स्ट्रक्टर इंजेक्शन) का उपयोग कर नियंत्रक द्वारा डोमेन में इंजेक्शन दी जाती है।

मैंने एपीआई परत को बहुत कोर पर रखा लेकिन आप एपीआई और डोमेन परियोजनाओं को एक में जोड़ सकते हैं। किसी भी तरह से, प्याज का बड़ा मांसपेशियों का हिस्सा डोमेन है, और इसमें आंतरिक परत है। उदाहरण के लिए सेवाएं कारखानों पर निर्भर हो सकती हैं, जो रेपॉजिटरीज़ पर निर्भर करती हैं, जो संस्थाओं पर निर्भर करती हैं।

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

एमवीसी में नियंत्रक और दृश्य हैं, और यूआई और वेब अनुप्रयोग प्रवाह पर ध्यान केंद्रित करते हैं। डोमेन-विशिष्ट ज्ञान की आवश्यकता वाले किसी भी डोमेन को डोमेन पर सौंप दिया जाता है, और डोमेन क्लास नियंत्रक में इंजेक्शन वाले कंस्ट्रक्टर होते हैं। इसका मतलब है कि डोमेन वर्गों में किसी भी कन्स्ट्रक्टर-इंजेक्शन इंटरफेस को आईओसी कंटेनर द्वारा स्वचालित रूप से हल किया जाता है।

अंतिम नोट के रूप में, एपीआई और डोमेन कक्षाओं में परिभाषित इंटरफेस के खिलाफ प्रोग्रामिंग का मतलब है कि आप एमवीसी प्रोजेक्ट से अलग से डोमेन प्रोजेक्ट का परीक्षण कर सकते हैं।

Answer 2

आप जिस कोण को देख रहे हैं उसके आधार पर अलग-अलग नाम हो सकते हैं। तो यह अभी भी एमवीसी है, यह सिर्फ इतना है कि आपका एम कई परतों में विभाजित है। इसे Multitier architecture (या एन-स्तरीय वास्तुकला) भी कहा जा सकता है। जेफरी पालेर्मो ने भी Onion architecture की धारणा का उपयोग किया।

Answer 3

चूंकि आपके पास डीएएल डोमेन मॉडल से अलग है और सेवा परत भी है, ऐसा लगता है कि आप डीडीडी (डोमेन-संचालित डिज़ाइन) पर जा रहे हैं, ऐसे an approach के बारे में एक चर्चा है जो जानना उपयोगी हो सकता है।

Answer 4

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

डोमेन परत एक विधानसभा/पैकेज दूसरों के किसी भी संदर्भ नहीं है कि में रहता है, तो यह Onion Architecture principles के मुख्य है, जो कर रहे हैं:

• आवेदन एक स्वतंत्र वस्तु आसपास बनाया गया है मॉडल
• आंतरिक परतें इंटरफेस को परिभाषित करती हैं।यदि आपका DataAccess संदर्भ डोमेन बाहरी परत इंटरफेस को लागू
• युग्मन की दिशा केंद्र
• सभी आवेदन कोर कोड संकलित किया जा सकता की ओर है और बुनियादी ढांचे

से अलग चलाने के एक ठोस बात के लिए देखने के लिए कर रहा है।