निकोले ग्रीबनेव (CUSTIS) - DDD क्या है? - एडीडी सम्मेलन से रिपोर्ट

इस तरह का एक सम्मेलन ADD (एप्लीकेशन डेवलपर डेज़) है जहाँ वे सॉफ्टवेयर विकास के लिए सभी प्रकार के वास्तुशिल्प टुकड़ों पर चर्चा करना पसंद करते हैं, आमतौर पर ये टुकड़े xDD - DDD, TDD, MDD, आदि के साथ भी समाप्त होते हैं।

उदाहरण के लिए, पिछले सम्मेलन में उन्होंने एक सवाल पूछा था: DDD (डोमेन ड्रिवेन डिज़ाइन) क्या है?
और CUSTIS से निकोलाई ग्रेबनेव - उठे और जवाब दिया।

रिपोर्ट वीडियो:




आप यहां वीडियो डाउनलोड कर सकते हैं (0.73 जीबी)

रिपोर्ट की प्रस्तुति:


रिपोर्ट पाठ

DDD (Domain Driven Design) क्या है?

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

• लेन-देन की लिपि
• टेबल मॉड्यूल
• डोमेन मॉडल

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



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



सभी वर्गों के पास किसी न किसी तरह के ऑपरेशन हैं, वे पहले से ही कुछ जानते हैं, कुछ को अपने आप में संलग्न करते हैं। एक नियम के रूप में, वे डेटाबेस के साथ काम को संक्षिप्त करते हैं। विशेष रूप से, उनमें विधियाँ हो सकती हैं: जोड़ना, हटाना, सब कुछ प्राप्त करना और कुछ अन्य। खैर, प्रत्येक इकाई के साथ, हम तालिकाओं से क्वेरी करके काम करते हैं। जाहिर है, हमारे पास तालिकाओं के बीच एक संबंध नहीं है, और किसी तरह हम उन्हें अपने कार्यक्रम के अंदर मैन्युअल रूप से बनाते हैं। वास्तव में, यदि कोई MS Visual Studio या सामान्य रूप से MS तकनीकों के साथ काम करता है, तो ये RecordSet & DataSet हैं, 2008 तक ये डेटा के साथ काम करने के लिए मुख्य प्रौद्योगिकियाँ थीं।
खैर, डोमेन मॉडल । इसमें प्रस्तुत पिछले विकल्पों से भिन्न है कि यहाँ हम एक पूर्ण डोमेन मॉडल का निर्माण कर रहे हैं। जिन संस्थाओं में व्यवहार होता है, जो अन्य संस्थाओं के साथ बातचीत करते हैं, जिनमें स्पष्ट संबंध होते हैं, आदि। आंकड़ा ऑटोमेशन डोमेन का एक मॉडल दिखाता है, उदाहरण के लिए, एक पुस्तकालय।



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

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

ज्ञान प्रसंस्करण क्या है?

जैसा कि एरिक इवांस इसे परिभाषित करते हैं, यह अमूर्त अवधारणाओं की खोज है जो आवश्यक विवरणों को ध्यान में रखते हैं।
जाहिर है, हमारे आईपी के विकास के लिए।
यह ज्ञान प्रसंस्करण कौन करता है?

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

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

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

महीने में काम करने के दिनों की संख्या का अनुपात एक महीने में कर्मचारियों के वेतन के अनुपात से गुणा करके एक महीने में कार्य दिवसों की संख्या


हम एक मॉडल बना रहे हैं



जाहिर है, उस वाक्यांश में कर्मचारी, महीने, कार्य दिवसों की संख्या, कर्मचारी वेतन जैसी अवधारणाएं हैं।
हम विशेषज्ञ से पूछते हैं कि किस दिन काम किया गया है। हमें जवाब मिलता है:
कार्य दिवस जब कर्मचारी कार्यस्थल पर मौजूद था, जबकि उसने अभी भी नहीं छोड़ा।



हमारे पास एक नई इकाई है, यह किसी प्रकार का डीएई है, जाहिर है, यह स्पष्ट रूप से बाहर खड़ा है, कर्मचारी के साथ संबंध है और महीने के साथ, "कार्य / दिन की छुट्टी", "वर्तमान" की विशेषताएं हैं।
इसके अलावा, डोमेन विशेषज्ञ याद करता है कि कर्मचारी के पास अभी भी छुट्टियां हो सकती हैं, या वह बीमार छुट्टी पर हो सकता है और वहां सब कुछ अलग है, एक अलग दर है, अन्य समस्याएं हैं।



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

