डीडीडी: डोमेन इकाई पर मुझे किस तरह के व्यवहार करना चाहिए?

Question

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

उदाहरण के लिए, सक्रिय रिकॉर्ड इकाई पर डेटा पहुंच डालता है। हम यह नहीं चाहते हैं क्योंकि हम डेटा एक्सेस के लिए खुशी से भंडार पैटर्न का उपयोग करते हैं।

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

तो, हमें किस प्रकार के व्यवहार को शामिल करना चाहिए? हमें किस प्रकार से दूर रहना चाहिए?

Answer 1

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

डोमेन को (कोड में) प्रतिनिधित्व करना चाहिए (वास्तविक जीवन में) व्यवसाय क्या है या करता है। डोमेन इकाइयां, फिर, वास्तविक जीवन व्यापार में पाए जाने वाले कलाकृतियों या कलाकार हैं। उन री-लाइफ कलाकृतियों और अभिनेताओं के किस प्रकार का व्यवहार है? यह सब। बदले में, डोमेन संस्थाओं के किस प्रकार के व्यवहार पर उनके पास होना चाहिए? यह सब।

उदाहरण के लिए, वास्तविक जीवन में, एक प्रबंधक एक नया कर्मचारी किराए पर ले सकता है। उस डोमेन के प्रतिनिधित्व में "प्रबंधक" और "नए कर्मचारी" जैसी संस्थाएं शामिल होनी चाहिए। प्रबंधक यहां अभिनेता है।

//newEmployee comes from somewhere else... possibly the UI 
//someManagerId comes from the logged in user 
var manager = _repository.Get<Manager>(someManagerId); 
manager.Hire(newEmployee); 

तो, प्रबंधक इकाई मॉडल/यहां वास्तविक जीवन व्यवसाय के व्यवहार को प्रतिबिंबित करता है। एक कमजोर डोमेन में

//newEmployeeService comes from somewhere else... possibly injected using IOC 
newEmployeeService.Create(newEmployee, someManagerId); 

: विकल्प एक अभिनेता के रूप प्रबंधक इकाई को छोड़ने के लिए, और उसे कोने में धक्का तो एक भारी-उठाने "डोमेन सेवा" सब काम कर सकते हैं ... इस तरह है , आप कर्मचारी बनाने या किराए पर लेने के लिए इस तरह की एक डोमेन सेवा का उपयोग करेंगे। यह काम करता है, लेकिन यह अभिव्यक्तिपूर्ण नहीं है और व्यवहार खोजने योग्य नहीं है। कौन क्या करता है? प्रबंधक को नया कर्मचारी बनाने की आवश्यकता क्यों है?

---

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

1. हम जब संभव हो, उपयोग अभिनेता संस्थाओं व्यक्ति या बात यह है कि कार्रवाई प्रदर्शन कर रहा है व्यक्त करने के लिए प्रयास करें।
2. अभिनेताओं के पास ऐसे तरीके हैं जो वे कर सकते हैं जो वे कर सकते हैं
3. जब किसी सेवा की आवश्यकता होती है, तो इसे विधि में एक तर्क के रूप में इंजेक्शन दिया जाता है जहां इसका उपयोग किया जाता है।
4. हम प्रत्येक डोमेन इकाई पर हर विधि पर BlingBag का उपयोग करके डोमेन घटनाओं को फायर कर सकते हैं ताकि एक्स्टेंसिबिलिटी प्रदान की जा सके और संस्थाओं को स्वयं को बनाए रखने की क्षमता मिल सके।

Answer 2

कुछ व्यवहार जो मैं अपने डोमेन, संस्थाओं या मूल्य वस्तुओं में डाल करने की कोशिश करता हूं।

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

क्या अधिक ... जानकारी खुफिया। कुल जानकारी को नियंत्रित और प्रतिबंधित करने के लिए अपनी इकाई और इसकी मूल्य वस्तुओं का उपयोग करें। जैसे व्यक्तित्व एक मूल्य वस्तु हो सकती है जो किसी व्यक्ति की असीमता को संभालती है। यह incapsulate एसएसएन, एसएसएन एल्गोरिथ्म, एसएसएन आदि पर लिंग जांच योग संभाल

Answer 3

व्यवहार आपके संस्थाओं पर है कि व्यापार मॉडल को प्रदर्शित करना चाहिए। उस इकाई के लिए या उसके द्वारा क्या किया जा सकता है, व्यापारिक दुनिया को ऐसी चीज होनी चाहिए जो इकाई वर्ग द्वारा या उसके द्वारा किया जा सके। उदाहरण के लिए:

एक ऑनलाइन शॉपिंग सिस्टम में, आप अपने कार्ट में एक उत्पाद जोड़ सकते हैं। तो गाड़ी वर्ग इस तरह दिखना चाहिए:

public class Cart 
{ 
    //... 

    public void AddProduct(Product product) 
    { 
     ...code to add product to cart. 
    } 
} 

यह तर्क दिया जा सकता है कि methids उपयोग के मामलों को प्रदर्शित करना चाहिए।

Answer 4

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

DDD या यहाँ तक कि domain model पैटर्न कि के बाद यह है कि डोमेन जटिलता बहुत अधिक किसी अन्य पद्धति से काम करने के लिए है की खोज की है पालन किया जा सकता है। तो सिर्फ सीआरयूडी डीडीडी के लिए उपयुक्त नहीं है। मेरी समझ से, डीडीडी फिट बैठता है जब आपके पास एक बाध्य संदर्भ होता है जिसमें जटिल व्यवसाय नियम होते हैं जिन्हें कुल रूट के लिए राज्य को स्थानांतरित करने से पहले चलाने की आवश्यकता होती है। तो मैं जटिल की परिभाषा में सत्यापन शामिल नहीं होगा।

व्यवहार है कि आप अपने संस्थाओं में रखना चाहते हैं की तरह परिचित व्यापार की समस्या को हल करने के लिए प्रयास कर रहे हैं से संबंधित है। दृढ़ता (भंडार आदि) के बारे में चिंता आनी चाहिए (वास्तव में, दृढ़ता वर्कफ़्लो या ईवेंट स्टोर में हो सकती है)।

उम्मीद है कि इससे मदद मिलती है।