परिचय

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

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

इसलिए ऐतिहासिक रूप से

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

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

एरिक इवांस 2006

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

कई माइक्रोसर्विसेज लिखने के दौरान, हमने ग्राउंडवर्क प्राप्त किया है - अमूर्त कक्षाओं का एक सेट। प्रत्येक ऐसे वर्ग को आधे घंटे में लिखा जा सकता है, इसका कोड समझना आसान है यदि आप जानते हैं कि यह कोड क्या है।

यहां मुख्य कठिनाइयां उत्पन्न हुईं। नए कर्मचारी जो डीडीडी प्रथाओं और स्वच्छ वास्तुकला के साथ सौदा नहीं करते थे, वे कोड और इसके उद्देश्य को नहीं समझ सकते थे। यदि मैं खुद इवांस पढ़ने से पहले पहली बार इस कोड को देखता हूं, तो मैं इसे विरासत, ओवर-इंजीनियरिंग के रूप में ले जाऊंगा।

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

दर्शन

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

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

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

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

ढांचा

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

module LunaPark #  module Forms #  class Single # / end end end 

यदि आप एक ऐसा फॉर्म लागू करना चाहते हैं जो एक एकल तत्व बनाता है, तो आपको इस वर्ग से विरासत में मिला है:

 module Forms class Create < LunaPark::Forms::Single 

यदि कई तत्व हैं, तो हम एक और कार्यान्वयन का उपयोग करेंगे।

 module Forms class Create < LunaPark::Forms::Multiple 

फिलहाल, सभी घटनाओं को सही क्रम में नहीं रखा गया है और मणि अल्फा अवस्था में है। हम इसे लेखों के प्रकाशन के अनुसार, चरणों में उद्धृत करेंगे। यानी यदि आप ValueObject और Entity बारे में कोई लेख देखते हैं, तो ये दोनों टेम्पलेट पहले से ही लागू हैं। चक्र के अंत तक, वे सभी परियोजना पर उपयोग के लिए उपयुक्त होंगे। चूंकि फ्रेमवर्क स्वयं sinatra \ roda के लिंक के बिना बहुत कम उपयोग का है, इसलिए एक अलग रिपॉजिटरी बनाई जाएगी जो दिखाती है कि जल्दी से अपनी परियोजना शुरू करने के लिए "सब कुछ पेंच" कैसे करें।

रूपरेखा मुख्य रूप से प्रलेखन के लिए एक आवेदन है। इन लेखों को फ्रेमवर्क के लिए प्रलेखन के रूप में न देखें।

तो, चलो व्यापार के लिए नीचे उतरो।

मान वस्तु

- आपकी प्रेमिका कितनी लंबी है?
- 151
- आप स्वतंत्रता की प्रतिमा के साथ मिलने लगे?

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

• धन केवल एक संख्या नहीं है, यह एक संख्या (राशि) + मुद्रा है।
• एक तिथि में एक दिन, महीना और वर्ष शामिल होते हैं।
• वजन मापने के लिए, एक भी संख्या हमारे लिए पर्याप्त नहीं है, इसके लिए माप की एक इकाई की भी आवश्यकता होती है।
• पासपोर्ट संख्या में एक श्रृंखला होती है और, वास्तव में, संख्या की।

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

 phone.call Values::PhoneNumber.new(79001231212) 

 Values::PhoneNumber.new(79001231212).to_s 

कल्पना कीजिए कि हम थ्री एक्सिस ऑनलाइन कैसीनो साइट बना रहे हैं और कार्ड गेम बेच रहे हैं। हमें 'प्लेइंग कार्ड' वर्ग की आवश्यकता होगी।

 module Values class PlayingCard < Lunapark::Values::Compound attr_reader :suit, :rank end end 

तो, हमारी कक्षा में केवल दो ही विशेषताएँ हैं:

