मेरे पास एक डोमेन है जो मैं इकाई का उपयोग करके उत्पन्न करता हूंडेवलपर। यह मेरी सभी संस्थाओं और मेरे डेटाबेस तालिकाओं को बनाता है। मैं अपने एंटिटीज़ को पॉप्युलेट करने के लिए NHibernate का उपयोग करता हूं जो रिपोजिटरीज़ के माध्यम से उजागर होते हैं। मेरे पास एक सेवा परत है जो रिपोजिटरी को उपयोगी सेवाओं में एकत्रित करती है। इस परत का उपयोग दो तरह से किया जाता है। एक, मैं अपनी वेब लेयर से संचार के एकमात्र साधन के रूप में सेवाओं का उपयोग करता हूं और किसी दिन मैं डब्ल्यूसीएफ के लिए सेवाओं का उपयोग करना चाहता हूं। अभी, मैं अपनी वेब लेयर पर काम कर रहा हूं और मैं अपनी सेवाओं के साथ संवाद करने का सबसे अच्छा तरीका जानने की कोशिश कर रहा हूं। मेरी सेवाएँ वर्तमान में Entities लौटा रही हैं। मेरी वेब परत नियंत्रकों में सेवाओं के माध्यम से इन संस्थाओं को पकड़ रही है। यह शायद बहुत DRY / DDD नहीं है। मुझे लगता है कि मेरी सेवाओं की परत को डीटीओ के माध्यम से इंटरफ़ेस करने की आवश्यकता है। DTO की मेरी WCF सेवाओं के लिए एकदम सही होगा। मेरी वेब परत के लिए, मुझे लगता है कि मैं DTO को ले जाऊंगा जो मेरी सेवाओं की परत से वापस आ गए हैं और मैं उन मॉडलों को देखने के लिए मैप करना चाहता हूं ASP.NET MVC 3 का उपयोग करना)।
तो यह वही है जो मेरी वास्तुकला की तरह लग रहा है:
Domain
Entities
Repository Interfaces
Infrastructure
NHibernate
Concrete Repositories
Services
DTO"s
Concrete Services
Service Interfaces
IIS hosted WCF
Website
ViewModels
और मैं या तो मेरा मैपिंग करने के लिए ऑटोमैपर या ValueInjecter का उपयोग करूँगा (शायद ValueInjector मेरे एंटिटी / डीटीओ को समतल और अनफ्लैट करने की क्षमता के कारण।
तो क्या यह ओवरकिल है? इस आर्किटेक्चर का उपयोग करने वाला सिस्टम मैं काफी बड़ा है (मैं सब कुछ फिर से लिख रहा हूं)। क्या मैं यह ठीक कर रहा हूँ? निनजे के साथ सब कुछ निर्भरता-वार को कम कर दिया गया है क्योंकि मैं किसी भी समय सिस्टम के किसी भी हिस्से को बदलना चाह सकता था। किसी भी विचार, विचार या आलोचना का बहुत स्वागत और सराहना है।
उत्तर:
उत्तर № 1 के लिए 1यह एक सामान्य वास्तुकला है और व्यवहार में अच्छी तरह से काम करती है। एक केंद्रीय लाभ एनकैप्सुलेशन है - आपका डोमेन एक सर्विस लेयर (DDD में एप्लिकेशन सेवाओं) द्वारा एनकैप्सुलेटेड है।
जहाँ तक WCF सेवाओं की बात है, मेरा मानना है कि उनके लिए अधिक उपयुक्त शब्द एडॉप्टर है। इस पर आधारित है हेक्सागोनल वास्तुकला जहां आप आवेदन सेवा परत कोर और WCF पर है adapts इसे HTTP (या अन्य बाध्यकारी)। इसे ध्यान में रखते हुए, एप्लिकेशन सेवाओं को एक एडाप्टर अज्ञेय तरीके से लागू किया जाना चाहिए। इसका मतलब कोई WCF विशिष्ट गुण या डेटा अनुबंध नहीं है। WCF एडेप्टर बदले में आवेदन सेवाओं के आसपास पतली परतें हैं। कुछ अतिरिक्त लेयरिंग के कारण इस ओवरकिल पर विचार कर सकते हैं, लेकिन मैंने इसे लाभकारी पाया क्योंकि यह प्रौद्योगिकी विशिष्ट चिंताओं से मुक्त अनुप्रयोग परत को बनाए रखता है।
क्या यह आर्किटेक्चर ओवरकिल है या नहीं यह निर्भर करता हैपरियोजना। उस सवाल का जवाब देने का एक तरीका यह निर्धारित करना है कि क्या आवेदन ज्यादातर सीआरयूडी है जिस स्थिति में डीडीडी ओवरकिल है और एक तकनीक का उपयोग करना बेहतर हो सकता है जो डेटाबेस से पढ़ने और डेटा को सीधे सेवा के रूप में उजागर करने की सुविधा देता है।
जरा देखो तो यहाँ DDD के भीतर सेवाओं के अधिक गहन उपचार के लिए।