👴🏾 🔙 🤴🏿 इवेंट सोर्सिंग क्यों माइक्रोसिस्टिक्स इंटरैक्शन के लिए एंटीपैटर्न है 🥂 👨🏿‍💼 👩🏿‍🚀

फिर से हैलो। मार्च में, OTUS ने सॉफ्टवेयर आर्किटेक्ट कोर्स की अगली स्ट्रीम लॉन्च की । पाठ्यक्रम की शुरुआत की प्रत्याशा में, हमने आपके लिए उपयोगी सामग्री का अनुवाद तैयार किया है।

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

किसी एकल भाषा के आधार के रूप में डोमेन घटनाएँ

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

डोमेन ईवेंट संदर्भों के बीच संवाद करने के लिए उपयोग किया जाता है

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

घटना पर विचार करें । इनवॉइस संदर्भ, साथ ही डिलीवरी संदर्भ, इस घटना को ट्रैक करने में रुचि रखते हैं, क्योंकि यह घटना इन संदर्भों में कुछ आंतरिक प्रक्रियाओं को ट्रिगर करती है।

कमजोर कनेक्टिविटी का मिथक

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

समय-समय पर डिकंप्लिंग के अलावा, डोमेन ईवेंट आपको एक और फायदा देते हैं: ऑर्डर के संदर्भ को यह जानने की जरूरत नहीं है कि इनवॉइस और डिलीवरी का संदर्भ इसकी घटनाओं को सुनता है। वास्तव में, उसे यह जानने की भी आवश्यकता नहीं है कि ये संदर्भ मौजूद हैं।

यह बहुत अच्छा है, लेकिन कठिनाई यह तय करने में निहित है कि घटना में कौन सा डेटा संग्रहीत करना है?

सरल उत्तर: इवेंट सोर्सिंग!

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

इवेंट सोर्सिंग सिर्फ एक स्टोरेज टियर है

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

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

यदि आप विश्व स्तर पर इवेंट सोर्सिंग का उपयोग करते हैं, तो आप अपने भंडारण स्तर का खुलासा करते हैं।

डेटा संग्रहण विधि आपकी सार्वजनिक एपीआई बन जाती है। हर बार जब आप स्टोरेज टियर में बदलाव करते हैं, तो आपको सार्वजनिक एपीआई में बदलाव से निपटना होगा।

मुझे यकीन है कि हर कोई इस बात से सहमत होगा कि यह तब बुरा है जब विभिन्न सीमित संदर्भ परिणामी कनेक्टिविटी के कारण (रिलेशनल) डेटाबेस में डेटा साझा करते हैं । लेकिन यह इवेंट सोर्सिंग से कैसे अलग है? कुछ भी तो नहीं। यदि आप डेटाबेस में साझा घटनाओं या साझा तालिकाओं का उपयोग करते हैं तो इससे कोई फर्क नहीं पड़ता। दोनों मामलों में, आप भंडारण विवरण साझा करते हैं।

एक निकास है

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

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

पसंद का अधिकार

सार्वजनिक API में अलग डोमेन ईवेंट होने से आप उन्हें लचीले ढंग से मॉडल कर सकते हैं। आप उस मॉडल तक सीमित नहीं हैं जो इवेंट सोर्सिंग द्वारा पूर्वनिर्धारित है।

"वास्तविक दुनिया की घटनाओं" के साथ काम करने के लिए दो विकल्प हैं: एक ओपन प्रोटोकॉल सेवा और एक सार्वजनिक भाषा (ओपन होस्ट सेवा, प्रकाशित भाषा) या एक ग्राहक / आपूर्तिकर्ता।

एक खुला प्रोटोकॉल और एक सार्वजनिक भाषा के साथ सेवा (ओपन होस्ट सेवा, प्रकाशित भाषा)

केवल एक डोमेन घटना प्रकाशित होती है जिसमें सभी डेटा होते हैं जो अन्य सीमित संदर्भों की आवश्यकता हो सकती है। DDD शब्दावली में, इसे ओपन होस्ट सर्विस और प्रकाशित भाषा कहा जा सकता है।

वास्तविक दुनिया की घटना "ऑर्डर एक्सेप्टेड" की शुरुआत एक ऑर्डरअपेक्टेड डोमेन इवेंट के प्रकाशन की ओर ले जाती है । इस घटना के पेलोड में सभी ऑर्डर डेटा शामिल हैं जो अन्य प्रतिबंधित संदर्भों की आवश्यकता हो सकती है ... इसलिए उम्मीद है कि इनवॉयस और डिलीवरी संदर्भों को वे सभी जानकारी मिलेंगी जिनकी उन्हें आवश्यकता है।

ग्राहक आपूर्तिकर्ता

प्रत्येक उपभोक्ता के लिए, अलग-अलग घटनाओं को प्रकाशित किया जाता है। प्रत्येक ईवेंट के मॉडलों को केवल एक उपभोक्ता के साथ समन्वित करना आवश्यक है, एक सामान्य साझा मॉडल को निर्धारित करना आवश्यक नहीं है। DDD इस संबंध को ग्राहक / आपूर्तिकर्ता कहता है।

वास्तविक दुनिया की घटनाओं "आदेश स्वीकार" की घटना उपभोक्ताओं में से प्रत्येक के लिए व्यक्तिगत घटनाओं के प्रकाशन की ओर ले जाती है: InvoiceOrderAcceptedऔर DeliveryOrderAccepted। प्रत्येक डोमेन ईवेंट में केवल वही डेटा होता है जो प्राप्तकर्ता संदर्भ के लिए आवश्यक होता है।

मैं अब इन दृष्टिकोणों के पेशेवरों और विपक्षों के बारे में चर्चा नहीं करना चाहता। मैं सिर्फ इस तथ्य पर ध्यान आकर्षित करना चाहता हूं कि आप डोमेन घटनाओं की संख्या और उनके द्वारा संग्रहीत डेटा का चयन कर सकते हैं।

यह एक ऐसा लाभ है जिसे आपको कम नहीं समझना चाहिए, क्योंकि आप यह तय कर सकते हैं कि इवेंट सोर्सिंग इवेंट्स के लिए बाध्य किए बिना अपने सीमित संदर्भ के एपीआई को कैसे विकसित किया जाए।

निष्कर्ष

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

अनुवाद: "वेयरवोल्फ की तरह एक अच्छा डेवलपर चांदी की गोलियों से डरता है।"

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

संदर्भ

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

यदि आप अधिक जानकारी चाहते हैं, तो आप इन संसाधनों का उल्लेख कर सकते हैं:

अनुच्छेद ईसाई Stettler डोमेन घटनाओं बनाम इवेंट सोर्सिंग
ह्यूगो रोचा लेख वे घटना सोर्सिंग के बारे में आपको क्या नहीं बताते हैं
Greg Young A Decade of DDD, CQRS, Event Sourcing (CQRS/ES is NOT a top level architecture)

: « : ».

इवेंट सोर्सिंग क्यों माइक्रोसिस्टिक्स इंटरैक्शन के लिए एंटीपैटर्न है