डीडीडी - डोमेन मॉडल, सेवाओं और भंडारों के बीच निर्भरता

Question

बस जानना चाहता था कि दूसरों ने अपने वास्तुकला को कैसे स्तरित किया है। इस प्रकार मैं अपने परतें हैं कहते हैं:

डोमेन परत
--Product
--ProductService (इस परत में जाने इम्प चाहिए?)
--IProductService
--IProductRepository

इंफ्रास्ट्रक्चर लेयर
--ProductRepository (मेरे डोमेन IProductRepository की Imp)

अब जब एक नया उत्पाद मैं बनाई गई है ProductService.GetNextProductId() विधि में कॉल करके उत्पाद आईडी असाइन करने की आवश्यकता।

क्योंकि सेवा पर रिपोजिटरी पर निर्भरता है, मैंने उत्पाद सेवा सेवा सीटीआर को आईपॉडक्ट रिपोजिटरी के इंटरफेस के साथ स्थापित किया है जिसे बाद में इंजेक्शन दिया जा सकता है। कुछ इस तरह:

public class ProductService : IProductService 
    { 
     private IProductRepository _repository; 

     public ProductService(IProductRepository repository) 
     { 
      _repository = repository; 
     } 

     public long GetNextProductId() 
     { 
      return _repository.GetNextProductId(); 
     } 
    } 

मेरे मुद्दा यह है कि जब मैं उत्पाद कक्षा मैं ctor में भंडार के संदर्भ बनाने हूँ जब एक नया ProductService वर्ग instantiating में सेवा का उपयोग करें। डीडीडी में इस तरह का कोई संदर्भ नहीं है। मैं कर रहा हूँ भी यकीन है कि अगर अपने उत्पाद डोमेन वर्ग को सही ढंग से सेवा को कॉल करने के लिए स्थापित किया जा रहा है, किसी को कृपया सलाह दे सकते हैं नहीं:

public class Product : Entity 
    { 
     private ProductService _svc; 
     private IProductRepository _repository; 

     public Product(string name, Address address) //It doesnt seem right to put parm for IProductRepository in the ctor? 
      : base(_svc.GetNextProductId) // This is where i pass the id 
     { 
      // where to create an instance of IProductRepository? 
     } 
    } 

कैसे मैं सुंदर ढंग से इस डिजाइन मुद्दे को हल कर सकते हैं?

आप टिप्पणी के लिए धन्यवाद: मैं अनुभवी DDD'ers से

संपादित सुझाव के लिए खुले हैं। मुझे यह भी संदेह है कि सेवा को उत्पाद कक्षा से बुलाया जाना चाहिए। मैंने कारखाने के पैटर्न का उपयोग नहीं किया है (अभी तक) क्योंकि वस्तु का निर्माण अभी भी सरल है। मुझे लगता है कि यह अभी तक एक कारखाने विधि वारंट नहीं है?

मैं उलझन में हूं ... उत्पाद को अलग करना अगर मेरे उत्पाद वर्ग को किसी सेवा से कुछ अन्य डेटा की आवश्यकता है जैसे GetSystemDateTime() (मुझे पता है, खराब उदाहरण है लेकिन एक गैर डीबी कॉल प्रदर्शित करने का प्रयास कर रहा है) यह सेवा विधि कहां होगी बुलाया जाए?

डीडीडी में सेवाएं तर्क डंप हैं जहां तर्क डोमेन ऑब्जेक्ट के लिए नाटकीय नहीं है, है ना? तो यह एक साथ गोंद कैसे करता है?

Answer 1

आपके डोमेन मॉडल में उत्पाद सेवा का संदर्भ नहीं होना चाहिए और न ही आईपॉडक्ट रिपोजिटरी का संदर्भ होना चाहिए। यदि आप एक नया उत्पाद बनाते हैं तो इसे कारखाने के माध्यम से बनाया जाना चाहिए - फैक्ट्री उत्पाद आईडी प्राप्त करने के लिए उत्पाद सेवा का उपयोग कर सकती है।

असल में मैं उत्पाद सेवा को उचित इंटरफ़ेस के साथ लपेटूंगा, जैसे कि IProductIdGeneratorService ताकि आप इसे अपने आईओसी कंटेनर का उपयोग करके कारखाने में इंजेक्ट कर सकें।

Answer 2

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

एक तरफ के रूप में, क्या आपको सच में लगता है कि आपके पास कभी भी एक से अधिक उत्पाद सेवा या उत्पाद रिपोजिटरी होगी? यदि नहीं तो मैं इंटरफेस से परेशान नहीं होगा। जोड़ने के लिए

संपादित:

मैं छोटे शुरू करने और इसे दो बस कक्षाएं, उत्पाद और ProductServices के साथ शुरू द्वारा सरल रखने की सलाह देते। उत्पाद सेवा कारखाने और भंडार समेत सभी सेवाएं निष्पादित करेगी, क्योंकि आप उन लोगों के बारे में सोच सकते हैं जो विशेष सेवाओं के रूप में सोच सकते हैं।

