सख्त TDD और DDD को कैसे संयोजित करें?


15

TDD डिजाइनिंग कोड के बारे में है, जो परीक्षणों द्वारा निर्देशित है।
इस प्रकार, आम तौर पर विशिष्ट परतें निर्मित नहीं होती हैं; वे थोड़ा सा कदमों के माध्यम से प्रकट होना चाहिए।

डोमेन-चालित डिज़ाइन में बहुत सारे तकनीकी पैटर्न शामिल होते हैं, जो एप्लीकेशन लेयर, इन्फ्रास्ट्रक्चर लेयर, डोमेन लेयर, पर्सिस्टेंस लेयर जैसी अच्छी तरह से स्थापित परतों को परिभाषित करते हैं।

डीडीडी परियोजना के कोडिंग भाग को खरोंच से शुरू करने के लिए, कैसे व्यवहार करें?
क्या मुझे डिजाइन को परीक्षणों से उभरने देना चाहिए, जिसका अर्थ है कि डीडीडी तकनीकी पैटर्न को फिट करने के लिए चिंताओं (कोई परतों) और रिफ्लेक्टर की कोई जुदाई नहीं?

या क्या मुझे उन खाली परतों (एप्लिकेशन, संस्थाओं / डोमेन सेवाओं, बुनियादी ढांचे) का निर्माण करना चाहिए और उनमें से प्रत्येक में टीडीडी को स्वतंत्र रूप से फिट होने देना चाहिए (परतों के बीच अलग करने के लिए मोज़ेक का उपयोग करना)?


जवाबों:


12

सुनिश्चित करें कि आपने चाचा बॉब की हाल की टिप्पणियों को TDD में डिजाइन की भूमिका के बारे में समीक्षा की है ।

डोमेन-चालित डिज़ाइन में बहुत सारे तकनीकी पैटर्न शामिल होते हैं, जो एप्लीकेशन लेयर, इन्फ्रास्ट्रक्चर लेयर, डोमेन लेयर, पर्सिस्टेंस लेयर जैसी अच्छी तरह से स्थापित परतों को परिभाषित करते हैं।

उदी दहन: "भगवान, मैं कैसे लेयरिंग से नफरत करता हूं।" वह अपनी चर्चा CQRS में इस पर चर्चा करने के लिए कुछ समय बिताते हैं - लेकिन अलग (लेयरिंग 18m30s से शुरू होता है)

मैं आपकी सजा को थोड़ा अलग तरीके से लिखूंगा; "डीडीडी यह स्वीकार करता है कि अधिकांश व्यावसायिक अनुप्रयोगों के लिए कई चिंताएं आम हैं और उन चिंताओं के समाधान के लिए अलग-अलग जीवनकाल हैं"

उदाहरण के लिए, डोमेन चिंताएं, एक नियम के रूप में, लचीली होने की आवश्यकता होती है - खासकर जब आप किसी विशेष व्यवसाय के लिए समाधान अनुकूलित कर रहे हों। आखिरकार, डोमेन चिंता करता है कि कंपनी कैसे व्यापार करती है, जो कहना है कि कंपनी कैसे पैसा बनाती है और जल्दी से व्यावसायिक सुधार देने में सक्षम है, यह मुफ्त राजस्व है।

दूसरी ओर, आपको शायद दृढ़ता घटक को बदलने की आवश्यकता नहीं है। अंतिम रिलीज़ पर काम करने वाला डेटाबेस समाधान भी संभवतः इस रिलीज़ पर काम करेगा।

आवेदन की चिंताएं कहीं बीच में हैं; वे स्थिर होते हैं ताकि उपयोगकर्ताओं को हर रिलीज़ के साथ एक नया ऐप सीखने की आवश्यकता न हो।

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

इस बीच, सीटीओ ऐप का एक संस्करण चाहता है जो उसके फोन पर चलता है; सीईओ सिर्फ एक आदमी से सुना है कि एपीआई प्रकाशित करना बड़ी बात है।

इसके अलावा, बिक्री टीम एक अलग मॉडल का उपयोग करती है, इसलिए हमें अलग मॉडल के साथ एक ही ऐप दें। ओह, लेकिन हम बहुत यात्रा कर रहे हैं, इसलिए हमारे संस्करण को तब काम करना होगा जब हम ऑफ़लाइन हों और बाद में सिंक करें ...

दूसरे शब्दों में, आप खाली प्लेसहोल्डर्स को लागू न करके से सामरिक पैटर्न लागू करते हैं और यह मानते हैं कि वे बाद में भरे जाएंगे, लेकिन जब आप स्ट्रीम पार कर रहे होते हैं तो पहचानने के बजाय "अरे, यह मेरे डोमेन मॉडल में दृढ़ता कोड है, मुझे नहीं होना चाहिए।" अभी तक रिफैक्टिंग नहीं हुई है। ”


11

टेस्ट ड्रिवेन डेवलपमेंट (TDD) एक डिज़ाइन नहीं है। यह एक आवश्यकता है जो आपके डिजाइन को प्रभावित करती है। जैसे कि आपको थ्रेड सुरक्षित होना आवश्यक था, यह एक डिज़ाइन नहीं है। फिर, यह एक आवश्यकता है जो आपके डिजाइन को प्रभावित करती है।

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

