2010-05-25 15 views
7

मैं डीडीडी के लिए नया हूं और अपनी परियोजना में इस डिजाइन तकनीक का उपयोग करने के बारे में सोच रहा हूं।मेरा कोड डीडीडी (डोमेन-संचालित डिज़ाइन) योग्यता प्राप्त करता है?

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

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

मेरे लिए, DDD में केवल नए विचार शायद है

  • "स्मार्ट" संस्थाओं मूल्य वस्तु के बीच
  • पृथक्करण, जड़ कुल (यानी आप रूट समुच्चय पर व्यापार के नियम के लिए अपेक्षा की जाती है) और संस्थाओं।

क्या कोई मुझे बता सकता है कि क्या मैंने यहां कुछ भी याद किया है? यदि डीडीडी के लिए यह सब कुछ है, तो यदि मैं उपर्युक्त 2 नए विचारों के साथ अपने मौजूदा एमवीसी एप्लिकेशन में से एक अपडेट करता हूं, तो क्या मैं दावा कर सकता हूं कि यह एक टीडीडी, एमवीसी और डीडीडी एप्लाशन है?

+0

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

+0

आप सेब और नाशपाती मिश्रण कर रहे हैं ... डीडीडी आर्किटेक्चर के लिए एक दृष्टिकोण है (हालांकि लेखक का नाम "सामरिक डिजाइन" है), जिसमें अनुभव से प्रेरित विभिन्न वास्तुकला, डिजाइन पैटर्न और तकनीकी शामिल हैं। एमवीसी वास्तुशिल्प और डिजाइन पैटर्न है। टीडीडी एक विकास विधि है, हालांकि बहुत हल्के वजन में एक सरल विकास तकनीक शामिल है। वो चीजें बहुत अलग हैं। एकल पैटर्न पर डीडीडी में न देखें, उन्हें ज्यादातर अन्य स्रोतों से लिया जाता है और डीडीडी के लिए विशिष्ट नहीं होते हैं। –

उत्तर

14

संक्षिप्त उत्तर यह है कि ऐसा नहीं है कि आपका कोड ऐसा लगता है जो इसे डीडीडी प्रोजेक्ट के रूप में योग्य बनाता है, इस तरह आप उस कोड पर पहुंचे। अब लंबे संस्करण के लिए ...

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

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

7

डीडीडी वास्तव में एक चेकलिस्ट नहीं है - यह एक पद्धति है। अपने कोड व्यवसाय के रूप में उपयोग करता है एक ही नाम/शर्तों -

  • सर्वव्यापी भाषा:

    Stefans जवाब देने के लिए इसके अलावा, मैं (महत्व के क्रम में) निम्नलिखित सुझाव देंगे? क्या आपके डोमेन ऑब्जेक्ट्स व्यवसाय के समान नामों का उपयोग करते हैं?

  • व्यवहार - क्या अधिकांश व्यवहार/तर्क सीधे डोमेन ऑब्जेक्ट्स से जुड़े हैं, या आपके पास बहुत सारे गूंगा डीटीओ हैं?
  • बाध्य संदर्भ - क्या आपने स्पष्ट रूप से जिम्मेदारी के क्षेत्रों को परिभाषित किया है और चिंता का पृथक्करण?
  • समेकित - क्या आपने रूट ऑब्जेक्ट्स के आधार पर समेकन की पहचान की है, और लॉकिंग रणनीतियों को व्यावसायिक आविष्कारों को लागू करने के लिए?
  • डेटा संग्रह स्थान - सभी डेटा पहुँच/ डेटा संग्रह स्थान के माध्यम से किया क्वेरिंग है, या आप अन्य वर्गों में SQL कोड क्या ज़रूरत है?
  • डोमेन सेवा - आप व्यापार तर्क है कि एक डोमेन वस्तु में
  • विनिर्देशों फिट स्वाभाविक रूप से नहीं करता है के लिए डोमेन सेवा है - आप अच्छी तरह से विनिर्देशों में लिपटे व्यापार के नियम है?
  • प्रश्न विनिर्देश - क्या आपके पास पूर्व-डिब्बाबंद प्रश्न/फिल्टर अच्छी तरह से क्वेरी विनिर्देशों में रैपर अप है?

फिर अन्य सभी चीजें हैं!

मुझे लगता है कि सबसे DDD चिकित्सकों कहना चाहता हूँ होगा:

"मैं के साथ डोमेन विशेषज्ञों का काम उनकी जरूरतों को समझने के लिए, और लिखने प्रणाली है कि (क) से मेल व्यापार नियमों और प्रक्रियाओं, (ख) अन्य डेवलपर्स मदद व्यवसाय डोमेन को समझें, और (सी) बदलती व्यावसायिक आवश्यकताओं को समायोजित करने के लिए फ्लेक्स कर सकते हैं। "

आशा है कि मदद करता है!

संबंधित मुद्दे