Answer 3

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

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

इस विषय के बारे में गहराई से बात करने वाला एक महान पॉडकास्ट here पाया जा सकता है। डेविड लार्बी वास्तव में एक अच्छा काम करता है जो अब "कैसे" लेकिन डीडीडी का "क्यों" बताता है।

Answer 4

जब आप स्मृति में उत्पाद बनाते हैं तो आपको उत्पाद आईडी की आवश्यकता क्यों होती है? आम तौर पर जब आप अपने भंडार में उत्पाद बनाते हैं तो उत्पाद आईडी सेट की जाती है।

निम्नलिखित कोड पर एक नज़र डालें:

वर ID1 = _repository.GetNextProductId(); var id2 = _repository.GetNextProductId();

क्या यह दो अलग-अलग उत्पाद आईडी वापस करेगा?

यदि उत्तर हाँ है, तो यह सुरक्षित है (लेकिन अभी भी अजीब है); यदि उत्तर नहीं है, तो आपको एक बड़ी समस्या होगी;

Answer 5

मार्सेलो के साथ समझौते में, आपको शायद पहले यह निर्धारित करना चाहिए कि उत्पाद आईडी वास्तव में एक डोमेन मॉडल अवधारणा है या नहीं। यदि व्यवसाय उपयोगकर्ता उत्पाद आईडी का कभी भी उपयोग नहीं करते हैं या आपके पास कोई विचार नहीं है और आम तौर पर नाम, संख्या, एसकेयू या नाम + आयाम से बने प्राकृतिक उत्पाद आईडी द्वारा उत्पाद का संदर्भ लें, तो डोमेन मॉडल को इसके बारे में पता होना चाहिए।

, यहाँ कहा जा रहा है कि कैसे मैं यह सोचते हैं कि उत्पाद ID डेटाबेस में एक स्वत: संख्या फ़ील्ड है मेरी DDD परियोजनाओं की संरचना है:

Project.Business (डोमेन मॉडल)

कोई संदर्भ नहीं और इसलिए, किसी भी चीज़ पर कोई निर्भरता नहीं है।

public class Product : Entity 
{ 
    private Product(string name, Address address) 
    { 
     //set values. 
    } 

    //Factory method, even for simple ctor is used for encapsulation so we don't have 
    //to publically expose the constructor. What if we needed more than just a couple   
    //of value objects? 
    public static CreateNewProduct(string name, Address address) 
    { 
     return new Product(name, address); 
    } 

    public static GetAddress(string address, string city, string state, string zip) { } 
} 

public interface IProductRepository : IEnumerable<Product> 
{ 
    void Add(Product product); 
    //The following methods are extraneous, but included for completion sake. 
    int IndexOf(Product product); 
    Product this[int index] { get; set; } 
} 

परियोजना।कार्यान्वयन

