डोमेन-संचालित डिज़ाइन कठिन नहीं होना चाहिए। यहाँ कैसे शुरू करें

एंड्रयू हैमेल-लॉ द्वारा

मैंने कई टीमों को डोमेन-संचालित डिज़ाइन (DDD) को अपनाते हुए देखा है, और मैंने देखा है कि चीजें बहुत गलत हैं। अक्सर समस्याएं बहुत शुरुआती चरणों में शुरू होती हैं।

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

"डोमेन-संचालित डिज़ाइन" क्या है?

जब मैं कहता हूं कि 'डोमेन-संचालित डिज़ाइन' मैं एरिक इवांस द्वारा 2003 की अपनी पुस्तक "डोमेन-ड्रिवेन डिज़ाइन: टैक्लिंग कॉम्प्लेक्सिटी इन द हार्ट ऑफ़ सॉफ्टवेयर" में शुरू की गई डिज़ाइन प्रक्रिया के बारे में बात कर रहा हूँ। इसमें उन्होंने DDD को "मूल अवधारणाओं के एक विकसित मॉडल के कार्यान्वयन को गहराई से जोड़कर जटिल जरूरतों के लिए सॉफ्टवेयर विकसित करने के लिए एक दृष्टिकोण" के रूप में परिभाषित किया। यह पुस्तक, जबकि अविश्वसनीय रूप से पठनीय (डेवलपर्स के लिए मेरी शीर्ष तीन पुस्तकों में से एक) भी ऑफ-पुटिंग हो सकती है: 560-पृष्ठों पर, यह एक वजनदार ठग है।

इवांस की पुस्तक DDD पर एकमात्र नहीं है। वॉन वर्नोन द्वारा "इंप्लीमेंटिंग डोमेन-ड्रिवेन डिज़ाइन" सबसे अच्छी तरह से जाना जाता है - लेकिन यह अधिक लंबा है। आप स्कॉट मिललेट और सैम नाइट द्वारा वॉन के "डोमेन-ड्रिवेन डिस्टिल्ड डिस्टिल्ड", या शायद, मेरे व्यक्तिगत पसंदीदा, "एनाटॉमी ऑफ़ डोमेन-ड्रिवेन डिज़ाइन" की कोशिश कर सकते हैं।

इन सब के बावजूद, लोगों को अभी भी जानकारी की सरासर मात्रा से दूर रखा जा रहा है, और शायद यह भी कि कैसे शुरू करने के लिए विकल्पों की संख्या।

यह मुझे दुखी करता है, क्योंकि डीडीडी वह चीज है जो मुझे परियोजनाओं पर समझदार रखती है, कोडबेस को लाइन में रखती है और व्यावसायिक समस्या के करीब है, और सबसे महत्वपूर्ण बात यह है कि टीमों को व्यवस्थित और वितरित करने में मदद करता है।

चरण 1: व्यवसाय की समस्या से शुरू करें

तो आप कैसे शुरू करते हैं? डीडीडी के बारे में भूल जाओ।

पूरी तरह से।

उन दिनों को याद करें जब आपने कभी डोमेन-संचालित डिज़ाइन के बारे में सुना था और आप केवल बॉक्स और लाइनों का उपयोग करके अपने सॉफ़्टवेयर डोमेन को मॉडल करेंगे?

वो करें। मज़े करो।

बस कोशिश करें और समझें कि आप अपने सॉफ़्टवेयर के साथ क्या समस्या हल कर रहे हैं। Ub बंधे हुए संदर्भ ’, it सर्वव्यापी भाषा’ और अन्य सभी सामानों को भूल जाओ - यहाँ तक कि। डोमेन ’शब्द को भी भूल जाओ।

जारी रखें। जाने दो ... मैं तुम्हारे लिए यहाँ इंतज़ार करूँगा।

अब, चलो कोशिश करते हैं और हमारी व्यावसायिक समस्या को समझते हैं।

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

स्टेज 2: सिर्फ ड्रॉ मत करो, कोडिंग भी मॉडलिंग है

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

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

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

मैं आपको इस मॉडल प्रदूषण के साथ थोड़ा सा जीने के लिए कहने जा रहा हूं। यह ठीक है। बस आपको निराश करने की भावना के लिए उपयोग करें। यह पहचानने के लिए एक अच्छा एहसास है।

चरण 3: अपने डोमेन विशेषज्ञ सहयोगियों के साथ सह-डिजाइन

जब आप मॉडल करते हैं, तो सुनिश्चित करें कि आप उन विशेषज्ञों के साथ निकट संपर्क में रहते हैं जो वास्तव में आपके द्वारा बनाए जा रहे सिस्टम के वास्तविक-विश्व संस्करण को समझते हैं। शायद वे अंतिम उपयोगकर्ता होंगे। उन्हें अपने सह-डेवलपर्स के रूप में समझो। वे समस्या को सुपर-डिटेल में जानते हैं, लेकिन कोड (शायद) को नहीं जानते। तुम विपरीत हो।

वास्तव में अपने सिर को मुश्किल बिट्स को गोल करने और भयानक समाधान बनाने के लिए उनके साथ सेना में शामिल हों। सॉफ्टवेयर में अपनी दुनिया का वर्णन करने के लिए उपयोग की जाने वाली शर्तों का उपयोग करके अपने विशेषज्ञों के लिए चीजों को आसान रखें। न केवल संज्ञाएं, बल्कि क्रियाएं भी; उदाहरण के लिए न केवल "BankAccount" बल्कि "CreditAmount" और "Close" भी। विशेषज्ञ की बातों को ध्यान से सुनें। स्पष्टता और साझा समझ पाने के लिए बहुत सारे प्रश्न पूछें, लेकिन उन पर अपने शब्दों को कभी न थोपें। इस साझा भाषा और मॉडल को इकाई परीक्षणों को भाषा में लिखकर चलाने में मदद करें कि विशेषज्ञ 100% सहज हों।

