परिचय

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

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

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

DDD

पिछली परिभाषा को याद करें:

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

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

डीडीडी के लिए विहित स्रोत एरिक इवांस की पुस्तक है। यह सॉफ्टवेयर साहित्य में सबसे आसान पढ़ा नहीं है, लेकिन यह उन पुस्तकों में से एक है जो पर्याप्त निवेश को दोहराता है।

मार्टिन फाउलर: 15 जनवरी 2014

यदि आप पुस्तक की सामग्री के माध्यम से स्क्रॉल करते हैं, तो यह आपको काफी संरचित नहीं लगेगा। लेकिन नक्शा हमारी मदद करेगा।

मानचित्र पर वे अभ्यास हैं, जिन पर हम आज विचार करेंगे।

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

• उत्पादकता बढ़ाएं।
• समझदार कोड लिखें।
• सॉफ्टवेयर विकास के स्तर पर स्केलिंग।

एकल भाषा

सॉफ्टवेयर विकास शायद ही कभी कुछ नया बनाने की ओर ले जाता है, एक नियम के रूप में, यह मौजूदा चीज़ का अनुकरण है।

एक मॉडल एक वास्तविक वस्तु का प्रतिनिधित्व है, जिसमें केवल आवश्यक गुण और कार्य शामिल हैं।

हम एक सॉफ्टवेयर उत्पाद नहीं बना सकते हैं जो पूरे विषय क्षेत्र को कवर करता है। केवल उस हिस्से को पुन: पेश करना संभव है जो आवश्यक कार्यक्षमता को पुन: पेश करेगा।

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

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

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

प्रोजेक्ट डॉक्यूमेंटेशन कैसे रखें

1. व्यवसाय और विकास के बीच किसी भी संचार को आपके मॉडल में सुधार करना चाहिए।
2. बैठक के बाद, परिणाम को दस्तावेज़ीकरण (स्क्रैम विरूपण साक्ष्य) के रूप में रिकॉर्ड करें, और विकास प्रक्रिया में सभी प्रतिभागियों को यह दस्तावेज़ दिखाएं।
3. प्रलेखन में एकल भाषा का उपयोग करें।
4. सबसे महत्वपूर्ण: प्रलेखन पर समय बर्बाद मत करो। आपको अभी भी कोड लिखना है, और प्रलेखन कई बार फिर से लिखा जाएगा, संसाधनों को खर्च करना महंगा है। लंबे समय तक यूएमएल चार्टिंग एप्लिकेशन के साथ गड़बड़ करने के बजाय, अपने फोन पर एक नैपकिन, पेन और कैमरा का उपयोग करें।
5. प्रलेखन के लिए अनुशासन की आवश्यकता होती है; आप इसे समय-समय पर नहीं लिख सकते।
6. प्रलेखन अलग करें:
   
   • कोड में टिप्पणियाँ - कोड में सीधे समझ से बाहर के क्षणों का वर्णन करें, #ODO: छोड़ें #ODO: (कोड को मास्टर में विलय करते समय हटा दें)। टिप्पणियों में अपनी राय व्यक्त करें, उदाहरण के लिए, आपको लीगासी कोड के साथ काम करते समय एक या दूसरे बैसाखी का उपयोग करना होगा।
   • आपके प्रोजेक्ट की रूट डायरेक्टरी में README.md प्रोजेक्ट की टिप्पणियों में तकनीकी जानकारी होनी चाहिए: प्रोजेक्ट कैसे शुरू करें, परीक्षण कैसे चलाएं आदि। यह एक अच्छा विचार है कि आपके पास सभी प्रोजेक्ट हैं और वे किस सर्वर पर चल रहे हैं। सभी स्वीकृत समझौतों को अलग-अलग रिकॉर्ड करें।
   • और सबसे महत्वपूर्ण बात, ज्ञान का आधार। व्यावसायिक प्रक्रियाओं का वर्णन करने वाले दस्तावेजों का एक संग्रह, यह दस्तावेजों का एक हिस्सा है जो आपके और व्यवसाय दोनों के लिए उपलब्ध है।
