परिचय

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

लेख में दिए गए उदाहरण हमारे LunaPark समाधान का उपयोग करके दिए गए हैं, यह आपको वर्णित दृष्टिकोणों में पहले चरणों के साथ मदद करेगा।

व्यावसायिक आवश्यकताओं से कार्यात्मक आवश्यकताओं को अलग करें।

बार-बार, ऐसा होता है कि कई व्यावसायिक विचार वास्तव में अंतिम, इच्छित उत्पाद में नहीं बदल जाते हैं। यह अक्सर व्यावसायिक आवश्यकताओं और कार्यात्मक आवश्यकताओं के बीच अंतर को समझने में असमर्थता के कारण होता है, जो अंततः आवश्यकताओं के अनावश्यक संग्रह, अनावश्यक दस्तावेज, परियोजना में देरी और प्रमुख परियोजना विफलताओं की ओर जाता है।

या कभी-कभी हम उन स्थितियों से सामना करते हैं जिनमें, हालांकि अंतिम समाधान ग्राहकों की जरूरतों को पूरा करता है, लेकिन किसी भी तरह व्यावसायिक लक्ष्यों को प्राप्त नहीं किया जाता है।

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

मान लीजिए कि हम एक पिज्जा डिलीवरी कंपनी के लिए एक आवेदन लिख रहे हैं, और हमने एक कूरियर ट्रैकिंग सिस्टम बनाने का फैसला किया। व्यावसायिक आवश्यकताएं इस प्रकार हैं:

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

यहां हम कई विशिष्ट विशेषताओं को अलग कर सकते हैं जो इंगित करेंगे कि ये व्यवसाय से आवश्यकताएं हैं:

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

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

• सिस्टम को GPS / GLONASS के माध्यम से कर्मचारी के देशांतर और अक्षांश को प्रदर्शित करना चाहिए;
• सिस्टम को मानचित्र पर कर्मचारियों के पदों को प्रदर्शित करना चाहिए;
• सिस्टम को प्रबंधकों को अपने क्षेत्र अधीनस्थों को सूचनाएं भेजने की अनुमति देनी चाहिए।

हम निम्नलिखित विशेषताओं पर प्रकाश डालते हैं:

• कार्यात्मक आवश्यकताओं को हमेशा सिस्टम के दृष्टिकोण से लिखा जाता है;
• वे अधिक विशिष्ट और विस्तृत हैं;
• यह कार्यात्मक आवश्यकताओं की पूर्ति के लिए धन्यवाद है कि एक प्रभावी समाधान विकसित किया जाता है जो व्यवसाय की जरूरतों और ग्राहक के लक्ष्यों को पूरा करता है;
• सवाल का जवाब " कैसे ।" सिस्टम व्यावसायिक आवश्यकताओं को कैसे हल करता है।

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

विकास व्यावसायिक आवश्यकताओं में व्यावसायिक आवश्यकताओं का अनुवाद है। एप्लाइड प्रोग्रामिंग कार्यात्मक आवश्यकताओं का कार्यान्वयन है, और सिस्टम - गैर-कार्यात्मक।

मामलों का उपयोग करें

कार्यात्मक आवश्यकताओं को लागू करना अक्सर वाणिज्यिक प्रणालियों में सबसे जटिल होता है। एक शुद्ध वास्तुकला में, कार्यात्मक आवश्यकताओं का उपयोग केस केस परत के माध्यम से किया जाता है।

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

1. कहानी कहने के माध्यम से उन्हें सरल बनाना;
2. एक रणनीतिक योजना है, पूरी तस्वीर से अवगत रहें;
3. अर्थ पर ध्यान केंद्रित;
4. परतों में सिस्टम को पंक्तिबद्ध करें;
5. सिस्टम चरण को चरणबद्ध तरीके से वितरित करें;
6. टीम की जरूरतों को पूरा करें।

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

कहानी कहने के माध्यम से सरलता

कथन हमारी संस्कृति का हिस्सा है; ज्ञान, सूचना को एक व्यक्ति से दूसरे व्यक्ति में स्थानांतरित करने का यह सबसे आसान और प्रभावी तरीका है। यह संवाद करने का सबसे अच्छा तरीका है कि सिस्टम को क्या करना चाहिए और टीम को सामान्य लक्ष्यों पर ध्यान केंद्रित करने में मदद करना चाहिए।

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

यह सिद्धांत डीडीडी दृष्टिकोण से उबिक्स भाषा के साथ सहसंबंधित है।