आप अपने सहयोगियों को एक विशेषज्ञ लेंस के रूप में सूचीबद्ध करके, तकनीकी प्लंबिंग / फ्रेमवर्क चीजों की पहचान कर सकते हैं, जो आपके प्यारे स्वच्छ मॉडल में क्रेप हैं। एक बार जब आप प्रदूषण की पहचान कर लेते हैं, तो आप इसे अपने "मॉडल" पैकेज से हटाकर अपने कोडबेस में कहीं और ले जा सकते हैं, जैसे ही ऐसा करने के लिए आरामदायक हो।

जाँच करें कि आप अपने एक या अधिक विशेषज्ञ सहयोगियों को अपना कोड दिखा कर इस सफाई में सफल रहे हैं, या इससे भी बेहतर है कि आप उनके साथ जोड़ी बनाते समय ऐसा करें। अगर यह उन्हें समझ में आता है (जिस भाषा का आप उपयोग कर रहे हैं, लेकिन शब्दावली का नहीं, उसके बारे में थोड़ी व्याख्या के साथ) आप सही रास्ते पर हैं।

उत्तम सुझाव:

  1. चीजों को सुपाच्य रखें।
  2. यदि आप एक ऐसे बिंदु पर पहुँचते हैं जहाँ आपका मॉडल और आपका विशेषज्ञ असहमत हैं, तो वे सही हैं और मॉडल गलत है। हमेशा। अपना मॉडल बदलें। यह एक सफलता है!

यदि आप इसके बाद कभी कोई समस्या नहीं मारते हैं तो बधाई! आप डोमेन-संचालित डिज़ाइन कर रहे हैं! अपने आप को एक DDD योग्यता बिल्ला पुरस्कार!

स्टेज 4: जब आपका मॉडल टूट जाता है

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

यह 100% ठीक है। इसका मतलब है कि एक मॉडल के साथ ऐसा करने का कोई तरीका नहीं है।

यदि आप इस बिंदु पर आते हैं, तो त्वरित जांच करें: क्या आपके मॉडल में सभी तत्व मौजूद हैं क्योंकि उन्हें समस्या को हल करने की आवश्यकता है? यदि नहीं, तो उन्हें हटा दें। सभी मॉडल वास्तविक दुनिया के सार हैं और इसमें वह सब कुछ शामिल करने की आवश्यकता नहीं है जो वह करता है।

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

शीर्ष सुझाव: आप शायद इसके लिए व्हाइटबोर्ड पर वापस जाना चाहते हैं।

"लेकिन" मैं आपको रोते हुए सुनता हूं, "मेरे मूल मॉडल के कुछ टुकड़े अब दो स्थानों पर आवश्यक हैं!" (Grrr! निराशा होती है!)

यह पूरी तरह से ठीक है। बस आगे बढ़ें और आपके द्वारा आवश्यक बिट्स की नकल करें। अपने दोनों मॉडलों को दुबला, क्षुद्र और समस्या को सुलझाने के लिए केंद्रित रखें। क्या आप DRY नहीं होने से चिंतित हैं? मैथियास वेरास द्वारा "डीआरवाई ज्ञान के बारे में है" पढ़ें और फिर एक डेवलपर के रूप में खुद को समतल करने के लिए बधाई दें। डेव थॉमस और एंडी हंट के चांगेलॉग पॉडकास्ट (एपिसोड 352) को भी देखें जो इस विषय पर भी बात करता है।

शीर्ष युक्ति: सुनिश्चित करें कि आप केवल उन बिट्स को कॉपी करें जिनकी आपको आवश्यकता है (यानी फ़ील्ड / विशेषताएँ और विधियाँ / फ़ंक्शन)।

ठीक है, अब आपके पास दो मॉडल हैं जिनमें से प्रत्येक एक समस्या को हल कर रहा है, आपको कैसे पता है कि कोड कहाँ जाता है?

अभी तक फिर से जवाब "अपने विशेषज्ञों से बात" है। वे संभवतः दो नौकरियों के बारे में सोच रहे होंगे जब उन्होंने आपको चीजों को समझाया था।

शीर्ष सुझाव: उन्हें नौकरी के शीर्षक और "टोपी" के बारे में सोचने के लिए प्राप्त करें जो वे अपने कार्य दिवस के विभिन्न समय पर पहन सकते हैं।

सुनिश्चित करें कि आपका मॉडल उन रेखाओं के साथ विभाजित है। जैसा कि वे आगे जाने वाली चीजों की व्याख्या करते हैं, उनसे पूछें "जब आप ऐसा कर रहे हों तो आपके पास कौन सी टोपी है?" वे इसे बहुत तेज़ कर देंगे, और जल्द ही आप फिर से उड़ान भरेंगे।

बधाई हो! अब आपने अपने पहले दो मॉडल खोज लिए हैं। क्या अधिक है, आपने बंधे हुए संदर्भों की आवश्यकता की भी खोज की है। अपने आप को एक और DDD योग्यता बिल्ला पुरस्कार!

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

26 फरवरी, 2020 को मूल रूप से https://www.thoughtworks.com पर प्रकाशित हुआ।