डोमेन घटनाक्रम और सेवा के साथ सीक्यूआरएस और डीडीडी का उपयोग करते समय दृश्य में परिवर्तन दिखा रहा है

Question

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

मैं उम्मीद करता हूं कि हमारे सिस्टम में से किसी एक को सीक्यूआरएस के साथ घटनाओं और एक सेवा बस का उपयोग करके इनलाइन के डिजाइन को स्थानांतरित करने की उम्मीद है।

मान लीजिए कि मेरी प्रवाह जैसे चला जाता है:

1. उपयोगकर्ता दृश्य में बटन क्लिक करता है उनके खाते से भुगतान की विधि को दूर करने के कार्य करने के लिए।

2. नियंत्रक भुगतान MethodRemovalService को कॉल करता है, इसे खाता पास करता है आईडी & paymentMethodId।

3. नियंत्रक AccountRepository का उपयोग करता खाते को पुनः प्राप्त करने और account.RemovePaymentMethod (आईडी)

4. खाता मान्य करता है कि आपरेशन हो सकता है कॉल और प्रकाशित करता घटना PaymentMethodRemovedMessage (ACCOUNTID, paymentMethodId)

5. क्योंकि घटना प्रकाशन अतुल्यकालिक है, अब हमें सेवा से वापस जाना है और नियंत्रक से रिटर्न व्यू करना है - लेकिन हमारा वास्तविक डेटा अभी तक अपडेट नहीं किया गया है!

6. एक हैंडलर, IHandle < PaymentMethodRemovedMessage>, घटना सुनता है और डीबी

तो वास्तविक पंक्ति निकाल देता है, एक आदमी क्या करना है?

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

क्या मैं सिर्फ एक अधिसूचना दिखाता हूं कि भुगतान विधि को हटाने का उनका अनुरोध सबमिट कर दिया गया है? (जो दोस्ताना प्रतीत नहीं होता है, ऑर्डर सबमिट करने के लिए समझ में आता है, लेकिन कहने के लिए, एक पता बदलना नहीं)।

क्या डीकॉप्लेड एसिंक्रोनस घटनाओं के रूप में परिवर्तनों को लागू करने और उनके वर्तमान परिवर्तन को दर्शाते हुए उपयोगकर्ता डेटा दिखाने के लिए एक तरीका है?

संपादित करें: - यूआई तकरार एक अद्यतन के साथ बैंड से बाहर है कि दिखाने के लिए मेरा प्रश्न काफी CQRS, DDD synching reporting database मुझे कहना है के समान है, इस सवाल का जवाब यहाँ करने के लिए वहाँ और भी दिए गए संकेत है, यह करने के लिए एक गंध का एक सा है बोलने के लिए डीबी पढ़ें। मैं थोड़ा साफ करने की उम्मीद कर रहा था।

Answer 1

यदि आप अनुरोध/प्रतिक्रिया मॉडल में बंद हैं तो आप एक सहसंबंधित अनुरोध/प्रतिक्रिया पैटर्न को अपना सकते हैं। विनिर्देशों के लिए, एनएसबी डाउनलोड में Async पेज नमूना देखें। यह एएसपी.NET सेटिंग में अनुरोध/प्रतिक्रिया प्रदर्शित करता है। अगर कुछ और चीज है तो वहां कुछ एएसपी.नेट एमवीसी उदाहरण हैं।

जब आप एसिंक्रोनस प्रोसेसिंग शुरू करते हैं तो आप स्वीकार कर रहे हैं कि डेटा पुराना होगा।कोई तर्क दे सकता है कि जिस क्षण आप डीबी से पूछते हैं वह डेटा पहले से ही पुराना है (नेटवर्क विलंबता, समय प्रस्तुत करने आदि)। चूंकि डेटा पहले से ही पुराना है, इसलिए हमें यह पूछना चाहिए कि कितना पुराना अच्छा है?

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

Answer 2

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

कुछ समय पहले मैंने इस विषय पर एक ब्लॉग पोस्ट लिखा था जिसे आप सहायक पा सकते हैं। आप इसे यहाँ पा सकते हैं:

विकल्प 1 - एक पुष्टिकरण स्क्रीन का उपयोग करें: 4 Ways to Handle Eventual Consistency on the UI

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

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

आप सहसंबंध आईडी का भी उपयोग कर सकते हैं ताकि आप सफलता या संचालन की विफलता की सदस्यता ले सकें।

वैसे भी, उम्मीद है कि विचार के लिए कुछ भोजन प्रदान करता है।