public SqlProductRepository : List<ProductDataModel>, IProductRepository 
{ 
    public SqlProductRepository(string sqlConnectionString) { } 

    public void Add(Product product) 
    { 
     //Get new Id and save the product to the db. 
    } 

    public int IndexOf(Product product) 
    { 
     //Get the index of the base class and convert to business object. 
    } 

    public Product this[int index] 
    { 
     get { //find instance based on index and return; } 
     set { //find product ID based on index and save the passed in Business object to the database under that ID. } 
    } 
} 

Project.ApplicationName (प्रस्तुति परत)

public class Application 
{ 
    IProductRepository repository = new SqlProductRepository(SqlConnectionString); 

    protected void Save_Click(object sender, EventArgs e) 
    { 
     Product newProduct = Product.CreateNewProduct(name, Product.GetAddress(address,city,state,zip)); 
     repository.Add(newProduct); 
    } 
}  

आवश्यक हैं, तो आप हो सकता है:

Project.Services (अनुप्रयोग सेवा स्तर खुद के बीच DTOs का उपयोग करता है और प्रस्तुति परत)

Answer 6

यहां बताया गया है कि मैं आपकी समस्या का निर्माण कैसे करूंगा। मेरा मानना ​​है कि यह करने का भी अनुशंसित डीडीडी तरीका है।

public class ProductService : IProductService // Application Service class, used by outside components like UI, WCF, HTTP Services, other Bounded Contexts, etc. 
{ 
    private readonly IProductRepository _prodRepository; 
    private readonly IStoreRepository _storeRepository; 

    public ProductService(IProductRepository prodRepository, IStoreRepository storeRepository) // Injected dependencies DI 
    { 
     if(prodRepository == null) throw new NullArgumentException("Prod Repo is required."); // guard 
     if(storeRepository == null) throw new NullArgumentException("Store Repo is required."); // guard 

     _prodRepository = prodRepository; 
     _storeRepository = storeRepository; 
    } 

    public void AddProductToStore(string name, Address address, StoreId storeId) //An exposed API method related to Product that is a part of your Application Service. Address and StoreId are value objects. 
    { 
     Store store = _storeRepository.GetBy(storeId); 
     IProductIdGenerator productIdGenerator = new ProductIdGenerator(_prodRepository); 
     Product product = Product.MakeNew(name, address, productIdGenerator); 
    } 

    ... // Rest of API 
} 

public class Product : Entity 
{ 
    public static MakeNew(string name, Address address, IProductIdGenerator productIdGenerator) // Factory to make construction behaviour more explicit 
    { 
     return new Product(name, address, productIdGenerator); 
    } 

    protected Product(string name, Address address, IProductIdGenerator productIdGenerator) 
     : base(productIdGenerator.GetNextProductId()) 
    { 
     Name = name; 
     Address = address; 
    } 

    ... // Rest of Product methods, properties and fields 
} 

public class ProductIdGenerator : IProductIdGenerator 
{ 
    private IProductRepository _repository; 

    public ProductIdGenerator(IProductRepository repository) 
    { 
     _repository = repository; 
    } 

    public long GetNextProductId() 
    { 
     return _repository.GetNextProductId(); 
    } 
} 

public interface IProductIdGenerator 
{ 
    long GetNextProductId(); 
} 

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

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

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

=========== अपने संपादित सवालों के जवाब देने ===============

मैं भी शक है, तो सेवा बुलाया जाना चाहिए उत्पाद वर्ग से।

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

मैंने ऑब्जेक्ट के निर्माण के रूप में अभी तक एक कारखाना पैटर्न (अभी तक) का उपयोग नहीं किया है। मुझे लगता है कि यह अभी तक एक कारखाने विधि वारंट नहीं है?

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

मैं उलझन में हूँ ... productId लाना एक तरफ अगर मेरे उत्पाद वर्ग एक सेवा जैसे GetSystemDateTime() (मुझे पता है, बुरा उदाहरण लेकिन एक गैर db कॉल प्रदर्शित करने के लिए कोशिश कर रहा है), जहां से कुछ अन्य डेटा की जरूरत क्या यह सेवा विधि कहलाएगी?

मान लें कि दिनांक कार्यान्वयन बुनियादी ढांचे का विवरण था। आप अपने आवेदन में उपयोग करने के लिए इसके चारों ओर एक अमूर्तता बनाएंगे। यह एक इंटरफ़ेस से शुरू होगा, शायद IDateTimeProvider जैसे कुछ। इस इंटरफेस में एक विधि GetSystemDateTime() होगी।

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

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

अंत में, आपकी प्रविष्टियां और कुल रूट्स और वैल्यू ऑब्जेक्ट्स GetSystemDateTime() और IDateTimeProvider के अन्य तरीकों को कॉल करने के लिए स्वतंत्र होंगे, लेकिन सीधे नहीं। इसे डबल प्रेषण के माध्यम से जाना होगा, जहां आप इसे किसी एक विधि के पैरामीटर के रूप में एक डोमेन सेवा देंगे, और यह उस डोमेन सेवा का उपयोग उस जानकारी की क्वेरी करने के लिए करेगा, जिसकी इच्छित जानकारी है, या जिस व्यवहार की आवश्यकता है उसे पूरा करें। यह स्वयं डोमेन सेवा पर वापस भी हो सकता है, जहां डोमेन सेवा क्वेरीिंग और सेटिंग करेगी।

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

डीडीडी में सेवाएं तर्क डंप हैं जहां तर्क डोमेन ऑब्जेक्ट पर नाटकीय नहीं है, है ना? तो यह एक साथ गोंद कैसे करता है?

मुझे लगता है कि मेरा पूरा जवाब पहले से ही यह स्पष्ट हो गया है। असल में, आपके पास यह सब चमकाने के लिए 3 संभावनाएं हैं (जिन्हें मैं कम से कम अब तक सोच सकता हूं)।

1) एक एप्लिकेशन सेवा एक डोमेन सेवा को तुरंत चालू करती है, उस पर एक विधि कॉल करती है, और परिणामस्वरूप वापसी मूल्यों को किसी और चीज को पास करता है जिसकी आवश्यकता होती है (रेपो, इकाई, कुल रूट, मूल्य वस्तु, अन्य डोमेन सेवा, कारखानों आदि) ।)।

2) एक डोमेन सेवा को एप्लिकेशन डोमेन द्वारा तत्काल किया जाता है और इसका उपयोग करने वाले किसी विधि की पैरामीटर के रूप में पारित किया जाता है। जो कुछ भी इसका उपयोग करता है, वह स्थायी संदर्भ नहीं रखता है, यह केवल स्थानीय चर है।

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

उम्मीद है कि इससे मदद मिलती है। टिप्पणियों का स्वागत है अगर मैंने कुछ गलत किया या डीडीडी के सर्वोत्तम प्रथाओं के खिलाफ चला जाता है।