पूरी तस्वीर को समझना

भले ही आप किस सिस्टम को विकसित कर रहे हैं, बड़े, छोटे, सॉफ्टवेयर, हार्डवेयर या व्यवसाय, बड़ी तस्वीर को समझना बहुत महत्वपूर्ण है। सिस्टम को समग्र रूप से समझे बिना, आप सही निर्णय नहीं ले सकते हैं कि सिस्टम में क्या शामिल किया जाए, क्या नियम बनाया जाए, इसकी लागत कितनी होगी और इससे क्या लाभ होंगे।

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

मूल्य पर ध्यान दें

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

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

इसके अलावा, लेखक एक अद्भुत योजना देता है, जिस पर सबसे अधिक ध्यान दिया जाना चाहिए:

आरेख एक उपयोग मामला दिखाता है, "एटीएम में नकद निकासी"। लक्ष्य प्राप्त करने का सबसे आसान तरीका बेसिक डायरेक्शन (मूल प्रवाह) में वर्णित है। अन्य मामलों को वैकल्पिक प्रवाह के रूप में वर्णित किया गया है। ये निर्देश कहानी कहने, प्रणाली की संरचना करने और परीक्षण लेखन में मदद करते हैं।

लेयरिंग

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

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

ये विचार चपल दृष्टिकोण और डोमेन विचारों के साथ प्रतिध्वनित होते हैं।

चरण-दर-चरण उत्पाद लॉन्च

अधिकांश सॉफ्टवेयर सिस्टम कई पीढ़ियों में विकसित हुए हैं। वे एक समय में उत्पादित नहीं होते हैं; उन्हें रिलीज़ की एक श्रृंखला के रूप में बनाया गया है, जिनमें से प्रत्येक को पिछली रिलीज़ पर बनाया गया है। यहां तक ​​कि स्वयं रिलीज़ अक्सर एक बार में बाहर नहीं जाते हैं, लेकिन मध्यवर्ती संस्करणों की एक श्रृंखला के माध्यम से विकसित होते हैं। प्रत्येक चरण सिस्टम का एक स्पष्ट, प्रयोग करने योग्य संस्करण प्रदान करता है। यह वह तरीका है जिससे सभी सिस्टम बनाए जाने चाहिए।

टीम की जरूरतों को पूरा करें

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

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

कार्यान्वयन

शुद्ध वास्तुकला में, रॉबर्ट मार्टिन निम्नलिखित उपयोग के मामलों को परिभाषित करता है:

ये उपयोग के मामले और संस्थाओं से डेटा के प्रवाह को ऑर्केस्ट्रेट करते हैं, और उन संस्थाओं को निर्देश देते हैं कि वे उपयोग के लक्ष्यों को प्राप्त करने के लिए अपने महत्वपूर्ण व्यावसायिक नियमों का उपयोग करें।

आइए इन विचारों को कोड में अनुवाद करने का प्रयास करें। आइए इस योजना को उपयोग मामलों के तीसरे सिद्धांत से याद करते हैं और इसे आधार के रूप में लेते हैं। वास्तव में जटिल व्यावसायिक प्रक्रिया पर विचार करें: "कुकिंग ए गोभी पाई"।

चलो इसे विघटित करने का प्रयास करें:

• उत्पाद की उपलब्धता की जाँच करें;
• उन्हें स्टॉक से ले लो;
• आटा गूंध;
• आटा उठने दो;
• भरने को तैयार करें;
• एक पाई बनाओ;
• एक पाई बेक करें।

हम इस पूरे अनुक्रम को इंटरएक्टर के माध्यम से कार्यान्वित करते हैं, और प्रत्येक चरण को सेवा परत पर एक फ़ंक्शन या कार्यात्मक वस्तु के माध्यम से लागू किया जाएगा।

क्रियाओं का अनुक्रम (इंटरेक्टर)

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

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

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

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

अनुक्रम डिजाइन टेम्पलेट इसके लिए जिम्मेदार है:

• क्रियाओं का क्रम;
• क्रियाओं के बीच संचरित डेटा का समन्वय;
• निष्पादन के दौरान क्रियाओं द्वारा किए गए प्रसंस्करण त्रुटियों;
• प्रतिबद्ध कृत्यों के सेट के परिणाम की वापसी;
• महत्वपूर्ण : इस डिजाइन पैटर्न की सबसे महत्वपूर्ण जिम्मेदारी व्यावसायिक तर्क का कार्यान्वयन है।

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

