डीडीडी: डोमेन इंटरफेस, इंफ्रास्ट्रक्चर कहां रखना है?

Question

क्या यह इंफ्रास्ट्रक्चर परत के भीतर आपके डोमेन लेयर (मॉड्यूल, मॉडल, संस्थाएं, डोमेन सेवाएं इत्यादि) के सभी इंटरफेस को समूहित करने के लिए समझ में आता है? यदि नहीं, तो क्या यह "साझा" प्रोजेक्ट/घटक बनाने के लिए समझ में आता है जो इन सभी को साझा लाइब्रेरी में समूहित करता है? आखिरकार, "इंफ्रास्ट्रक्चर लेयर" की परिभाषा में "डोमेन, एप्लिकेशन और यूआई परतों के लिए साझा लाइब्रेरी" शामिल हैं।

मैं डीडीडी परतों के आसपास अपना कोडबेस डिजाइन करने की सोच रहा हूं: यूआई, एप्लीकेशन, डोमेन, इंफ्रास्ट्रक्चर। यह 4 परियोजनाओं को सम्मानपूर्वक बनाएगा। मेरा मुद्दा यह है कि आप डोमेन लेयर से इंफ्रास्ट्रक्चर लेयर का संदर्भ लेते हैं। लेकिन अगर आप डोमेन परत परियोजना में इंटरफेस को परिभाषित, IPost के लिए कहते हैं, आप बुनियादी ढांचा परियोजना जब आप IPostRepository.Save (IPost पोस्ट) विधि को परिभाषित कर रहे से डोमेन परत परियोजना को संदर्भित करने के लिए है जब तो आप एक circulur संदर्भ होगा । इसलिए, "साझा लाइब्रेरी में सभी इंटरफ़ेस को परिभाषित करने" का विचार "।

