CQRS + इवेंट सोर्सिंग: (क्या यह सही है) कमांड को आम तौर पर पॉइंट-टू-पॉइंट बताया जाता है, जबकि डोमेन इवेंट्स को पब / सब के माध्यम से सूचित किया जाता है?


12

मैं मूल रूप से CQRS की अवधारणा और संबंधित अवधारणाओं के चारों ओर अपना सिर लपेटने की कोशिश कर रहा हूं ।

हालाँकि CQRS आवश्यक रूप से मैसेजिंग और ईवेंट सोर्सिंग को शामिल नहीं करता है, लेकिन यह एक अच्छा संयोजन प्रतीत होता है (जैसा कि इन अवधारणाओं को मिलाकर बहुत सारे उदाहरण / ब्लॉगपोस्ट के साथ देखा जा सकता है)

किसी चीज़ के लिए एक राज्य परिवर्तन के लिए उपयोग-मामले को देखते हुए (SO पर एक प्रश्न को अद्यतन करने के लिए कहें), क्या आप निम्न प्रवाह को सही मानेंगे (जैसा कि सर्वोत्तम व्यवहार में है)?

सिस्टम एक समग्र UpdateQuestionCommand जारी करता है जिसे छोटे आदेशों के एक जोड़े में अलग किया जा सकता है: UpdateQuestion जो कि उपयोगकर्ता के मूल रूट पर लक्षित प्रश्न सकल रूट पर लक्षित है, और UpdateUserAction (अंक गिनने के लिए आदि) पर लक्षित है। ये बिंदु-से-बिंदु संदेश का उपयोग करते हुए एसिंक्रोनस रूप से भेजे जाते हैं।

कुलमिलाकर जड़ें अपना काम करती हैं और यदि सभी आग लगने की घटनाओं पर क्रमशः प्रश्नोत्तर और UserActionUpdated हो जाते हैं, जिसमें एक घटना की दुकान के लिए आउटसोर्स किए जाने वाले राज्य होते हैं .. यदयादा को बनाए रखने के लिए, बस पूरा होने के लिए, वास्तव में यहां बिंदु नहीं है।

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

सामान्य प्रश्न: क्या यह वास्तव में सबसे अच्छा अभ्यास है, कि कमांड को पॉइंट-टू-पॉइंट (यानी: रिसीवर ज्ञात है) का संचार किया जाता है, जबकि घटनाओं को प्रसारित किया जाता है (यानी: रिसीवर अज्ञात हैं)?

उपरोक्त मानते हुए, कमांड-टू-पॉइंट की बजाय पब / उप माध्यम से प्रसारित करने की अनुमति देने का क्या फायदा / नुकसान होगा?

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

दूसरी ओर, मैं लाभ (लचीलापन) देखता हूं जब प्रसारण आदेशों की अनुमति होगी।


अच्छी तरह से लिखित प्रश्न btw।
दाव

जवाबों:


19

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

80% मामला

आपके प्रश्न का उत्तर देने के लिए, कमांड वास्तव में एक पॉइंट-टू-पॉइंट मामला है। जब कोई कमांड कंट्रोलर (MVC वेबऐप) में प्रवेश करता है, तो वह कंट्रोलर एक कमांड डिस्पैचर को एक और केवल एक उपयुक्त कमांड हैंडलर को खोजने के लिए कहता है, और उस हैंडलर को काम सौंपता है।

प्रकाशित क्यों नहीं हुआ?

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

दूसरी ओर, घटनाएँ प्रकृति में सूचनात्मक हैं, और किसी विशेष घटना में रुचि रखने के लिए शून्य, दो, या अधिक घटकों की अपेक्षा करना उचित है। अनुरोधित परिवर्तन करने के दायरे में हम वास्तव में परवाह नहीं करते हैं।

उदाहरण

इसकी तुलना वास्तविक जीवन से की जा सकती है। यदि आपके तीन बच्चे हैं, तो एक कमरे में चलें और बस चिल्लाएं "बाथरूम को साफ करें," आपको इस बात की कोई गारंटी नहीं है कि कोई व्यक्ति होगा, और पेरफ़ेफ़्स अगर यह दो बार नहीं किया जाएगा (यदि आपके पास आज्ञाकारी बच्चे हैं; तो; आपको चाहिए) बेहतर होगा यदि आप एक विशिष्ट बच्चे को वह करने के लिए कहें जो आप चाहते हैं।

