आप एक बहुत ही दिलचस्प उदाहरण :)
मैं वास्तव में उपयोग लेने में कामयाब रहे Account 1 -> * Transaction जब किसी को भी यह से परिचित नहीं करने के लिए घटना सोर्सिंग (ईएस) समझा।
एक डेवलपर के रूप में मुझे सिखाया गया था (जिस तरह से) अब हम इकाई इंटरैक्शन के रूप में संदर्भित कर सकते हैं। तो हमारे पास Customer रिकॉर्ड है और इसमें वर्तमान स्थिति है। हम किसी भी तरह से रिकॉर्ड की स्थिति बदलते हैं (पता, कर विवरण, छूट, इत्यादि) और परिणाम संग्रहित करते हैं। हम कभी नहीं जानते कि क्या हुआ लेकिन हमारे पास नवीनतम राज्य है और, क्योंकि यह हमारे व्यापार की वर्तमान स्थिति है, यह ठीक है। निस्संदेह हमें निपटने के लिए आवश्यक पहले मुद्दों में से एक समेकन था, लेकिन हमारे पास इसे संभालने के तरीके थे और भले ही यह शानदार नहीं था "काम किया"।
किसी कारण से लेखांकन अनुशासन में काफी खरीद नहीं हुआ।हमारे पास Account की नवीनतम स्थिति क्यों नहीं है। हम संबंधित रिकॉर्ड लोड करेंगे, संतुलन को बदल देंगे, और राज्य को बचाएंगे। विचित्र रूप से पर्याप्त लोग शायद इस विचार पर चिल्लाएंगे, फिर भी यह हमारे शेष डेटा के लिए ठीक लगता है।
Transaction प्रविष्टियों की श्रृंखला के रूप में परिवर्तन घटनाओं को पंजीकृत करके लेखांकन डोमेन को इसके आसपास मिल गया। तो क्या आपको अपना खाता रिकॉर्ड और नवीनतम शेष राशि खोनी चाहिए जो आप हमेशा चल सकते हैं हालांकि नवीनतम लेनदेन प्राप्त करने के लिए सभी लेनदेन। वह घटना सोर्सिंग है।
ईएस में आमतौर पर एक समग्र रूट (एआर) के लिए अपनी नवीनतम स्थिति प्राप्त करने के लिए घटनाओं की पूरी सूची लोड करता है। आम तौर पर, सभी लोड होने पर घटनाओं की एक बड़ी संख्या से निपटने के लिए एक तंत्र भी प्रदर्शन समस्याओं का कारण बनता है: स्नैपशॉट्स। आमतौर पर केवल नवीनतम स्नैपशॉट संग्रहीत किया जाता है। स्नैपशॉट में स्नैपशॉट संस्करण लागू होने के बाद कुल और केवल ईवेंट की पूरी नवीनतम स्थिति होती है।
ईएस के बड़े फायदों में से एक यह है कि कोई भी नए प्रश्नों के साथ आ सकता है और फिर सभी घटनाओं को क्वेरी हैंडलर पर लागू कर सकता है और परिणाम निर्धारित कर सकता है। शायद कुछ ऐसा है: "मेरे पास कितने ग्राहक हैं जो पिछले साल दो बार चले गए हैं"। काफी मनमानी लेकिन "पारंपरिक" दृष्टिकोण का उपयोग करके जवाब काफी संभावना है कि हम आज से उस जानकारी को इकट्ठा करना शुरू कर देंगे और अगले वर्ष यह उपलब्ध होगा क्योंकि हम CustomerMoved घटनाओं को सहेज नहीं रहे हैं। ईएस के साथ हम CustomerMoved घटनाओं की खोज कर सकते हैं और किसी भी समय परिणाम प्राप्त कर सकते हैं।
तो यह मुझे आपके उदाहरण पर वापस लाता है। आप शायद सभी लेनदेन लोड नहीं करना चाहते हैं। इसके बजाय "टर्नओवर" स्टोर करें और इसे चलते समय गणना करें। "टर्नओवर" एक नई आवश्यकता होनी चाहिए, तो सभी एआरएस को एक बार बंद करने से इसे गति तक ले जाना चाहिए। आपके पास अभी भी calculateTurnover() विधि हो सकती है लेकिन यह ऐसा कुछ होगा जो आप अक्सर नहीं चलाएंगे। और उन मामलों में आपको एआर के लिए सभी लेनदेन लोड करने की आवश्यकता होगी।
स्रोत
2015-04-20 04:59:41
सबसे पहले - इतनी जल्दी प्रतिक्रिया देने के लिए धन्यवाद। मैंने हाल ही में वेरनॉन की पुस्तक का आदेश दिया है, इसलिए मैं इसे जल्द ही पढ़ूंगा और इस धागे पर वापस आऊंगा। –
खुशी। बशर्ते कि आप डीडीडी मूल बातें और शब्दावली जानते हैं, तो आप मेरे उत्तर में जुड़े 3-भाग पीडीएफ श्रृंखला को पढ़कर शुरू कर सकते हैं। – davenewza