7. प्रलेखन लिखने वालों की मुख्य गलती अतिरेक है। सब कुछ और सब कुछ कवर करने की कोशिश न करें, केवल सामान्य अर्थ बताएं। प्रलेखन को आपकी परियोजना का पूरक होना चाहिए, लेकिन इसे किसी भी तरह से प्रतिस्थापित नहीं करना चाहिए। उन सभी शब्दों को न लिखें जो केवल अस्पष्ट हैं। यदि एक परिभाषा में दो से अधिक वाक्य हैं, तो यह एक खराब परिभाषा है।

प्रलेखन उदाहरण:

 #         . # :  : -    - email -  ## : ###        ,     email  ,    1  (      email  ). ###           .          email . ###  email  email     .    ,    email.   . ###       ,     ,    .   . ###      email,    ,       .   2 . ###                  .    ,     ,             . 

ध्यान दें कि इस उदाहरण में हमने एक स्पष्ट शब्दकोश निर्दिष्ट नहीं किया है, फिर भी हमने उपयोगकर्ता , प्राधिकरण , पंजीकरण की अवधारणा को निर्धारित किया है। इस तरह के प्रलेखन को लिखने में विशेषज्ञ को 20 मिनट से अधिक नहीं लगेगा।

एक व्यक्ति जो विषय क्षेत्र का विशेषज्ञ नहीं है, के लिए प्रलेखन लिखने की प्रक्रिया को कुछ जटिल माना जाता है। ज्ञान के संग्रह और एकत्रित ज्ञान के रिकॉर्ड को अलग करना आवश्यक है। != + .

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

- असामान्य रूप से स्पष्ट रूप से कहा गया है! - अवधेश की प्रशंसा की। - आश्चर्यजनक रूप से स्पष्ट! "उन्हें लगा कि वे दार्शनिक को समझ गए हैं, क्योंकि वे जानते थे कि प्याज क्या था।"

एबरडीन स्टोरी, क्रिस्टोव मार्टिन वेलैंड

सीमित संदर्भ और डोमेन

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

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

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

• ग्राहक पंजीकरण
• पिज़्ज़ेरिया पंजीकरण
• कूरियर पंजीकरण
• आदेश पंजीकरण

एक एकीकृत भाषा एक सीमित संदर्भ में होती है। उपरोक्त प्रलेखन का डोमेन 'प्राधिकरण प्रणाली' है। आइए हमारे स्टार्टअप के लिए डोमेन आवंटित करने का प्रयास करें।

लेकिन इससे पहले कि हम शुरुआत करें, आइए थोड़ा शब्दावली देखें कि डोमेन क्या है और सीमित संदर्भ क्या है।

डोमेन (डोमेन) - एक वास्तविक व्यवसाय संरचना का प्रतिनिधित्व जो एक विशिष्ट समस्या को हल करता है।

उदाहरण के लिए: रसद प्रणाली, भुगतान प्रणाली, प्राधिकरण प्रणाली, आदेश प्रबंधन प्रणाली।

डोमेन को उप-डोमेन में विभाजित किया गया है, जो छोटी संरचनाओं का वर्णन करता है, उदाहरण के लिए: आदेशों की एक टोकरी, मार्गों के निर्माण के लिए एक प्रणाली।

प्रत्येक डोमेन के पास जिम्मेदारी का एक सीमित क्षेत्र है - सीमित कार्यक्षमता।

बद्ध संदर्भ - डोमेन प्रतिबंधों का एक सेट जो डोमेन को अपने सर्वोत्तम समाधान के लिए केवल एक कार्य पर ध्यान केंद्रित करने में मदद करता है।

मैं इस शब्द को ऐसे अमूर्त के रूप में प्रस्तुत करना पसंद करता हूं। एक डोमेन एक सर्कल है। एक प्रतिबंधित संदर्भ एक चक्र है।

डीडीडी शब्दावली में भी, कर्नेल आवंटित किया जाता है।

कोर (कोर डोमेन) - सबसे महत्वपूर्ण डोमेन जो आपके व्यवसाय की विशेषता बताता है।

तो, परियोजना के डोमेन "चार कछुए और एक चूहा":

पिज़्ज़ेरिया (पिज़ेरिया) के साथ काम करें

संदर्भ : b2b सब कुछ पिज़्ज़ेरिया से संबंधित है

उप डोमेन :

• नए पिज़्ज़ेरिया का पंजीकरण
• वर्गीकरण जोड़ना
• किसी उत्पाद की उपलब्धता की स्थिति को अद्यतन करना

