परिचय

पिछले लेखों में, हमने दृष्टिकोण के दायरे की पहचान की और डोमेन ड्रिवेन डिज़ाइन के बुनियादी पद्धति सिद्धांतों की जांच की।

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

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

लचीली वास्तुकला

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

अपनी पुस्तक में, एरिक इवांस अनुशंसित डिज़ाइन पैटर्न की एक श्रृंखला प्रदान करता है और इस दृष्टिकोण को लचीला बनाता है:

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

एरिक इवांस, डोमेन-प्रेरित डिज़ाइन: सॉफ्टवेयर के दिल में जटिलता का सामना करना

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

आकर्षक वास्तुकला

इसी तरह के विचार कई डेवलपर्स और जटिल प्रणालियों के डिजाइनरों के मन में उत्पन्न हुए।

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

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

रॉबर्ट सी। मार्टिन, 30 सितंबर, 2011

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

साफ वास्तुकला

एक साल बाद, रॉबर्ट मार्टिन का अगला लेख - द क्लीन आर्किटेक्चर । इसमें, लेखक बताता है कि कोड को कैसे चीखना है। कई आर्किटेक्चर का अध्ययन करने के बाद, वह मूल सिद्धांतों की पहचान करता है:

1. स्‍वतंत्रता। वास्तुकला किसी भी मौजूदा पुस्तकालय पर निर्भर नहीं है। यह आपको अपने हाथों को बांधने वाली बाधाओं के बजाय उपकरण के रूप में फ्रेमवर्क का उपयोग करने की अनुमति देता है।
2. Testability। उपयोगकर्ता इंटरफ़ेस, डेटाबेस, वेब सर्वर या किसी अन्य तकनीकी साधनों के बिना व्यावसायिक नियमों का परीक्षण किया जा सकता है।
3. यूआई स्वतंत्रता। बाकी सिस्टम को बदले बिना यूजर इंटरफेस को आसानी से बदला जा सकता है। उदाहरण के लिए, वेब इंटरफ़ेस को व्यावसायिक तर्क को बदले बिना कंसोल इंटरफ़ेस से बदला जा सकता है।
4. डेटाबेस की स्वतंत्रता। आप मैंगो, बिगटेबल, काउचबीडी या कुछ और के लिए ओरेकल या एसक्यूएल सर्वर का आदान-प्रदान कर सकते हैं। आपका एप्लिकेशन लॉजिक डेटाबेस बाउंड नहीं होना चाहिए।
5. पर्यावरणीय प्रभावों से स्वतंत्रता। वास्तव में, आपके व्यावसायिक नियम बस बाहरी दुनिया के बारे में कुछ नहीं जानते हैं।

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

चर वास्तुकला

उपरोक्त दृष्टिकोण का वर्णन इतना सीधा नहीं लगता है। कई जटिल कॉर्पोरेट प्रणालियों के वास्तुकला के विकास के हिस्से के रूप में, मैंने और मेरे सहयोगियों ने वर्णित दृष्टिकोणों की काफी स्पष्ट व्याख्या विकसित की है, जिसे मैं नीचे प्रस्तुत करने का इरादा रखता हूं।

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

1. दस्तावेज़ निर्माण
2. दस्तावेज़ प्रसंस्करण
3. दस्तावेजों के संग्रह के साथ काम करें
4. दस्तावेज़ प्रस्तुत करना

दस्तावेज़ - किसी विशेष वास्तविक व्यापारिक वस्तु की आर्थिक गतिविधियों के बारे में जानकारी दर्ज करना।

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

1. एकत्रित
2. प्रसंस्करण
3. भंडारण
4. प्रतिनिधित्व

क्रिया - एक व्यवसाय मॉडल की गतिविधि की एक संरचनात्मक इकाई; एक सचेत लक्ष्य का एक अपेक्षाकृत पूरा किया गया अलग कार्य, एक व्यापारिक वस्तु की व्यक्तिगत गतिविधि की मनमानी और जानबूझकर अंत उपयोगकर्ता द्वारा प्रतिष्ठित।

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

मोड (आचरण) - एक निश्चित क्रम में क्रियाओं का एक सेट, जिसका पूरा अर्थ है, अंतिम उपयोगकर्ता के लिए फायदेमंद।

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

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

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

प्रतिनिधित्व (प्रतिनिधित्व)

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

आइए सरलतम "हेल्थ चेकर" लिखें

module Health class Endpoints < Sinatra::Base get '/check' do; end end end 

इसके सबसे आदिम रूप में, हमारी योजना इस तरह दिखाई देगी:

भंडारण प्रणाली के साथ काम करें

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

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

  module Reception class Endpoints < Sinatra::Base # Show item get '/residents/:id', provides: :json do resident = Repository::Residents.find params[:id] status 200 serialize(resident) end end end 

एक ग्राफिक आरेख के रूप में भंडारण प्रणाली के साथ काम करें :

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

प्रसंस्करण (प्रोसेसिंग)

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

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

  module Reception class Endpoints < Sinatra::Base # Register resident arrival post '/residents/:uid/arrival', provides: :json do result = Interactors::Arrival.call(resident_id: params[:id]) check!(result) do status 201 serialize result.data end end # Register resident departure post '/residents/:uid/departure', provides: :json do result = Interactors::Departure.call(resident_id: params[:id]) check!(result) do status 201 serialize result.data end end end end 

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

लेकिन बाहर से डेटा होने पर हमें क्या करना चाहिए? यहां डेटा कलेक्शन की कार्रवाई जुड़ी हुई है।

डेटा एकत्र करना

होटल में एक अतिथि के प्रारंभिक पंजीकरण के दौरान, वह पंजीकरण फॉर्म भरता है। इस फॉर्म का सत्यापन किया जा रहा है। यदि डेटा सही है, तो पंजीकरण व्यवसाय प्रक्रिया होती है। प्रक्रिया डेटा लौटाती है - निर्मित "किरायेदार" व्यवसाय मॉडल। हम इस मॉडल को अतिथि के लिए पठनीय रूप में प्रस्तुत करते हैं:

 module Reception class Endpoints < Sinatra::Base # Register new resident post '/residents', provides: [:json] do form = Forms::Registration.new(params) complete! form do check! form.result do status 201 serialize form.result.data end end end end end 

योजनाबद्ध रूप से, यह इस तरह दिखता है:

खेल के नियम (नियम)

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

सामान्य योजना

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

उच्च संकल्प नक्शा