आइए पाई पर वापस जाएं: आइए इंटरएक्टर के माध्यम से इसकी तैयारी की प्रक्रिया का वर्णन करें।

कार्यान्वयन

मैं हमारे LunaPark समाधान के साथ एक उदाहरण कार्यान्वयन देता हूं, जिसे हमने पिछले लेख में प्रस्तुत किया था।

module Kitchen module Sequences class CookingPieWithabbage < LunaPark::Interactors::Sequence TEMPERATURE = Values::Temperature.new(180, unit: :cel) def call! Services::CheckProductsAvailability.call list: ingredients dough = Services::BeatDough.call from: Repository::Products.get(beat_ingredients) filler = Services::MakeabbageFiller.call from: Repository::Products.get(filler_ingredients) pie = Services::MakePie.call dough, with: filler bake = Services::BakePie.new pie, temp: TEMPERATURE sleep 5.min until bake.call pie end private attr_accessor :beat_ingredients, :filler_ingredients attr_accessor :pie def ingredients_list beat_ingredients_list + filler_ingredients_list end end end end 

जैसा कि हम देख सकते हैं, call! केक बेकिंग प्रक्रिया के पूरे व्यापार तर्क का वर्णन करता है। और आवेदन के तर्क को समझने के लिए उपयोग करना सुविधाजनक है।

इसके अलावा, हम MakeabbageFiller को MakeFishFiller साथ बदलकर मछली पाई को पकाने की प्रक्रिया का आसानी से वर्णन कर सकते हैं। इस प्रकार, हम महत्वपूर्ण कोड संशोधनों के बिना, व्यवसाय प्रक्रिया को बहुत जल्दी बदल देते हैं। और यह भी, हम एक ही समय में दोनों दृश्यों को छोड़ सकते हैं, व्यावसायिक मामलों को बढ़ा सकते हैं।

सहमति

• call! विधि call! एक आवश्यक विधि है, यह क्रियाओं के क्रम का वर्णन करता है।
• प्रत्येक आरंभीकरण पैरामीटर को एक सेटर या attr_acessor माध्यम से वर्णित किया जा सकता है:

 class Foo < LunaPark::Interactors::Sequence # ... private attr_accessor :bar end Foo.call(bar: 42) 

• बाकी विधियां निजी होनी चाहिए।

उदाहरण का उपयोग करें

 beat_ingredients = [ Entity::Product.new :flour, 500, :gr, Entity::Product.new :oil, 50, :gr, Entity::Product.new :salt, 1, :spoon, Entity::Product.new :milk, 150, :ml, Entity::Product.new :egg, 1, :unit, Entity::Product.new :yeast, 1, :spoon ] filler_ingredients = [ Entity::Product.new :cabbage, 500, :gr, Entity::Product.new :salt, 1, :spoon, Entity::Product.new :pepper, 1, :spoon ] cooking = CookingPieWithabbage.call( beat_ingredients: beat_ingredients, filler_ingredients: filler_ingredients ) #   : cooking.success? # => true cooking.fail # => false cooking.fail_message # => '' cooking.data # => Entity::Pie #   : cooking.success? # => false cooking.fail # => true cooking.fail_message # => 'The pie burned out' cooking.data # => nil 

ऑब्जेक्ट के माध्यम से प्रक्रिया का प्रतिनिधित्व किया जाता है और हमारे पास इसे कॉल करने के लिए सभी आवश्यक तरीके हैं - क्या कॉल सफल हुआ, क्या कॉल के दौरान कोई त्रुटि हुई, और यदि ऐसा है, तो कौन सा?

हैंडलिंग में त्रुटि

यदि हम अब Use Case के तीसरे सिद्धांत को याद करते हैं, तो हम इस तथ्य पर ध्यान देते हैं कि मेन लाइन के अलावा, हमारे पास वैकल्पिक निर्देश भी थे। ये त्रुटियां हैं जिन्हें हमें संभालना चाहिए। एक उदाहरण पर विचार करें: हम निश्चित रूप से इस तरह की घटनाओं को नहीं चाहते हैं, लेकिन हम इसके बारे में कुछ भी नहीं कर सकते, कठोर वास्तविकता यह है कि समय-समय पर जलन होती है।

इंटरएक्टर LunaPark::Errors::Processing वर्ग से विरासत में मिली सभी त्रुटियों को LunaPark::Errors::Processing ।

