🧔🏾 ♐️ 🥥 डोमेन संचालित डिज़ाइन उपकरण 🍍 ⏸️ 🎫

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

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

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

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

रिपोर्ट के पूर्ण प्रस्तुति ।

अर्टेम मालिशेव (proofit404) - 5 वर्षों के लिए पायथन में लिखा गया एक स्वतंत्र डेवलपर, सक्रिय रूप से Django चैनल 1.0 के साथ मदद करता है। बाद में उन्होंने वास्तुकला के दृष्टिकोणों पर ध्यान केंद्रित किया: उन्होंने अध्ययन किया कि पायथन आर्किटेक्ट्स के पास कौन से उपकरण हैं और सूखे-अजगर परियोजना की शुरुआत की । ड्रायलैब्स के सह-संस्थापक।

जटिलता

प्रोग्रामिंग क्या है?

प्रोग्रामिंग एक जटिल संघर्ष है जो डेवलपर्स स्वयं बनाते हैं जब वे समस्याओं को हल करने का प्रयास करते हैं।

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

अच्छे इंजीनियरों को उत्पाद की उपयोगिता बढ़ाने के लिए अतिरिक्त जटिलता को कम करना चाहिए और प्राकृतिक को बढ़ाना चाहिए।

लेकिन हम प्रोग्रामर जटिल लोग हैं और हम परियोजनाओं में तकनीकी जटिलता जोड़ना पसंद करते हैं। उदाहरण के लिए, हमने कोडिंग मानकों से परेशान नहीं किया, लिंटर, मॉड्यूलर डिजाइन प्रथाओं का उपयोग नहीं किया और परियोजनाओं में बहुत सारे स्टाइल कोड प्राप्त किए if c==1।

ऐसे कोड के साथ कैसे काम करें? बहुत सारी फाइलें पढ़ें, चर, स्थितियों को समझें और यह सब कब और कैसे काम करेगा। इस कोड को ध्यान में रखना मुश्किल है - बिल्कुल तकनीकी जोड़ा जटिलता।

जोड़ा जटिलता का एक और उदाहरण मेरा पसंदीदा "कॉलबैक नरक" है।

जब हम किसी इवेंट-ओरिएंटेड आर्किटेक्चर (EDA) के फ्रेमवर्क में लिखते हैं और नॉट-सो-गुड मॉडर्न फ्रेमवर्क चुनते हैं, तो हमें एक कोड मिलता है जिसमें यह स्पष्ट नहीं होता है कि क्या होता है और कब होता है। इस तरह के कोड को पढ़ना मुश्किल है - यह फिर से जोड़ा गया जटिलता है।

प्रोग्रामर न केवल तकनीकी कठिनाइयों को स्वीकार करते हैं, बल्कि यह भी तर्क देते हैं कि कौन सा बेहतर है:

AsyncIO या Gevent;
PostgreSQL या MongoDB;
अजगर या गो;
Emacs या विम;
टैब या रिक्त स्थान;

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

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

DDD क्या है?

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

विषय वस्तु विशेषज्ञों और सॉफ्टवेयर डेवलपर्स के साथ मॉडल पर काम करें। हमें व्यापार से लोगों के साथ संवाद करना चाहिए: एक सामान्य भाषा की तलाश करें, दुनिया का एक मॉडल बनाएं, जिसके भीतर हमारा उत्पाद काम करेगा और समस्याओं को हल करेगा।

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

व्यवसाय के साथ एक ही भाषा बोलें । DDD एक विशिष्ट क्षेत्र में व्यावसायिक विशेषज्ञों के साथ समान भाषा बोलने और इस क्षेत्र में शब्दावली लागू करने के बारे में एक दर्शन है। हमारे पास एक सामान्य भाषा या बोली है, जिसे हम संदर्भ के रूप में मानते हैं। हम वास्तुशिल्प समाधानों के चारों ओर सीमा बनाते हैं।

DDD तकनीक के बारे में नहीं है।

सबसे पहले, तकनीकी हिस्सा, फिर - डीडीडी। पत्थर से मूर्ति को तराशने वाले मूर्तिकार ने हथौड़ा और छेनी रखने के तरीके को मैनुअल नहीं पढ़ा है - वह पहले से ही जानता है कि उनके साथ कैसे काम करना है। DDD को अपनी परियोजना में लाने के लिए, तकनीकी भाग में महारत हासिल करें: Django को अंत तक जानें, ट्यूटोरियल पढ़ें और बहस करना बंद कर दें कि क्या PostgreSQL या MongoDB का उपयोग करना है।