• जितने दिन काम किया हो कर लो
• छुट्टी के दिनों की संख्या प्राप्त करें
• बीमार अवकाश आदि पर दिनों की संख्या प्राप्त करें।

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

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

शब्दावली शब्दावली की एक प्रणाली है - एक वैज्ञानिक और तकनीकी भाषा के शब्द जिनका एक विशिष्ट, स्पष्ट रूप से सीमित अर्थ है।

इसका मतलब यह है कि भाषा का शब्द हमें इस मॉडल का उपयोग करने में सक्षम बनाता है, इसके द्वारा एक दूसरे के साथ संचार के लिए उत्पन्न भाषा। और यह तथ्य कि शर्तों के स्पष्ट रूप से सीमित अर्थ हैं, हमें इन शब्दों को कोड में उपयोग करने का अवसर देता है।

मॉडल द्वारा डिजाइन।

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


- और हम उसके लिए एक कार्यक्रम बनाना शुरू करते हैं।



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

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

यानी यह गलत होगा यदि हमारे पास मॉडल में लेखक की अवधारणा है, और हमारे कोड में यह एक डेटासेट का एक स्ट्रिंग है, जो कि अप्रयुक्त भी है और स्पष्ट रूप से मौजूद नहीं है।

मैं आपको एक उदाहरण देता हूं। आइए हम निम्नलिखित कार्य का निर्माण करें:

दी गई तारीख से शुरू करते हुए, इकाई में एक कर्मचारी को भर्ती करें।

एक लेखा प्रणाली के लिए एक सामान्य कार्य, और यह समझना आसान है कि कुछ विभाग एक इतिहास रखते हैं, कि हमें एक इकाई कर्मचारी प्राप्त करने में सक्षम होना चाहिए। यूनिट में एक तिथि पर एक कर्मचारी को नामांकित करने के रूप में ऐसा कार्य होता है। आइए इसे कोड में लिखने की कोशिश करें, जैसा कि आमतौर पर होता है।



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



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



उसी समय, ध्यान दें कि हम इस इकाई का निर्माण इकाई में बिल्कुल नहीं कर रहे हैं, कड़ाई से बोलते हुए, इस इकाई को किसी को श्रेय दिया जाता है, लेकिन कुछ डिपार्टमेंटहिस्टोरिपोरेटरी में, सबसे अधिक संभावना है कि केवल प्रोग्रामर यह जानते हैं और यह सब संभव नहीं है। अगला, हम एक अलग नाम के साथ विधि कहते हैं - "नया बनाएं" (CreateNew) - नया क्यों? हम कुछ भी नहीं बनाते हैं, हम बस व्यक्ति को नामांकित करते हैं।
लेकिन मॉडल ड्राइव डिजाइन के मामले में, यह कैसा दिखेगा:



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

हमें डीडीडी की आवश्यकता क्यों है।

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

. DDD, ? . , .

DDD

, , , – , , , , , - , . , , - . DDD, , . , , – . , , – , .
, , , , . , , , , . – , , . , , — . - , .
DDD. , DDD , , , , , . , . Model Driven Design, DDD – , , , — - , , - .
. Model Driven Design. , , - – , - - . . - . , Hibernate ORM, . , , , - , , DDD, – , . , , , DDD, , : , , — , .
, DDD , .
, , DDD. , .

सवाल:

: DDD?
: , – , . , , – , . DDD , , , . DDD - , , , . , , DDD, , - , - , , – . « », « ». , « , * + * », , , , , , – . «select from db order by … group by …» — , Model Driven Design , .

: , (, . ) ?
: , , .

: . ?
: . . Facebook, , – . , , -, , . , . . , , , .

: overdraft, ?
: , DDD . , , ( ..). , , , , . . , , , , DDD, . , , – , .

: . , , .
: . - . , , . , DDD . , , . , , , , 10 , – -, . , , -, – , , . , : - «»? , , , – , , . « » — , – . , ! , , , , .