सीक्यूआरएस में सेट आधारित स्थिरता सत्यापन को कैसे संभालें?

Question

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

1. Facility के पास एक अद्वितीय नाम होना चाहिए।

चूंकि मैं क्वेरी पक्ष पर अंततः एक सतत डेटाबेस का उपयोग कर रहा हूं, इसमें डेटा प्रोसेसर घटना को संसाधित करते समय सटीक होने की गारंटी नहीं देता है।

उदाहरण के लिए, FacilityCreatedEvent क्वेरी डेटाबेस इवेंट प्रोसेसिंग कतार में संसाधित होने और डेटाबेस में लिखे जाने की प्रतीक्षा में है। संसाधित होने के लिए डोमेन पर एक नया CreateFacilityCommand भेजा जाता है। डोमेन सेवाएं यह देखने के लिए पढ़ने वाले डेटाबेस से पूछती हैं कि क्या कोई अन्य Facility पहले से ही उस नाम से पंजीकृत है, लेकिन झूठी वापसी करता है क्योंकि CreateNewFacilityEvent अभी तक संसाधित नहीं हुआ है और स्टोर में लिखा गया है। नया CreateFacilityCommand अब सफल होगा और FacilityCreatedEvent फेंक देगा जो घटना प्रोसेसर डेटाबेस में लिखने की कोशिश करता है और यह पता चलता है कि उस नाम के साथ Facility पहले से मौजूद है।

Answer 1

जिस समाधान के साथ मैं गया था वह System कुल रूट जोड़ना था जो वर्तमान Facility नामों की सूची बनाए रख सकता था। एक नया Facility बनाते समय, मैं इसके लिए एक कारखाने के रूप में System कुल (केवल एक System वैश्विक वस्तु/सिंगलटन के रूप में) का उपयोग करता हूं। यदि दिया गया सुविधा नाम पहले से मौजूद है, तो यह एक सत्यापन त्रुटि फेंक देगा।

यह डोमेन के भीतर सत्यापन बाधाओं को रखता है और अंततः लगातार क्वेरी स्टोर पर भरोसा नहीं करता है।

Answer 2

इस मामले में, आप एक साधारण सीआरयूडी शैली सेवा लागू कर सकते हैं जो मूल रूप से प्राथमिक कुंजी बाधा वाले एसक्यूएल तालिका में एक सम्मिलित करता है।

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

जाहिर है, जब आदेश में एक मान होता है जो प्राथमिक कुंजी जांच के लिए तालिका में मौजूद नहीं होता है, तो ऑपरेशन एक सफलता है।

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

Answer 3

तीन दृष्टिकोण Eventual Consistency and Set Validation में दिए गए हैं:

1. यदि समस्या दुर्लभ या महत्वपूर्ण नहीं है,, प्रशासनिक रूप से इसके साथ सौदा संभवतः एक व्यवस्थापक को सूचना भेजकर।
2. एक डुप्लिकेटफैसिलिटीनाम डिटेक्टेड ईवेंट डिस्पैच करें, जो एक स्वचालित रिज़ॉल्यूशन प्रक्रिया को लात मार सकता है।
3. ऐसी सेवा बनाए रखें जो उपयोग की गई सुविधा नामों के बारे में जानता हो, शायद डोमेन ईवेंट सुनकर और नामों की लगातार सूची बनाए रखे। कोई नई सुविधा बनाने से पहले, पहले इस सेवा से जांचें।

इसके अलावा इस संबंधित सवाल देखें: Uniqueness validation when using CQRS and Event sourcing

Answer 4

विशिष्टता की जांच डेटा लेखन से पहले किया जाना होगा, बल्कि इसलिए बेहतर तरीका एक घटना-ट्रैकिंग सेवा का निर्माण करना है, जब प्रक्रिया समाप्त जो एक अधिसूचना भेजना होगा या समाप्त हो गया।