अधिकांश डिज़ाइन पैटर्न और पैटर्न तकनीकी शोर हैं। अधिकांश पैटर्न जो हम जानते हैं और उपयोग करते हैं, वे तकनीकी हैं। वे कहते हैं कि कोड का पुन: उपयोग कैसे करें, इसे कैसे संरचना करें, लेकिन वे यह नहीं कहते कि उपयोगकर्ताओं, व्यवसायों और बाहरी दुनिया के लिए इसका उपयोग कैसे किया जाए। इसलिए, कारखाने या अमूर्त वर्ग डीडीडी के प्रति शिथिल हैं।

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

"लाल" और "नीली" किताबें वे स्तंभ हैं जिन पर सभी DDD खड़े हैं।

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

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

एकमात्र स्थान प्रौद्योगिकी चुना गया है स्मार्ट यूआई। यह बाहरी दुनिया, उपयोगकर्ता और हमारे (रॉबर्ट मार्टिन के संदर्भ और परतों के साथ उनकी साफ वास्तुकला) के बीच एक परत है। जैसा कि आप देख सकते हैं, सब कुछ मॉडल पर जाता है।

मॉडल क्या है? यह किसी भी वास्तुकार का प्रेत दर्द है। हर कोई सोचता है कि यह यूएमएल है, लेकिन ऐसा नहीं है।

एक मॉडल कक्षाओं, विधियों और उनके बीच लिंक का एक सेट है जो कार्यक्रम में व्यावसायिक परिदृश्यों को दर्शाता है।

मॉडल सभी आवश्यक गुणों और कार्यों के साथ एक वास्तविक वस्तु को दर्शाता है। यह व्यावसायिक मामलों के दृष्टिकोण से निर्णय लेने के लिए एक उच्च-स्तरीय टूलकिट है। हालाँकि, विधियाँ और कक्षाएं वास्तुशिल्प समाधानों के लिए एक निम्न-स्तरीय टूलकिट हैं।

सूखा अजगर

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

कथा का अनुक्रम डीडीडी के इष्टतम जोड़ के कालक्रम से मेल खाता है - परतों द्वारा। पहली परत सेवाओं , हमारे सिस्टम में व्यावसायिक परिदृश्यों (प्रक्रियाओं) का वर्णन है। इस परत के लिए स्टोरीज लाइब्रेरी जिम्मेदार है।

कहानियों

व्यावसायिक परिदृश्यों को तीन भागों में बांटा गया है:

विनिर्देश - व्यवसाय प्रक्रिया का विवरण;
वह राज्य जिसमें व्यावसायिक परिदृश्य मौजूद हो सकता है
स्क्रिप्ट के प्रत्येक चरण का कार्यान्वयन ।

इन भागों को मिश्रित नहीं होना चाहिए। द स्टोरीज़ लाइब्रेरी इन भागों को अलग करती है और उनके बीच एक स्पष्ट रेखा खींचती है।

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

डीएसएल विनिर्देश। पुस्तकालय आपको एक विनिर्देश लिखने की अनुमति देता है और इसके लिए डीएसएल प्रदान करता है। यह कदम से कदम उपयोगकर्ता का वर्णन करने का एक तरीका है। उदाहरण के लिए, खरीदने के लिए subscription, मैं कई चरणों का पालन करता हूं: मुझे एक आदेश मिलेगा, कीमत की प्रासंगिकता की जांच करें, जांचें कि क्या उपयोगकर्ता इसे खरीद सकता है। यह एक उच्च स्तरीय विवरण है।

अनुबंध।इस वर्ग के नीचे हम व्यावसायिक परिदृश्य की स्थिति के लिए एक अनुबंध लिखेंगे। ऐसा करने के लिए, हम व्यापार प्रक्रिया में उत्पन्न होने वाले चर के क्षेत्र को निरूपित करते हैं, और प्रत्येक चर के लिए हम सत्यापनकर्ताओं का एक सेट प्रदान करते हैं।

जैसे ही कोई व्यवसाय प्रक्रिया के भाग के रूप में इस क्षेत्र को एक चर सौंपने की कोशिश करता है, सत्यापनकर्ताओं के एक सेट पर काम किया जाएगा। हम यह सुनिश्चित करेंगे कि रनटाइम पर प्रक्रिया की स्थिति हमेशा काम कर रही है। लेकिन यदि नहीं, तो यह दर्द से गिरता है और इसके बारे में जोर से चिल्लाता है।