• सूट - कार्ड सूट
• रैंक - कार्ड की गरिमा

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

 module Values RSpec.describe PlayingCard do let(:card) { described_class.new suit: :clubs, rank: 10 } let(:other) { described_class.new suit: :clubs, rank: 10 } it 'should be eql' do expect(card).to eq other end end end 

ऐसा परीक्षण विफल हो जाएगा, क्योंकि पते पर उनकी तुलना की जाएगी। पारित करने के लिए परीक्षण के लिए, हमें मूल्य-मानों की तुलना मूल्य से करनी चाहिए, इसके लिए हम एक तुलना विधि जोड़ेंगे:

 def ==(other) suit == other.suit && rank == other.rank end 

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

 ten = Values::Rank.new('10') clubs = Values::Suits.new(:clubs) ten_clubs = Values::PlayingCards.new(rank: ten, clubs: clubs) 

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

 class PlayingCard < Lunapark::Values::Compound def self.wrap(obj) case obj.is_a? self.class #      PlayingCard obj #      case obj.is_a? Hash #    ,      new(obj) #    case obj.is_a String #    ,     new rank: obj[0..-2], suit:[-1] # ,  -  . else #       raise ArgumentError #  . end end def initialize(suit:, rank:) #     @suit = Suit.wrap(suit) #      @rank = Rank.wrap(rank) end end 

यह दृष्टिकोण एक बड़ा लाभ देता है:

 ten = Values::Rank.new('10') clubs = Values::Suits.new(:clubs) from_values = Values::PlayingCard.wrap rank: ten, suit: clubs from_hash = Values::PlayingCard.wrap rank: '10', suit: :clubs from_obj = Values::PlayingCard.wrap from_values from_str = Values::PlayingCard.wrap '10C' #        utf ,  ,  . 

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

सिफारिशें

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

फ्रेडरिक टेलर 1914

अंकगणित संचालन को एक नई वस्तु वापस करनी चाहिए

 # GOOD class Money < LunaPark::Values::Compound def +(other) other = self.class.wrap(other) raise ArgumentError unless same_currency? other self.class.new( amount: amount + other.amount, currency: currency ) end end 

एक वैल्यू ऑब्जेक्ट के गुण केवल प्राइमेटिव या अन्य वैल्यू ऑब्जेक्ट हो सकते हैं

 # GOOD class Weight < LunaPark::Values::Compound def intialize(value:, unit:) @value = value @unit = Unit.wrap(unit) end end # BAD class PlaingCard < LunaPark::Value def initialize(rank:, suit:, deck:) ... @deck = Entity::Deck.wrap(deck) #    end end 

कक्षा के तरीकों के अंदर सरल संचालन रखें

 # GOOD class Weight < LunaPark::Values::Compound def >(other) value > other.convert_to(unit).value end end 

यदि "रूपांतरण" ऑपरेशन बड़ा है, तो शायद इसे एक अलग वर्ग में स्थानांतरित करने के लिए समझ में आता है

 # UGLY class Weight < LunaPark::Values::Compound def convert_to(unit) unit = Unit.wrap(unit) case { self.unit.to_sym => unit.to_sym } when { :kg => :ft } Weight.new(value: 2.2046 * value, unit.to_sym) when # ... end end end # GOOD #./lib/values/weight/converter.rb class Weight class Converter < LunaPark::Services::Simple def initialize(weight, to:) ... end end end #./lib/values/weight.rb class Weight < LunaPark::Values::Compound def convert_to(unit) Converter.call! self, to: unit end end 

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

डोमेन लॉजिक के बारे में ऑब्जेक्ट वैल्यू कुछ भी नहीं जान सकती

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

 # DEADLY BAD class Rate < LunaPark::Values::Single def top?(10) Repository::Rates.top(first: 10).include? self end end 

सारांश (इकाई)

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

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