हम केक पर नज़र कैसे रखेंगे? ऐसा करने के लिए, BakePie क्रिया में BakePie त्रुटि को परिभाषित करें।

 module Kitchen module Errors class Burned < LunaPark::Errors::Processing; end end end 

और बेकिंग के दौरान, जांच लें कि हमारा पाई बाहर जला नहीं है:

 module Kitchen module Services class BakePie < LunaPark::Callable def call # ... rescue Errors::Burned, 'The pie burned out' if pie.burned? # ... end end end end 

इस स्थिति में, त्रुटि जाल काम करेगा, और हम में उनके साथ सौदा करने में सक्षम होंगे।
Processing से विरासत में नहीं मिली त्रुटियों को सिस्टम त्रुटियों के रूप में माना जाता है और इसे सर्वर स्तर पर इंटरसेप्ट किया जाएगा। जब तक अन्यथा निर्दिष्ट न हो, उपयोगकर्ता को 500 ServerError प्राप्त होगी।

अभ्यास का उपयोग करें

1. कॉल विधि में सभी कॉल का वर्णन करने का प्रयास करें!

आपको प्रत्येक एक्शन को एक अलग तरीके से लागू नहीं करना चाहिए, इससे कोड अधिक फूला हुआ होता है। यह कैसे काम करता है यह समझने के लिए आपको कई बार पूरी कक्षा को देखना होगा। एक पाई पकाना के लिए नुस्खा बिगाड़ें:

 module Service class CookingPieWithabbage < LunaPark::Interactors::Sequence def call! check_products_availability make_cabbage_filler make_pie bake end private def check_products_availability Services::CheckProductsAvailability.call list: ingredients end # ... end end 

कक्षा में सीधे एक्शन कॉल का उपयोग करें। माणिक के दृष्टिकोण से, यह दृष्टिकोण असामान्य लग सकता है, इसलिए यह अधिक पठनीय लगता है:

 class DrivingStart < LunaPark::Interactors::Sequence def call! Service::CheckEngine.call Service::StartUpTheIgnition.call car, with: key Service::ChangeGear.call car.gear_box, to: :drive Service::StepOnTheGas.call car.pedals[:right] end end 

2. यदि संभव हो, तो कॉल क्लास विधि का उपयोग करें

 # good - ,   ,  . #    . Sequence::RingingToPerson.call(params) # good -   ,      e, #    ,     , #    . ring = Sequence::RingingToPerson.new(person) unless ring.success? ring.call sleep 5.min end 

3. कोड टाइप करने के लिए फंक्शनल ऑब्जेक्ट न बनाएं, स्थिति के अनुसार देखें

 # bad -        ,  #     . module Services class BuildUser < LunaPark::Callable def initialize(first_name:, last_name:, phone:) @first_name = first_name @last_name = last_name @phone = phone end def call Entity::User.new( first_name: first_name, last_name: last_name, phone: phone ) end private attr_reader :first_name, :last_name, :phone end end module Sequences class RegisteringUser < LunaPark::Interactors::Sequence attr_accessor :first_name, :last_name, :phone def call! user = Service::BuildUser.call(first_name: first_name, last_name: last_name, phone: phone) end end end # good -     ,  . #        , #       . module Sequences class RegisteringUser < LunaPark::Interactors::Sequence attr_accessor :first_name, :last_name, :phone def call! user #... end private def user @user = Entity::User.new( first_name: first_name, last_name: last_name, phone: phone ) end end end 

सेवा परत

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

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

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

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

 module Entities class Wood def chop # ... end end end 

यह विधि गलती होगी। जलाऊ लकड़ी खुद नहीं काटेंगे, हमें एक कुल्हाड़ी चाहिए:

 module Entities class Axe def chop(sacrifice) # ... end end end 

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

 module Entities class Human def chop_firewood(wood, axe, chock) # ... end end end 

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

 module Services class ChopFirewood # ... end end 

हमने यह पता लगाने के बाद कि हम सेवाओं में क्या तर्क रखते हैं , हम उनमें से एक को लागू करने का प्रयास करेंगे। अधिकतर, सेवाओं को विधियों या कार्यात्मक वस्तुओं के माध्यम से कार्यान्वित किया जाता है।

क्रियात्मक वस्तुएँ

