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