शायद रिपॉजिटरीज़ को ऑब्जेक्ट को सहेजने की उम्मीद नहीं करनी चाहिए (IPostRepository.Save (आईपीओस्ट पोस्ट); लेकिन इसके बजाय, ऑब्जेक्ट के पैराम की अपेक्षा करें (जो कि सहेजें() में पैरा का लंबा सेट हो सकता है)। , इस एक आदर्श स्थिति से पता चलता है कि जब एक वस्तु बहुत जटिल हो रही है हो सकता है, और अतिरिक्त मूल्य वस्तुओं इसके लिए में देखा जाना चाहिए।

विचार?

Answer 1

एरिक, मैं एक जोड़े के लिए दूर था, इसलिए मुझे बहुत देर से जवाब देने के लिए क्षमा करें। रिपोजिटरी कहां रखना है, व्यक्तिगत रूप से मैं हमेशा एक संग्रहित आधारभूत संरचना परत (उदा। MyApp.Data.Oracle) में भंडार डालता हूं लेकिन उन इंटरफेस को घोषित करता हूं जिनके लिए रिपॉजिटरीज को डोमेन परत में अनुरूप होना होता है।
मेरी परियोजनाओं में एप्लिकेशन लेयर को डोमेन और इंफ्रास्ट्रक्चर परत तक पहुंचना है क्योंकि यह डोमेन और आधारभूत संरचना परत को कॉन्फ़िगर करने के लिए ज़िम्मेदार है।
आवेदन परत डोमेन में उचित आधारभूत संरचना को इंजेक्ट करने के लिए ज़िम्मेदार है। डोमेन यह नहीं जानता कि यह किस बुनियादी ढांचे से बात कर रहा है, यह केवल यह जानता है कि इसे कैसे कॉल किया जाए। निस्संदेह मैं डोमेन में निर्भरताओं को इंजेक्ट करने के लिए स्ट्रक्चरमैप जैसे आईओसी कंटेनर का उपयोग करता हूं। फिर मैं यह नहीं कहता कि डीडीडी आपकी परियोजनाओं को ढांचा बनाने की सिफारिश करता है, यह वही तरीका है, मैं अपने ऐप्स को आर्किटेक्चर करता हूं। चीयर्स।

Answer 2

मैं चुप DDD में नए कर रहा हूँ तो संकोच नहीं करते अगर आप असहमत हैं, तो टिप्पणी करने के लिए, क्योंकि आप यहां सीखने के लिए हैं।

व्यक्तिगत रूप से मुझे समझ में नहीं आता कि आपको संदर्भ क्यों देना चाहिए अपने डोमेन से बुनियादी ढांचे परत सीई। मेरी राय में डोमेन बुनियादी ढांचे पर निर्भर नहीं होना चाहिए। डोमेन ऑब्जेक्ट्स पूरी तरह से अनजान होना चाहिए कि वे किस डेटाबेस पर चल रहे हैं या मेल भेजने के लिए किस प्रकार का मेल सर्वर उपयोग किया जाता है। बुनियादी ढांचे से डोमेन को सारण करके इसे पुन: उपयोग करना आसान है; क्योंकि डोमेन यह नहीं जानता कि किस बुनियादी ढांचे पर चल रहा है।

मुझे अपने कोड में क्या मेरी बुनियादी ढांचे परत से डोमेन परत संदर्भ है (लेकिन विपरीत)। रेपॉजिटरीज डोमेन ऑब्जेक्ट्स को जानते हैं क्योंकि उनकी भूमिका डोमेन के लिए राज्य को संरक्षित करना है। मेरे रिपॉजिटरीज़ में मेरे रूट एग्रीगेट्स (get (id), getall(), सेव (ऑब्जेक्ट), डिलीट (ऑब्जेक्ट) के लिए मेरे मूल सीआरयूडी ऑपरेशंस शामिल हैं और मेरे नियंत्रकों के भीतर से कॉल किया जाता है।

मैंने अपनी आखिरी परियोजना पर क्या किया (मेरा दृष्टिकोण पूरी तरह से डीडीडी नहीं है लेकिन यह बहुत अच्छी तरह से काम करता है) यह है कि मैंने इंटरफेस के साथ अपने रेपॉजिटरीज़ को सारणीबद्ध किया। रूट योग को एक कंस्रीटरी के एक ठोस प्रकार को पारित करके तत्काल किया जाना चाहिए:

रूट कुल के माध्यम से तत्काल होना चाहिए प्राप्त करें (आईडी) या भंडार की एक विधि बनाएँ() का उपयोग करके भंडार। ठोस भंडार वस्तु के निर्माण में ही पारित कर दिया है, ताकि एकीकृत कंक्रीट कार्यान्वयन के लिए कुछ भी जानने के बिना अपने राज्य और अपने बच्चे वस्तुओं के राज्य लेकिन की रक्षा कर सकता है भंडार की। उदा .:

public class PostRepository:IPostRepository 
{ 
    ... 
    public Post Create() 
    { 
     Post post=new Post(this); 
     dbContext.PostTable.Insert(post); 
     return post; 
    } 
    public Save(post) 
    { 
     Post exitingPost=GetPost(post.ID); 
     existingPost = post; 
     dbContext.SubmitChanges(); 
    } 
} 

public class Post 
{ 

    private IPostRepository _repository 
    internal Post(IPostRepository repository) 
    { 
     _repository = repository; 
    } 
    ... 
    Public Save() 
    { 
     _repository.Save(this); 
    } 

} 

Answer 3

मैं आपको सलाह Onion architecture विचार करने के लिए होगा। यह डीडीडी के साथ बहुत अच्छी तरह से फिट बैठता है। विचार यह है कि अपने भंडार इंटरफेस सिर्फ बाहर सीधे डोमेन और संदर्भ संस्थाओं एक परत में बैठते है:

IPostRepository.Save(Post post)

डोमेन बिल्कुल खजाने के बारे में पता करने की जरूरत नहीं है।

इंफ्रास्ट्रक्चर परत डोमेन द्वारा संदर्भित है नहीं, या किसी और और अन्य आई/ओ से संबंधित सामान के बीच में खजाने की ठोस कार्यान्वयन में शामिल है।विभिन्न सहायकों के साथ आम पुस्तकालय को इस मामले में एप्लिकेशन कोर कहा जाता है, और इसे किसी के द्वारा संदर्भित किया जा सकता है।