प्रत्येक चरण के कार्यान्वयन का चरण । उसी कक्षा में, subscriptionहम उन विधियों का एक सेट लिखते हैं जिनके नाम व्यापारिक चरणों के अनुरूप हैं। प्रत्येक इनपुट विधि एक ऐसी स्थिति प्राप्त करती है जिसके साथ यह काम कर सकता है, लेकिन इसे संशोधित करने का अधिकार नहीं है। विधि कुछ मार्कर वापस कर सकती है और रिपोर्ट कर सकती है:

, () ;
- , .

अधिक जटिल मार्कर हैं: वे पुष्टि कर सकते हैं कि राज्य काम कर रहा है, व्यापार प्रक्रिया के कुछ हिस्सों को हटाने या बदलने का सुझाव देता है। आप कक्षाओं में भी लिख सकते हैं।

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

डिबग टूलबार। यदि हम Django में लिखते हैं और डीबग पैनल का उपयोग करते हैं, तो हम देख सकते हैं कि प्रत्येक अनुरोध और उनकी स्थिति में व्यावसायिक परिदृश्य क्या संसाधित किए गए थे।

Py.test। यदि हम py.test में लिखते हैं, तो गिरी हुई परीक्षा के लिए हम देख सकते हैं कि प्रत्येक लाइन पर कौन सी व्यावसायिक स्क्रिप्ट निष्पादित की गई और क्या गलत हुआ। यह सुविधाजनक है - कोड में चुनने के बजाय, हम विनिर्देश पढ़ते हैं और समझते हैं कि क्या हुआ।

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

ELK । अब हम सक्रिय रूप से एक प्लगइन पर काम कर रहे हैं जो कि एलिनाटिक्स में किबाना स्टैक पर यह सब लिखता है और सक्षम इंडेक्स बनाता है।

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

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

एंटिटीज, एग्रीगेट्स और वैल्यू ऑब्जेक्ट्स

यह सब आपस में कैसे जुड़ा है? उदाहरण के लिए, एक उपयोगकर्ता एक उत्पाद ऑर्डर करता है और हम बिल देते हैं। एकत्रीकरण की जड़ क्या है, और एक साधारण वस्तु क्या है?

जो कुछ रेखांकित किया गया है वह एकत्रीकरण की जड़ है। यह वही है जो मैं सीधे काम करना चाहता हूं: महत्वपूर्ण, मूल्यवान, समग्र।

कहाँ से शुरू करें? हम परियोजना में एक खाली पैकेज बनाएंगे, जहां हम अपनी इकाइयां लगाएंगे। समुच्चय कुछ बेहतर घोषित के साथ लिखे गए हैं, जैसे dataclassesया attrs।

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

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

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

मानचित्रकारों

हम अपनी परियोजना में एक और पैकेज जोड़ते हैं - एक भंडार जिसमें हम अपने स्टोर करेंगे mappers। यह है कि हम वास्तविक दुनिया में उच्च-स्तरीय व्यावसायिक तर्क को कैसे स्थानांतरित करेंगे।

उदाहरण के लिए, हम वर्णन कर सकते हैं कि हम कैसे dataclassएक Django मॉडल के लिए मैप करते हैं ।

Django ORM। हम Django ORM के विवरण के साथ ऑर्डर मॉडल की तुलना करते हैं - हम खेतों को देखते हैं।

उदाहरण के लिए, हम वैकल्पिक कॉन्फ़िगरेशन के माध्यम से कुछ क्षेत्रों को फिर से लिख सकते हैं। निम्नलिखित होगा: mapperघोषणा के दौरान यह तुलना करेगा कि dataclassमॉडल कैसे लिखा गया है । उदाहरण के लिए, Django- मॉडल intमें एनोटेशन ( एनोटेशन के साथ Order dataclassएक क्षेत्र है ) विकल्प के साथ मेल खाता है । यहाँ यह होगा जोड़ने के लिए की पेशकश करने के लिए दूर करने के लिए, याcostintinteger fieldnullable="true"dataclassoptionaldataclassnullableसे field।

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

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

रेखांकन क्वेश्चन। ग्राफकॉइल और माइक्रोसर्विसेज: ग्राफकॉक इंटरफेस प्रकार स्कीमा के खिलाफ अच्छी तरह से काम करता हैdataclass। आप आंतरिक डेटा संरचनाओं में विशिष्ट ग्राफ़कॉल प्रश्नों का अनुवाद कर सकते हैं।

