सीक्यूआरएस - कब पुष्टि संदेश भेजना है?

Question

उदाहरण: व्यवसाय नियम बताते हैं कि ऑर्डर देने पर ग्राहक को एक पुष्टिकरण संदेश (ईमेल या समान) प्राप्त करना चाहिए।

का कहना है कि एक NewOrderRegisteredEvent डोमेन से भेजा जाता है और एक घटना श्रोता पुष्टि संदेश के द्वारा भेजे जाने वाले द्वारा उठाया जाता है देता है। जब ऐसा किया जाता है तो कुछ अन्य घटना हैंडलर अपवाद फेंकता है या कुछ और गलत हो जाता है और काम की इकाई वापस लुढ़क जाती है। हमने अब उपयोगकर्ता को वापस लुढ़का हुआ कुछ चीज़ के लिए एक पुष्टिकरण संदेश भेजा है।

इस तरह की समस्याओं को हल करने के "cqrs" तरीका क्या है जहां आप काम की इकाई के बाद कुछ करना चाहते हैं? एक और जटिल कारक घटनाओं को फिर से खेल रहा है। जब भी मैं एक नया दृश्य/प्रक्षेपण बनाने के लिए रिकॉर्ड की गई घटनाओं को फिर से चलाता हूं, तो मैं पुराने पुष्टिकरण संदेशों को दोबारा नहीं भेजना चाहता हूं।

मेरा सबसे अच्छा सिद्धांत अब तक: मैंने अभी तक सीकर्स की आकर्षक दुनिया को देखना शुरू कर दिया है और यह सोच रहा था कि यह ऐसा कुछ है जिसे गाथा के रूप में लागू किया जाएगा? यदि एक गाथा एक राज्य मशीन की तरह है जहां प्रत्येक संक्रमण केवल एक ही समय में हो सकता है तो मुझे लगता है कि इस समस्या को हल करेगा? मैं सिर्फ visualizing कैसे इस आदेश बस और डोमेन की घटनाओं के साथ एक साथ फिट होगा एक कठिन समय है ..

Answer 1

1. एक ईवेंट लेनदेन पूरा होने के बाद ही होना चाहिए। अगर कुछ गलत हो जाता है और रोलबैक होता है, तो घटना बाहरी दृष्टिकोण से नहीं होती है। इसलिए इसे बिल्कुल प्रकाशित नहीं किया जाना चाहिए। यद्यपि यदि आवश्यक हो तो OrderRegistrationFailed ईवेंट प्रकाशित किया जा सकता है।

2. आप मेल नहीं भेजना चाहते हैं जब तक आदेश को सफलतापूर्वक निष्पादित नहीं किया जाता है।

   कमांड हैंडलर - जैसा कि किसी अन्य उत्तर में प्रस्तावित किया गया है, पहले कुछ कारणों से गलत जगह होगी: कुछ परिस्थितियों में कमांड हैंडलर यह बताने में सक्षम नहीं होगा कि आदेश अंततः सफल होगा या नहीं। कमांड हैंडलर मेल भेजने का आह्वान करने से कमांड हैंडलर के अंदर प्रक्रिया ज्ञान भी लगाएगा, जो एसआरएम को तोड़ देगा और आवेदन परत के साथ बहुत कड़े दो व्यवसाय नियमों को तोड़ देगा।

   इस तथ्य के बाद मेल भेजा जाना चाहिए, यानी एक ईवेंट हैंडलर से।

   इस हैंडलर को रीप्ले के दौरान फायरिंग से रोकने के लिए, आप इसे पंजीकृत नहीं कर सकते हैं। यह आपके आवेदन की जांच के समान काम करता है। आप केवल उन हैंडलर को पंजीकृत करते हैं जिन्हें आपको वास्तव में चाहिए।

   • उत्पादन प्रणाली -> सभी ईवेंट हैंडलर्स रजिस्टर
   • टेस्ट -> रजिस्टर केवल परीक्षण किया ईवेंट हैंडलर्स
   • खेलना -> रजिस्टर केवल प्रक्षेपण/असमान्यीकरण संचालकों

एक और - यहां तक ​​कि थोड़ा अधिक जटिल, हालांकि थोड़ा अधिक जटिल - संभावना SagaNewOrderRegisteredEvent को संभालने और अनुमोदन के लिए SendMail आदेश जारी करें ओप्रीट बाध्य संदर्भ (धन्यवाद, Yves Reynhout, प्रश्न की टिप्पणियों में इसे इंगित करने के लिए)।

Answer 2

दो संभावना समाधान

1) घटना के प्रकाशन और घटना से निपटने रहे हैं (यानी ईमेल) एक ही लेनदेन का हिस्सा हैं। इस मामले में, आपका लेनदेन ढांचा आपके लिए इसका ख्याल रखता है। अगर ईमेल विफल रहता है, तो घटना वापस लुढ़का है। आप शायद आदेश का पुनः प्रयास करेंगे। यह अवधारणात्मक रूप से साफ और सोचने में आसान है। कोई भी घटना प्रकाशित नहीं हो जाती है जब तक कि इसके बारे में कुछ कहने के लिए कुछ न कहें। हालांकि व्यावहारिक रूप से बोलना, यह दर्दनाक हो सकता है, क्योंकि इसमें आमतौर पर वितरित लेनदेन शामिल होते हैं। ये आना मुश्किल है। क्या आपका ईमेल क्लाइंट उसी लेनदेन में नामांकन कर सकता है जो आपके ईवेंट आयोजित कर रहा है?

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

समाधान (2) आमतौर पर डीडीडी/सीक्यूआरएस सर्किल में प्रचारित किया जाता है क्योंकि यह अधिक कमजोर युग्मित समाधान है। समाधान (1) एक छोटी प्रणाली में काफी व्यावहारिक है जहां ईवेंट स्टोर और अनुमान एक डेटाबेस में हैं और अनुमान अक्सर बदलते नहीं हैं। समाधान (2) इवेंट हैंडलरों की विविधता को अपने तरीके से काम करने की अनुमति देता है। समाधान (1) कई गैर-ओवरलैपिंग चिंताओं को उलझन में डाल सकता है। इस मामले में आपके ऑर्डर व्यवसाय नियम तब तक पूरा नहीं होते जब तक कि ईमेलिंग में होने वाली कई विचित्र चीजों का ध्यान नहीं रखा जाता है। एक बात के लिए, यह आपको थोड़ा धीमा कर सकता है।

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