परीक्षण योग्य बकवास के बारे में एक अच्छी बात यह है कि यह कुछ लोगों के लिए काफी अच्छा बकवास है। जरूरत पड़ने पर ही हम फैंसला लेंगे। अन्य लोग इससे नफरत करते हैं और इसके लिए टीडीडी को दोषी मानते हैं। नहीं। यह आपका काम है।

डोमेन ड्रिवेन डिज़ाइन (DDD) कुछ है जो आप TDD के रेड ग्रीन रिफैक्टर चक्र से पहले करते हैं।

डीडीडी कोड में एक स्थान बनाने और संरक्षित करने का प्रयास है जहां एक डोमेन विशेषज्ञ, जो सिस्टम के विवरण से काफी हद तक बेखबर है, यह समझ सकता है कि सिस्टम को कैसे नियंत्रित किया जाए। यह एब्स्ट्रैक्शन और समस्या डोमेन को एक परिचित तरीके से मॉडलिंग द्वारा किया जाता है।

डीडीडी प्रणाली में एक आर्किटेक्चर हो सकता है जो इस तरह दिखता है:

यहाँ छवि विवरण दर्ज करें

डीडीडी आर्किटेक्चर को कई नामों से जाना जाता है: स्वच्छ , प्याज , हेक्सागोनल , आदि

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

बस। इस डिजाइन के नियमों का पालन करें और आप अपने छोटे दिल को टीडीडी कर सकते हैं। TDD परवाह नहीं करता है कि आप किससे बात करते हैं। यह परवाह करता है कि सब कुछ जो कुछ करता है वह एक बटन के क्लिक पर काम करने के लिए सिद्ध हो सकता है या नहीं। नहीं, कहीं कुछ टूट गया है। यह बताता है कि वास्तव में क्या टूटा है।

अभी भी अस्पष्ट है? पर देखो Controler- Use Case Interactor- Presenterनीचे दाएं कोने में चित्र। यहां तीन ठोस चीजें एक दूसरे के साथ संवाद कर रही हैं। यकीन है कि यह DDD है लेकिन आप यहाँ TDD कैसे जोड़ते हैं? बस कंक्रीट के सामान का मजाक उड़ाएं। प्रस्तुतकर्ता को जानकारी प्राप्त करनी चाहिए। एक PresenterMockवर्ग यह जांचने का एक अच्छा तरीका होगा कि यह वही हो रहा है जो आपने प्राप्त करने की अपेक्षा की थी। हाथ और ड्राइव के रूप में अगर तुम थे और आप इकाई परीक्षण करने के लिए एक अच्छा तरीका है के बाद से नकली आपको बताती हैं कि समझ में आ गया कि क्या आप इसे प्राप्त करने के लिए उम्मीद करेंगे।Use Case InteractorPresenterMockUse Case InteractorControllerUse Case Interactor

खैर वो देखो। TDD संतुष्ट है और हमें अपने DDD डिजाइन के साथ वायदा नहीं करना था। ये कैसे हो गया? हमने एक अच्छी तरह से डिकॉउन्ड डिज़ाइन के साथ शुरुआत की।

यदि आप ड्राइव डिजाइन (केवल डी इलवमेंट नहीं) के लिए टीडीडी का उपयोग करते हैं, तो आपको एक डिज़ाइन मिलता है जो आपके द्वारा डाले गए प्रयास को दर्शाता है। यदि आप चाहते हैं कि ठीक है। लेकिन यह कभी नहीं था कि टीडीडी का मतलब क्या था। यह जो कमी है वह निश्चित रूप से टीडीडी की गलती नहीं है।

TDD डिजाइन के बारे में नहीं है। यदि आपको TDD का उपयोग करने के लिए डिज़ाइन में परिवर्तन करना है तो आपको परीक्षण की तुलना में बड़ी समस्याएं हैं।


मैंने कभी नहीं कहा कि टीडीडी एक डिज़ाइन है, लेकिन यह डिज़ाइन के बारे में है
मिक 378

1
अंकल बॉब आपको डिजाइन करने के लिए कह रहे थे। वह आपको यह नहीं बता रहा था कि "यदि आप काम का परीक्षण करते हैं जो बाकी की परवाह करता है"।
candied_orange

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

7
ऊ ... मैं वास्तव में "टेस्ट ड्रिवन डिजाइन" मिथ्या नाम नहीं कर सकता। आपको अभी भी थोड़ा सा डिज़ाइन करना है, इससे पहले कि आप अपने कीबोर्ड पर आनंदपूर्वक तेज़ करना शुरू करें, चाहे आप परीक्षण लिखें या नहीं।
रबडक ३

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

4

TDD आपके कोड को बताता है कि विकास के समानांतर सभी आवश्यक परीक्षण मामले लिखे गए हैं। यह उच्च स्तर के डिजाइन को प्रभावित नहीं करना चाहिए। इसे खाइयों के काम में अधिक समझें।

