परिचय

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

सिस्टम के भीतर समस्या को हल करने का अनुमान लगाया जा सकता है, हमने ब्लैक बॉक्स के साथ काम करना बंद कर दिया, और अंत में, सिस्टम ने ही हमें समाधान के साथ संकेत देना शुरू कर दिया।

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

कोश

थिसॉरस एक विशिष्ट विषय क्षेत्र का वर्णन करने के लिए उपयोग की जाने वाली शब्दावली है।

नीचे दी गई सभी परिभाषाएँ इस लेख के ढांचे के भीतर सही हैं। आप उन्हें अपने विषय क्षेत्र में लागू कर सकते हैं यदि वे इसे अच्छी तरह से वर्णन करते हैं।

इस दृष्टिकोण के ढांचे के भीतर हल की गई समस्या

नीचे वर्णित दृष्टिकोण में एक संकीर्ण संकीर्णता है, और, सबसे ऊपर, एक विशिष्ट समस्या को हल करने के उद्देश्य से है। फिर भी, यह संबंधित क्षेत्रों के विशेषज्ञों से संभावित ब्याज को बाहर नहीं करता है। तो, हमारे पास कार्य है:

आपको पर्याप्त संसाधनों के साथ रूबी ऑन रेल्स में लिखे गए जटिल व्यावसायिक तर्क को फिर से लिखने और बनाए रखने की आवश्यकता है।

आइए इस कार्य को और अधिक विस्तार से लिखें।

परियोजना को फिर से लिखने की आवश्यकता क्यों है?

मुझे लगता है कि हर डेवलपर इस सवाल का जवाब दे सकता है। इसका उत्तर देना कठिन है, ताकि यह उत्तर आपके व्यवसाय की जरूरतों को पूरा करे।

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

व्यवसाय लोगों की एक कंपनी का प्रयास है, जिसका उद्देश्य व्यक्तियों की एक विस्तृत श्रृंखला के लिए लाभ प्राप्त करना है।

उदाहरण के लिए:

• कंपनी उपभोक्ताओं के लिए एक उत्पाद बनाती है या एक सेवा प्रदान करती है।
• प्रयोगशाला एक नई दवा विकसित कर रही है।
• विद्यालय प्रशिक्षण में लगा हुआ है।
• सिटी आर्काइव नागरिकों को जानकारी प्रदान करता है।
• लेरा सोशल नेटवर्क पर एक शानदार फिगर के साथ अपने प्रशंसकों को प्रसन्न करती है।

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

प्रतिस्पर्धात्मकता - एक व्यवसाय का दूसरे पर लाभ।

एजाइल मैनिफेस्टो हमें एक संकेत भी देता है कि प्रोजेक्ट लचीलापन इसकी तकनीकी उत्कृष्टता और डिजाइन गुणवत्ता के माध्यम से बढ़ाया जाता है।

"विशिष्ट वेब-प्रोजेक्ट" के उदाहरण पर मूल्यों की आपूर्ति श्रृंखला पर विचार करें

• t ₀ - हमें एक विचार मिला।
• t ₁ हमने एमवीपी लागू किया । यहाँ हम थोड़ा खोदते हैं:
  

  एमवीपी न्यूनतम व्यवहार्य उत्पाद - एक ऐसा उत्पाद जिसमें न्यूनतम, लेकिन पहले उपभोक्ताओं, कार्यों को संतुष्ट करने के लिए पर्याप्त है। मुख्य कार्य आगे के उत्पाद विकास के लिए परिकल्पना के गठन के लिए प्रतिक्रिया प्राप्त करना है।
  

इस शब्द को स्टीव ब्लैंक और एरिक रीस ने लोकप्रिय बनाया। MVP आपके व्यवसाय के विचार का परीक्षण करने और मुख्य प्रश्न का उत्तर देने के लिए एक प्रभावी साधन है "टेक ऑफ - टेक ऑफ नहीं होगा?"

• टी ₂ - वापस अनुसूची पर। यह विचार सफल था, हमें सकारात्मक प्रतिक्रिया मिली और संकेतित समय पर बड़ी संख्या में ग्राहकों की जरूरतों को पूरा करने में सक्षम थे।
• t ₃ - इस बार, संतुष्टि कुछ हद तक कम हुई। हमने स्टाफ बढ़ाया है।
• टी ₄ - हमने और भी कम मूल्य दिए।
• t ₅ - यदि हमने Refactoring शुरू नहीं की है, तो इस समय व्यवसाय प्रतिस्पर्धी होना बंद हो जाता है।

ऐसा क्यों हो रहा है? समय के साथ, हमारी परियोजना उच्च कनेक्टिविटी के कारण उच्च स्तर की एन्ट्रापी जमा करती है। मान लीजिए कि हमारे पास एक "विशिष्ट कंपनी" है जिसमें एक विपणन, विश्लेषण, रसद, बिक्री और प्रबंधन विभाग शामिल हैं। फिलहाल, परियोजना इस प्रकार है:

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

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

अभिन्न (लाइन के तहत क्षेत्र) अर्जित धन होगा। वास्तविक ऐप (रियल ऐप) "आदर्श" (एकेडेमिन ऐप) से अधिक कमाएगा, कम से कम एंट्रॉपी - टी ₄ की शुरुआत तक। यह अच्छा लगता है, और आपको यही करना है।

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

जटिल प्रणालियों को लागू करने का एक तरीका DDD है:

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

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

इस पैटर्न को एक नेमस्पेस (नेमस्पेस) और माइक्रोसेवर्स के माध्यम से लागू किया जा सकता है। हम संदर्भ कनेक्टिविटी के स्तर के आधार पर इन दोनों कार्यान्वयनों का उपयोग करेंगे। जो अंततः एक विघटित, खंडित अनुप्रयोग के निर्माण की ओर ले जाता है।

उपरोक्त रेखांकन वास्तविक चित्र को प्रतिबिंबित करने की संभावना नहीं है, लेकिन आप अपने बीच विभिन्न दृष्टिकोणों की तुलना करने की अनुमति देते हैं।

परियोजना का समर्थन

परियोजना के समर्थन के हिस्से के रूप में, कई चीजों को प्रदान करने की आवश्यकता है।

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

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

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

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

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

संक्षिप्त

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

अगली बार मैं और अधिक विस्तार से डीडीडी दृष्टिकोण और इसके माइक्रो सर्विस के सार पर विचार करना चाहूंगा।

प्रेरणा के स्रोत:

• https://habr.com/post/351242/
• http://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html
• http://agilemanifesto.org/iso/ru/principles.html
• http://dddcommunity.org/learning-ddd/what_is_ddd/
• https://martinfowler.com/bliki/BoundedContext.html
• सैम न्यूमैन द्वारा माइक्रोसिस्टम्स बनाना
• हिचहाइकर गाइड टू द गैलेक्सी, डगलस एडम्स