एक कार्यात्मक वस्तु एक कार्यात्मक आवश्यकता को पूरा करती है। अपने सबसे आदिम रूप में, एक कार्यात्मक वस्तु में एक एकल सार्वजनिक विधि होती है - call ।

 module Serivices class Sum def initialize(x, y) @x = x @y = y end def call x + y end def self.call(x,y) new(x,y).call end private attr_reader :x, :y end end 

ऐसी वस्तुओं के कई फायदे हैं: वे संक्षिप्त हैं, वे परीक्षण करने के लिए बहुत सरल हैं। एक खामी है, ऐसी वस्तुएं बड़ी संख्या में हो सकती हैं। समान वस्तुओं को समूहित करने के कई तरीके हैं; हमारी परियोजनाओं के हिस्से में, हम उन्हें प्रकार से विभाजित करते हैं:

• सेवा वस्तु (सेवा) - एक वस्तु, एक नई वस्तु बनाता है;
• कमांड (कमांड) - वर्तमान वस्तु को बदलता है;
• गार्जियन (गार्ड) - अगर कुछ गलत हुआ तो एक त्रुटि देता है।

सेवा वस्तु

हमारे कार्यान्वयन में, सेवा - एक कार्यात्मक आवश्यकता को लागू करती है और हमेशा एक मूल्य लौटाती है।

 module KorovaMilkBar module Services class FindMilk < LunaPark::Callable GLASS_SIZE = Values::Unit.wrap '200g' def initialize(fridge:) @fridge = fridge end def call fridge.shelfs.find { |shelf| shelf.has?(GLASS_SIZE, of: :milk) } end private attr_reader :fridge end end end FindMilk.call(fridge: the_red_one) # => #<Glass: ... > 

कमान (कमान)

हमारे कार्यान्वयन में, कमांड - एक एक्शन करता है, ऑब्जेक्ट को संशोधित करता है, अगर सही रिटर्न सही है। वास्तव में, टीम एक वस्तु नहीं बनाती है, लेकिन एक मौजूदा को संशोधित करती है।

 module KorovaMilkBar module Commands class FillGlass < LunaPark::Callable def initialize(glass, with:) @glass = glass @content = with end def call glass << content true end private attr_reader :fridge end end end glass = Glass.empty milk = Milk.new(200, :gr) glass.empty? # => true FillGlass.call glass, with: milk # => true glass.empty? # => false 

अभिभावक (गार्ड)

चौकीदार एक तार्किक जाँच करता है और विफलता के मामले में एक प्रसंस्करण त्रुटि देता है। इस प्रकार की वस्तु मुख्य दिशा को किसी भी तरह से प्रभावित नहीं करती है, लेकिन कुछ गलत होने पर हमें वैकल्पिक दिशा में ले जाती है।

दूध परोसते समय, यह सुनिश्चित करना ज़रूरी है कि यह ताज़ा हो:

 module KorovaMilkBar module Guards class IsFresh < LunaPark::Callable def initialize(product) @products = products end def call products.each do |product| raise Errors::Rotten, "#{product.title} is not fresh" if product.expiration_date > Date.today end nil end private attr_reader :products end end end 

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

सहमति

• call विधि केवल अनिवार्य सार्वजनिक विधि है।
• initialize विधि एकमात्र वैकल्पिक सार्वजनिक विधि है।
• बाकी विधियां निजी होनी चाहिए।
• तार्किक त्रुटियों को LunaPark::Errors::Processing वर्ग से विरासत में मिला होना चाहिए।

हैंडलिंग में त्रुटि

क्रिया के संचालन के दौरान 2 प्रकार की त्रुटियां हो सकती हैं।

रनटाइम त्रुटियां

प्रसंस्करण तर्क के उल्लंघन के परिणामस्वरूप ऐसी त्रुटियां हो सकती हैं।

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

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

सभी संभावना में, उपयोगकर्ता इन त्रुटियों के बारे में जानना चाहेगा। साथ ही, ये शायद गलतियां हैं
जिसे हम देख सकते हैं।

इस तरह की त्रुटियों को LunaPark::Errors::Processing से विरासत में मिला होना चाहिए

सिस्टम की त्रुटियां

सिस्टम क्रैश के परिणामस्वरूप उत्पन्न त्रुटियां।

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

• डेटाबेस काम नहीं करता है;
• शून्य से विभाजित कुछ।

सभी संभावना में, हम इन त्रुटियों को दूर नहीं कर सकते हैं और उपयोगकर्ता को कुछ भी नहीं कह सकते हैं, सिवाय इसके कि सब कुछ बहुत बुरा है, और डेवलपर्स को कार्रवाई के लिए रिपोर्ट करने के लिए रिपोर्ट भेजें। इस तरह की त्रुटियां SystemError से विरासत में मिलनी चाहिए