DDD सभी उच्च स्तरीय डिजाइन, डोमेन विशेषज्ञों और इंजीनियरों के बीच की भाषा, संदर्भ मानचित्रण आदि के बारे में है। यह एप्लिकेशन उच्च स्तरीय डिज़ाइन का चालक होना चाहिए।

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

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

मुझे लगता है कि यह नोट करना महत्वपूर्ण हो सकता है: यदि आवेदन पर्याप्त रूप से जटिल है, तो आपको केवल DDD का अभ्यास करना चाहिए।


1
मैं असहमत हूं, टीडीडी परीक्षण के बारे में नहीं है, यह डिजाइनिंग के बारे में है।
मिक 378

मैं चाचा बॉब द्वारा वर्णित के रूप में टीडीडी के 3 नियमों को बंद कर रहा हूं।
मैट ओक्साका

GOOS पुस्तक के लेखक स्टीव फ्रीमैन ने कहा: आपको TDD चक्र शुरू करने से पहले किसी भी परत या बुनियादी ढांचे को निर्दिष्ट नहीं करना चाहिए।
मिक 378

मैं उस पुस्तक से अपरिचित हूं, लेकिन मुझे असहमत होना पड़ेगा। मैं नहीं चाहता कि TDD मेरे DI और वर्ग ग्राफ को आकार दे।
मैट ओक्साका

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

3

DDD सॉफ्टवेयर डिज़ाइन के बारे में है।
TDD कोड डिज़ाइन के बारे में है।

DDD में, "मॉडल" डोमेन के सभी अमूर्त ज्ञान का प्रतिनिधित्व करता है, डोमेन विशेषज्ञ से।

हम कोड प्रारंभिक सॉफ़्टवेयर डिज़ाइन मॉडल के लिए TDD का उपयोग कर सकते हैं। डोमेन में व्यावसायिक नियम और डोमेन मॉडल हैं जो लिखित (पहले) परीक्षण हरा होना चाहिए।

वास्तव में, हम डोमेन-संचालित मॉडल को डिज़ाइन करने के बाद परीक्षणों को कोड कर सकते हैं।
यह पुस्तक "बढ़ते ऑब्जेक्ट-ओरिएंटेड सॉफ्टवेयर, टेस्ट द्वारा निर्देशित" लिंक-फॉर-बाय
इस दृष्टिकोण को लें, एक पैदल कंकाल , हेक्सागोनल वास्तुकला और टीडीडी के साथ।

स्रोत से: DDD जल्दी - InfoQ


1
मेरे लिए सॉफ्टवेयर और कोड एक ही बात है
कोनराड

1
यह वही हो सकता है, भी। मैंने यह कहने की कोशिश की: सॉफ्टवेयर एक "समाधान", "सिस्टम", "उच्च स्तर" और एक "कार्यान्वयन", "निम्न स्तर", "विवरण" के रूप में कोड
JonyLoscal

मुझे लगता है कि महत्वपूर्ण बात यह है कि "पहले हम परीक्षण करते हैं, लेकिन हमें एक न्यूनतम कंकाल चाहिए जहां हम परीक्षण शुरू करेंगे"। क्या आप?
3

1

क्या मुझे कड़ाई से डिजाइन को परीक्षणों से उभरने देना चाहिए

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

या मैं उन खाली परतों (एप्लिकेशन, इकाइयां / डोमेन सेवा, बुनियादी ढांचे) का निर्माण करूं और उनमें से प्रत्येक में टीडीडी को स्वतंत्र रूप से फिट होने दूं

(जारी) ... या अपनी पसंद की ओओ भाषा में कक्षाओं / वर्ग पदानुक्रम की कुछ विहित परतें, भले ही यह बहुत परिपक्व और लोकप्रिय एक हो (आखिर "लाखों मक्खियों को गलत नहीं किया जा सकता", है ना?) ।

जब डीडीडी की बात आती है, तो ओओपी मानव-पठनीय रूप में छोटी व्यक्त आवश्यकताओं को पूरा करता है अर्थात ऐसा कुछ जो गैर-प्रोग्रामर के लिए कम या ज्यादा स्पष्ट होगा। कड़ाई से टाइप की गई एफपी भाषाएँ बेहतर काम करती हैं। मैं स्कॉट Wlaschin द्वारा कार्यात्मक प्रोग्रामिंग "डोमेन मॉडलिंग मेड फंक्शनल" का उपयोग करके DDD के बारे में एक पुस्तक पढ़ने की सलाह देता हूं

https://pragprog.com/book/swdddf/domain-modeling-made-functional

आपको वहां से कुछ विचारों को उधार लेने के लिए FP भाषा का उपयोग करने की आवश्यकता नहीं है (सभी दुर्भाग्य से नहीं), लेकिन यदि आप वास्तव में इसे पढ़ते हैं तो आप शायद एक कार्यात्मक भाषा का उपयोग करना चाहेंगे।

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

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


एफपी डीडीडी पुस्तक और समग्र स्पष्टीकरण के लिए +1।
रोमन सूसी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.