जब वह बच्चा अपना काम खत्म कर लेता है, लेकिन यह सुविधाजनक होता है अगर वह चिल्लाता है "बाथरूम को साफ कर दिया गया है," ताकि हर कोई जो अपने दांतों को ब्रश करना चाहता है, वह जानता है कि वे अब ऐसा कर सकते हैं।


इसमें काफी सार्थकता है। उत्कृष्ट सादृश्य :)
गेर्ट-जान

आपने मुझे खो दिया .. When a command enters a controller (MVC webapp)? क्या आप RESTful का उपयोग कर रहे हैं? या कुछ हाइब्रिड एपीआई एंडपॉइंट्स? क्या आप एक उदाहरण जोड़ सकते हैं
पियोट कुला

@ppumkin हमने एक WebAPI एंडपॉइंट का इस्तेमाल किया है जिसे कमांड निष्पादित करने के लिए हर बार हमारे वेब ऐप द्वारा कॉल किया जाएगा। उदाहरण के लिए। यदि उपयोगकर्ता पोस्ट कमेंट जोड़ना चाहता है, तो वेब ऐप एक POST अनुरोध भेजेगा example.com/api/Post/AddPostComment
डेव

1

मैं इस बात से सहमत हूं कि एक आरंभिक प्रणाली आमतौर पर कभी भी एक कमांड को कई लक्ष्य प्रणालियों द्वारा लेन-देन की उम्मीद नहीं करेगी:

  • आदेश आम तौर पर कभी नहीं 'भेजने और प्रार्थना' कर रहे हैं - एक कमांड की शुरुआत करने प्रणाली आम तौर पर लेता है प्रगति और आदेश के परिणाम के रूप में अतुल्यकालिक प्रतिक्रिया चाहता है जगह (जैसे राज्य की घटनाओं की तरह है acknowledgement, और सफल completionया failureशुरुआत सूचित करने के लिए निशाना बनाया प्रणाली द्वारा प्रकाशित किया जा सकता है प्रणाली)।
  • यदि कई लक्ष्य सिस्टम शामिल थे, तो आरंभिक प्रणाली कमांड के लिए एकाधिक (संभवतः विरोधाभासी) परिणाम प्राप्त करेगी (जैसे लक्ष्य 1 सफल, लेकिन लक्ष्य 2 विफल)। इसके लिए मूल कमांड की वास्तविक स्थिति को निर्धारित करने में अतिरिक्त जटिलता की आवश्यकता होगी (जैसे कि कमांड लेनदेन को तभी सफल माना जाएगा जब लक्ष्य सफल हो जाएं। क्या किसी लक्ष्य के विफल होने पर कमांड को वापस रोल में लाने या सफल लक्ष्यों में मुआवजा देने की आवश्यकता होगी? आदि।)। यह पहल और लक्ष्य प्रणालियों के बीच अवांछनीय युग्मन और जटिलता का परिचय देगा।

हालांकि, अभी भी अतिरिक्त (गैर-लेन-देन की सदस्यता लेने में सक्षम होने के लिए योग्यता है, और आमतौर पर काफी 'प्रांतीय') उपभोक्ता जो सिस्टम के बीच जारी किए गए आदेशों पर 'छिपकर' कहते हैं

  • ऑडिटिंग के उद्देश्य
  • इंस्ट्रूमेंटेशन और ऑपरेशनल मेट्रिक्स (जैसे लोड, बिजनेस एनालिटिक्स आदि)
  • कॉम्प्लेक्स इवेंट प्रोसेसिंग या स्ट्रीम इवेंट प्रोसेसिंग 'ईव्सड्रॉपर' - ये सिस्टम कमांड में त्रुटियों या अनियमितताओं का पता लगा सकते हैं (जैसे कमांड की आवृत्ति, या कमांड और घटनाओं के विभिन्न संयोजनों के बीच सहसंबंध), और अलर्ट ट्रिगर कर सकते हैं, या सुधारात्मक कार्रवाई (अक्सर में) आगे का रूप, विभिन्न प्रकार के कमांड)।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.