"व्हाट इफ," इवेंट सोर्सिंग

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

आधार

प्रमुख तंत्र जो हमें विभिन्न उपयोगी कार्यक्षमता बनाने की अनुमति देते हैं, वे इस प्रकार हैं:

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

"Pechenyushki"

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

घटना का इतिहास

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

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

प्रक्षेपण

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

public void Consume (ShipArrived message) { readModel.Dock.Ships.Add(message.Ship); } public void Consume (ShipDeparted message) { readModel.Dock.Ships.Remove(message.Ship); } 

बेशक, इंटरफ़ेस के लिए अनुमानों के अलावा, घटना विकृतीकरण विभिन्न रिपोर्टों के निर्माण और घटना खट्टा संस्थाओं का विश्लेषण करने के लिए एक शक्तिशाली उपकरण है।

प्रक्रिया उन्मुख यूआई

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

सामान्य तौर पर, यह अनुप्रयोग के साथ उपयोगकर्ता के काम को बेहतर बनाने की प्रवृत्ति के साथ मेल खाता है और कार्रवाई करते समय संकेतों के साथ बहु-पृष्ठ निर्देशों को प्रतिस्थापित करता है, अर्थात्। आवेदन से ही सीखना।

तकनीकी बिंदु

इस दृष्टिकोण के साथ तकनीकी रूप से दिलचस्प उपयोगिताओं की एक जोड़ी:

• जब बाहरी प्रणालियों के साथ एकीकृत किया जाता है, तो घटनाओं की एक फ़िल्टर्ड धारा प्रसारित की जा सकती है। यह कुछ मामलों में कार्य को सरल बना सकता है।
• इवेंट स्टोर को बहुत तेज और विस्तार योग्य बनाया जा सकता है, क्योंकि ईवेंट अपरिवर्तित हैं और केवल जोड़े जा सकते हैं।
• अनुमान भू-प्रतिकृति हो सकते हैं।

समस्याओं

जैसा कि आप अनुमान लगा सकते हैं, वे महत्वपूर्ण हैं।

नरक के लिए refactoring

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

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

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

कोई तैयार उपकरण नहीं

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

घटनाओं की पारस्परिक रूप से भरपाई

कहते हैं, यदि कोई उपयोगकर्ता समाचार से सदस्यता समाप्त कर लेता है, और फिर सदस्यता लेता है ... और ऐसा 50 बार (पूरे वर्ष में) होता है। नतीजतन, केवल वर्तमान स्थिति है कि यह हस्ताक्षरित या सदस्यता समाप्त है और सब कुछ ठीक है। हालांकि, यदि आपको एक नई रिपोर्ट या प्रक्षेपण बनाने की आवश्यकता है जहां इस डेटा का उपयोग किया जाता है, तो ऐसी घटनाओं के प्रसंस्करण में बेकार समय लगेगा, लेकिन यह मशीन को अच्छी तरह से लोड करेगा।

समर्थन

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

निष्कर्ष

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

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