ग्राहक के साथ काम करें (ग्राहक)

संदर्भ : b2c, पिज्जा ग्राहकों के साथ काम करने से जुड़ी हर चीज

उप डोमेन :

• वर्गीकरण देखें
• सूचना सामग्री

कोरियर (डिलीवरी सिस्टम) के साथ काम करें

संदर्भ : बी 2 ई, कोरियर के साथ काम करने से जुड़ी हर चीज

उप डोमेन :

• कूरियर पंजीकरण
• कार्यों का कार्य
• कूरियर द्वारा अर्जित धन की वापसी के लिए आवेदनों का पंजीकरण।

आदेश प्रणाली

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

उप डोमेन :

• आदेश स्वीकृति
• आदेश निष्पादन
• आदेश स्थिति ट्रैकिंग

निपटान प्रणाली (बिलिंग)

संदर्भ : सभी वित्तीय लेनदेन शामिल हैं। यह प्रसंस्करण केंद्र के साथ सहभागिता प्रदान करता है।

उप डोमेन :

• आदेशों के लिए पैसा स्वीकार करना
• काम करने के लिए कोरियर को पैसा देना

सांख्यिकी प्रणाली

संदर्भ : विश्लेषणात्मक जानकारी का संग्रह और प्रसंस्करण (जारी नहीं करना)।

उप डोमेन :

• धन पर आंकड़े
• आवेदन के आँकड़े

प्रबंधन प्रणाली (प्रबंधन पैनल)

संदर्भ : विश्लेषणात्मक जानकारी जारी करना। प्रबंधन निर्णयों का टूलकिट।

• एकत्रित आँकड़ों के आधार पर विश्लेषण
• कोरियर को भुगतान का पूर्व-मॉडरेशन

डोमेन के आधार पर, इसे मैप करते हैं।

एक डोमेन मैप (संदर्भ नक्शा) एक ग्राफिकल टूल है जो आपको व्यक्तिगत डोमेन के बीच संबंधों का वर्णन करने की अनुमति देता है।

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

मानचित्र पर सबसे महत्वपूर्ण बात यह है कि हम डोमेन के बीच संबंध देखते हैं। इस तरह की संरचना सूक्ष्मदर्शी वास्तुकला पर बहुत अच्छी तरह से फिट होती है:

माइक्रोसर्विस आर्किटेक्चर का मुख्य सिद्धांत: कमजोर कनेक्टिविटी और मजबूत आसंजन।

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

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

डोमेन शेयरिंग कार्यान्वयन अभ्यास

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

मुख्य सिद्धांत जो हमें निर्देशित करते हैं:

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

डोमेन कैसे लागू करें?

अलग-अलग माइक्रोसर्विसेज के रूप में डोमेन का चयन करना बहुत सुविधाजनक है।

माइक्रोसर्विसेज एक अलग अनुप्रयोग है जो एक डोमेन के तर्क को लागू करता है।

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

डोमेन के बीच के रिश्ते को कैसे उजागर करें?

डोमेन के बीच संबंध हमेशा एक एपीआई है। यह RESTful json api, gRPC, AMPQ हो सकता है। इस लेख के ढांचे के भीतर, हम एक प्रोटोकॉल की दूसरे के साथ तुलना नहीं करेंगे और उनके फायदे और नुकसान को उजागर करेंगे, उनमें से प्रत्येक के पास आवेदन का अपना क्षेत्र है। लेकिन फिर भी, आइए हम सामान्य सिफारिशों पर ध्यान दें:

इसके कार्यान्वयन की एकरूपता में एक प्रोटोकॉल और कठोर चुनने में लचीला हो।

व्यक्तिगत रूप से प्रत्येक जोड़ी डोमेन के लिए एक प्रोटोकॉल चुनें, हर जगह http का उपयोग करने की कोशिश न करें, आपको कहीं न कहीं अतुल्यकालिक कतार की आवश्यकता हो सकती है और AMPQ के फायदे आपके लिए स्पष्ट हो जाएंगे। इस अवसर को अनदेखा न करें क्योंकि आपके पास हर जगह RESTful है।

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

उपडोमेन कैसे लागू करें?

एक microservice के अंदर अलग मॉड्यूल के रूप में।

एक मॉड्यूल एक सबडोमेन का एक कार्यान्वयन है, एक एकल नाम के साथ एक अलग नामस्थान (नामस्पेस) में तर्क डालकर।