सत्यापन त्रुटियां भी हैं , जिनके बारे में हम अगले लेख में अधिक विस्तार से चर्चा करेंगे।

अभ्यास का उपयोग करें

1. पठनीयता बढ़ाने के लिए चर का उपयोग करें

 module Fishing # bad -   Serivices::Catch.call(fish, rod) # bad -  Serivices::Catch.call(fish: fish, rod: rod) # good -   Serivices::Catch.call(fish, with: rod) module Serivices class Catch def initialize(fish, with:) @fish = fish @rod = with #      #   . end # ... private attr_reader :fish, :rod end end end 

2. वस्तुओं को पारित करें, मापदंडों को नहीं

यदि पैरामीटर प्रसंस्करण इसका उद्देश्य नहीं है तो इनिशियलाइज़र को सरल बनाने का प्रयास करें।
ऑब्जेक्ट पास करें, पैरामीटर नहीं।

 module Service # bad -        -.  #      ,   . class Foo def initialize(foo_params:, bar_params:) @foo = Values::Foo.new(*foo_params) @bar = Values::Bar.new(*bar_params) end # ... end Services::Foo.call(foo: {a: 1, b: 2}, bar: 34) # good -   -. class Bar def initialize(foo:, bar:) @foo = foo @bar = bar # ... end end foo = Values::Foo.new(a: 1, b: 2) bar = Values::Bar.new(34) Services::Bar.call(foo: foo, bar: bar) # good -       - Builder. class BuildFoo def initialize(param_1:, param_2:) @param_1 = param_1 @param_1 = param_1 end def call Foo.new( param_1: param_1.foo, param_2: param_2.bar, param_3: some_magick ) end # ... end end 

3. नाम क्रिया का उपयोग करें - क्रिया की क्रिया और प्रभाव की वस्तु।

 # bad module Services class Milk; end class Work; end class FooBuild; end class PasswordGenerator; end end # good module Services class GetMilk; end class WorkOnTable; end class BuildFoo; end class GeneratePassword; end end 

4. यदि संभव हो, तो कॉल क्लास विधि का उपयोग करें

आमतौर पर ऐक्शन क्लास का एक उदाहरण, कॉल करने के लिए लिखने के अलावा शायद ही कभी इस्तेमाल किया गया हो।

 # good -    . Services::BuildFoo.call(params) # good -     Services::BuildFoo.(params) # good -   ,      , #    ,     ,   #  . ring = Services::RingToPhone.new(phone: neighbour) 10.times do ring.call end 

5. त्रुटि से निपटने कोई सेवा कार्य नहीं है

 # bad -    ,   . def call #... rescue SystemError => e return false end 

मॉड्यूल

इस क्षण तक, हमने सेवा परत के कार्यान्वयन को कार्यात्मक वस्तुओं के एक सेट के रूप में माना। लेकिन हम आसानी से इस परत पर तरीके रख सकते हैं:

 module Services def sum(a, b) a + b end end 

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

 class NoonService def initialize(arina_radionovna, pushkin) # ... end def to_feed # ... end def to_sleep # ... end end 

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

 module Services module Noon class ToFeed def call! # ... end end class << self #    ,   #    def to_feed(arina_radionovna, pushkin) ToFeed.new(arina_radionovna, pushkin).call end #    ,    def to_sleep(arina_radionovna, pushkin) arina_radionovna.tell_story pushkin pushkin.state = :sleep end end end end 

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

बड़ी नीली किताब से एक और छोटा अंश उद्धृत करने के लिए:

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

मॉड्यूल नाम दें जिन्हें UNIFIED LANGUAGE में शामिल किया जाएगा। दोनों मॉड्यूल खुद और उनके नाम विषय क्षेत्र के ज्ञान और समझ को दर्शाते हैं।

मॉड्यूल का विषय बड़ा और दिलचस्प है, लेकिन पूरी तरह से इस लेख के विषय से परे है। अगली बार हम आपसे Repositories और Adapters के बारे में बात करेंगे। हमने एक आरामदायक टेलीग्राम चैनल खोला जहां हम डीडीडी के विषय पर सामग्री साझा करना चाहते हैं। हम आपके सवालों और प्रतिक्रिया का स्वागत करते हैं।