जब हमें डोमेन-संचालित डिज़ाइन दृष्टिकोण का उपयोग नहीं करना चाहिए?

Question

मुझे लगता है कि मैं इस पैरा

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

के साथ-साथ यह एक:

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

तो, आपको क्या लगता है? क्या आप इस राय को स्वीकार करते हैं? इन अनुच्छेदों के मुताबिक हम आईटी परियोजनाओं की विस्तृत श्रृंखला के लिए डीडीडी का उपयोग नहीं कर सके, हम कर सकते थे?

Answer 1

लेखक संख्या के आधार पर उन मानों को केवल कुछ मूल्यों के रूप में लें (इवांस की पुस्तक 13 साल पहले प्रकाशित हुई थी, तब से चीजें बदल गई हैं)।

सबसे पहले, यह बात है कि (दुख की बात है) कुछ देव समझते हैं कि डीडीडी चीजों को देखने का एक तरीका है। बस। तो आप में प्रत्येक प्रोजेक्ट में डीडीडी का उपयोग कर सकते हैं, क्योंकि इसके कार्यान्वयन के बावजूद हमें पहले भी डोमेन को समझने की आवश्यकता है। यदि यह पता चला है कि डोमेन केवल डेटा संरचनाओं का एक गुच्छा है, तो आपको अपने जीवन को जटिल करने की आवश्यकता नहीं है। विशेष रूप से यदि आप एक 'गूंगा' ऐप बना रहे हैं i.e डेटाबेस के लिए एक यूआई बना रहे हैं।

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

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

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

सीधे शब्दों में कहें, आपको यह तय करने के लिए डीडीडी का उपयोग करना होगा कि (संपूर्ण) डीडीडी आपके ऐप के कुछ हिस्सों के लिए उपयोग योग्य है या नहीं। लेकिन एक बार फिर, डीडीडी का अर्थ रणनीतिक दृष्टिकोण, मानसिकता है।

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

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

Answer 2

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

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

मुझे डीडीडी के बारे में सोचना पसंद है जो डिज़ाइन स्पेक्ट्रम के अंदर मौजूद है।
कुछ की तरह:

<--CRUD----Active Record----Domain Model----DDD--> 

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

Answer 3

वॉन वर्नन अपनी महान पुस्तक में उनके DDD scorecard में उभरता है।

यदि आपका आवेदन विशेष रूप से सीआरयूडी उन्मुख है, तो डीडीडी यागनी होगी।
अन्यथा, यदि आपका एप्लिकेशन वास्तव में कार्य-उन्मुख है, तो उपयोगकर्ता का एक विशिष्ट इरादा पकड़कर, डीडीडी वास्तव में आपकी मदद कर सकता है।