एप्लिकेशन के अंदर आंतरिक उच्च-स्तरीय डेटा मॉडल से परेशान क्यों? "क्यों," का वर्णन करने के लिए मैं एक "मनोरंजक" कहानी बताऊंगा।

हमारी एक परियोजना में, वेब सॉकेट्स ने पुशर सेवा के माध्यम से काम किया। हमने परेशान नहीं किया, हमने इसे एक इंटरफ़ेस में लपेट दिया ताकि सीधे कॉल न करें। यह इंटरफ़ेस सभी कहानियों में बंधा हुआ था और संतुष्ट था।

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

पुशर द्वारा उपयोग किए जाने वाले सार (फ़ंक्शन तर्क) प्रत्येक व्यावसायिक ऑब्जेक्ट में फंस गए हैं। मुझे लगभग 100 कहानियाँ ठीक करनी थीं, और उस उपयोगकर्ता चैनल के गठन को ठीक करना था जिसमें हम कुछ भेज रहे हैं।

वापस परीक्षणों के लिए।

टेस्ट और मोज़ेक

आप आमतौर पर बाहरी सेवाओं के साथ इस व्यवहार का परीक्षण कैसे करते हैं? हम कुछ गीला कर रहे हैं, हम देख रहे हैं कि कैसे एक तीसरे पक्ष के पुस्तकालय को बुलाया जाता है, और यह सब - हमें यकीन है कि सब कुछ ठीक है। लेकिन जब पुस्तकालय बदलते हैं, तो तर्क प्रारूप भी बदलते हैं।

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

निर्भरता

इस तरह के एक मॉडल वास्तुकला में, कई शानदार संस्थाएं दिखाई देती हैं। पहले, हमने कुछ प्रकार के Django फ़ंक्शन लिए और इसे लिखा: अनुरोध, प्रतिक्रिया, न्यूनतम बॉडी मूवमेंट। यहां आपको मैपर्स को इनिशियलाइज़ करना है, स्टोरीज़ में डालना है और इनिशियलाइज़ करना है, HTTP रिक्वेस्ट की रिक्वेस्ट लाइन को प्रोसेस करना है, जो जवाब देना है देखिए। यह सब बोएन्गप्लेट कॉलिंग कोड स्टोरीज़ की 30-50 लाइनों में Django-view के अंदर होता है।

दूसरी ओर, हम पहले से ही इंटरफेस और मैपर लिख चुके हैं। हम एक विशिष्ट व्यापार मामले के साथ उनकी संगतता की जांच कर सकते हैं, उदाहरण के लिए, निर्भरता पुस्तकालय का उपयोग कर। कैसे? निर्भरता इंजेक्शन पैटर्न के माध्यम से, सब कुछ घोषित रूप से न्यूनतम बॉयलरप्लेट से चिपके हुए है।

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

नक़ल उतारने का नक्शा

मैंने जो कुछ भी बात की थी, उसका उपयोग करके, हमने एक योजना विकसित की जिसके द्वारा हमने Django सिग्नल (निहित "कॉलबैक नरक") से एक बड़ी परियोजना को फिर से लिखा और डीडीडी का उपयोग करके Django से किया।

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

ठेके के बिना कहानियाँ। हमने डेटा अनुबंधों के बिना तार्किक व्यापार मामलों में परियोजना को तोड़ दिया।

अनुबंध और समुच्चय । फिर, एक-एक करके, हमने प्रत्येक मॉडल के लिए डेटा अनुबंध को खींच लिया, जिससे हमारी वास्तुकला में पता लगाया जा सकता है।

मैपर । मैपर्स ने डेटा वेयरहाउस टेम्प्लेट से छुटकारा पाने के लिए लिखा था।

निर्भरता इंजेक्शन । ग्लूइंग पैटर्न से छुटकारा पाएं।

यदि आपकी परियोजना एमवीपी से आगे निकल गई है और इसे तत्काल वास्तुकला में बदलने की आवश्यकता है ताकि यह विरासत में फिसल न जाए - डीडीडी की ओर देखें।

legacy Python-, , , Moscow Python Conf++ 27 . Python . unconference, , , , Drylabs.

DDD Python, TechLead Conf — IT-, DDD . 8 , Call for Papers 6 .

डोमेन संचालित डिज़ाइन उपकरण