क्या डीडीडी सभी प्रकार के आवेदन के लिए उपयुक्त है?

Question

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

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

क्या यह दृष्टिकोण अच्छा लगता है?
या आप कहेंगे कि डीडीडी रास्ता या नहीं, चाहे "सभी या कोई नहीं" विकल्प के मामले में प्रत्येक आवेदन के डिजाइन में मौलिक विकल्प है?

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

Answer 1

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

अक्सर अनदेखा किया जाता है: डीडीडी कार्यान्वयन पैटर्न के साथ-साथ विश्लेषण पैटर्न का वर्णन करता है। विश्लेषण पैटर्न कई (यदि नहीं सबसे) अनुप्रयोगों में overkill हो सकता है लेकिन कार्यान्वयन पैटर्न (अर्थात संस्थाओं, विनिर्देशों, सेवाएं) बहुत काम की कम जटिल स्थितियों में भी हो सकता है।

Answer 2

संक्षेप में,

यदि यह महज CRUD है, मैं परेशान नहीं होता।

दूसरी ओर,

यह व्यवहार है, जहां कुछ की अगली राज्य पहले वाली स्थिति पर निर्भर करता है मिल गया है, तो DDD कुछ आप शायद विचार करना चाहते है।