यह सब क्या दिखता है? आइए एक उदाहरण देखें। जैसा कि हम याद करते हैं, हमारे पास एक डिलीवरी सिस्टम डोमेन है - इस डोमेन में तीन उप डोमेन हैं:

• कूरियर पंजीकरण
• कार्य (कार्य) जारी करना
• कूरियर द्वारा निकाले गए धन की वापसी के लिए आवेदन का पंजीकरण (निकासी)
• जाँच कर रहा है कि आपका माइक्रोसेवा काम कर रहा है, सहायक, तकनीकी उपकरण (healt_checker)

यह सब एक फ़ोल्डर संरचना के रूप में कल्पना करें:

 $ tree --dirsfirst delivery_system delivery_system ├── app/ │ ├── health_checker/ │ │ └── endpoints.rb │ ├── registrations/ │ │ ├── entities/ │ │ ├── forms/ │ │ ├── repositories/ │ │ ├── interactor/ │ │ ├── services/ │ │ ├── validations/ │ │ ├── endpoints.rb │ │ └── helpers.rb │ ├── tasks │ │ ├── entities/ │ │ ├── queries/ │ │ ├── repositories/ │ │ ├── endpoints.rb │ │ └── helpers.rb │ └── withdrawals │ ├── entities/ │ ├── forms/ │ ├── repositories/ │ ├── interactor/ │ ├── services/ │ ├── validations/ │ ├── endpoints.rb │ └── helpers.rb ├── config/ ├── db/ ├── docs/ ├── lib/ │ ├── schemas/ │ └── values/ ├── public ├── specs ├── config.ru ├── Gemfile ├── Gemfile.lock ├── Rakefile └── README.md 

apps/ निर्देशिका में प्रत्येक फ़ोल्डर एक या किसी अन्य उपडोमेन को लागू करता है, प्रत्येक डोमेन के भीतर विभिन्न पैटर्न होते हैं: entities , forms , services , हम भविष्य के किसी एक लेख में विस्तार से लागू किए गए प्रत्येक पैटर्न पर विचार करेंगे।

इस तरह के प्रत्येक पैटर्न को इसी नामस्थान (नेमस्पेस) में लागू किया जाता है। उदाहरण के लिए, एक कूरियर के लिए भुगतान के लिए एक आवेदन पत्र बनाने के लिए एक फार्म:

 module Withdrawal #   module Forms #  class Create end end end 

उप-डोमेन के बीच संचार कैसे लागू करें?

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

हमारे पास निष्पादन की दो प्रक्रियाएँ हैं जिनमें से हम इस खाते का उपयोग करते हैं।

• एक खाता बनाएँ (पंजीकरण)
• एक कूरियर (Wihtdrawal) द्वारा अर्जित धन की वापसी के लिए एक आवेदन का निर्माण

जैसा कि हम देखते हैं कि ये दो प्रक्रियाएँ अलग-अलग उप-डोमेन से हैं - पंजीकरण और विह्रद्रवाल।

 module Registrations module Serivices class CreateAccount def call account = Entities::Account.new end end end end module Withdrwals module Serivices class CreateOrder def call account = Registrations::Entities::Account.new end end end end 

पहले मामले में, Entities::Account को एक कॉल के माध्यम से Entities::Account लागू किया जाएगा। और दूसरे मामले में, Registrations::Entities::Account लिए एक स्पष्ट कॉल के माध्यम से Registrations::Entities::Account । यानी यदि हम स्पष्ट रूप से एक उपडोमेन निर्दिष्ट करते हैं, तो वर्ग दूसरे उपडोमेन से है और इसलिए हम स्पष्ट रूप से कनेक्शन का संकेत देते हैं।

यदि वर्ग स्पष्ट रूप से किसी भी उप-डोमेन पर लागू नहीं होता है, तो यह समझ में आता है कि वह इसे lib/ फ़ोल्डर में ले जाए। एक नियम के रूप में, ये वे वर्ग हैं जो 'ValueObject' पैटर्न को लागू करते हैं। हम निम्नलिखित लेखों में से एक में इस पैटर्न की अधिक विस्तार से जाँच करेंगे।

मॉडल के माध्यम से कार्यान्वयन।

एरिक इवांस को उद्धृत करने के लिए:

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

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

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