सार से हमारा मतलब केवल संरचना से होगा। अपने सरलतम रूप में, इकाई वर्ग इस तरह दिखेगा:

 module Entities class MeatBag < LunaPark::Entities::Simple attr_accessor :id, :name, :hegiht, :weight, :birthday end end 

एक परिवर्तनशील वस्तु जो एक व्यवसाय मॉडल की संरचना का वर्णन करती है, इसमें आदिम प्रकार और मूल्य शामिल हो सकते हैं।
LunaPark::Entites::Simple वर्ग अविश्वसनीय रूप से सरल है, आप इसका कोड देख सकते हैं, यह हमें केवल एक चीज देता है - आसान आरंभीकरण।

 module LunaPark module Entities class Simple def initialize(params) set_attributes params end private def set_attributes(hash) hash.each { |k, v| send(:"#{k}=", v) } end end end end 

आप लिख सकते हैं:

 john_doe = Entity::MeatBag.new( id: 42, name: 'John Doe', height: '180cm', weight: '80kg', birthday: '01-01-1970' ) 

जैसा कि आप शायद पहले ही अनुमान लगा चुके हैं, हम मूल्य वस्तुओं में वजन, ऊंचाई और जन्म की तारीख को लपेटना चाहते हैं।

 module Entities class MeatBag < LunaPark::Entites::Simple attr_accessor :id, :name attr_reader :heiht, :wight, :birthday def height=(height) @height = Values::Height.wrap(height) end def weight=(height) @height = Values::Weight.wrap(weight) end def birthday=(day) @birthday = Date.parse(day) end end end 

ऐसे निर्माणकर्ताओं पर समय बर्बाद न करने के लिए, हमने LunaPark::Entites::Nested का अधिक जटिल कार्यान्वयन तैयार किया है:

 module Entities class MeatBag < LunaPark::Entities::Nested attr :id attr :name attr :heiht, Values::Height, :wrap attr :weight, Values::Weight, :wrap attr :birthday, Values::Date, :parse end end 

जैसा कि नाम से पता चलता है, यह कार्यान्वयन आपको वृक्ष संरचनाएं बनाने की अनुमति देता है।

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

 class Refregerator < LunaPark::Entites::Nested attr :id, attr :brand attr :title namespace :fridge do namespace :door do attr :upper, Shelf, :wrap attr :lower, Shelf, :wrap end attr :upper, Shelf, :wrap attr :lower, Shelf, :wrap end namespace :main do namespace :door do attr :first, Shelf, :wrap attr :second, Shelf, :wrap attr :third, Shelf, :wrap end namespace :boxes do attr :left, Box, :wrap attr :right, Box, :wrap end attr :first, Shelf, :wrap attr :second, Shelf, :wrap attr :third, Shelf, :wrap attr :fourth, Shelf, :wrap end attr :last_open_at, comparable: false end 

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

LunaPark::Entites::Nested क्लास में 2 और महत्वपूर्ण गुण हैं:

तुलनीयता:

 module Entites class User < LunaPark::Entites::Nested attr :email attr :registred_at end end u1 = Entites::User.new(email: 'john.doe@mail.com', registred_at: Time.now) u2 = Entites::User.new(email: 'john.doe@mail.com', registred_at: Time.now) u1 == u2 # => false 

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

 module Entites class User < LunaPark::Entites::Nested attr :email attr :registred_at, comparable: false end end 

तब हमें दो तुलनीय वस्तुएं मिलती हैं।

इस कार्यान्वयन में टर्नओवर की संपत्ति भी है - हम वर्ग विधि का उपयोग कर सकते हैं

 Entites::User.wrap(email: 'john.doe@mail.com', registred_at: Time.now) 

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

एक इकाई एक व्यावसायिक वस्तु का एक मॉडल है, इसे सरल छोड़ दें। यदि आपके व्यवसाय द्वारा कुछ संपत्ति का उपयोग नहीं किया जाता है, तो इसका वर्णन न करें।

इकाई परिवर्तन

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