CQRS + इवेंट सोर्सिंग का परिचय: भाग 1. मूल बातें

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

आम तौर पर, कई CQRS के बारे में एक डिज़ाइन पैटर्न के रूप में बात करते हैं। मेरी राय में, यह एप्लिकेशन के समग्र आर्किटेक्चर को बहुत अधिक प्रभावित करता है, जिसे केवल "डिज़ाइन पैटर्न" कहा जाता है, इसलिए मैं इसे एक सिद्धांत या दृष्टिकोण कहना पसंद करता हूं। CQRS का उपयोग करना एप्लिकेशन के लगभग हर कोने में प्रवेश करता है।

मैं तुरंत स्पष्ट करना चाहता हूं कि मैंने केवल CQRS + इवेंट सोर्सिंग के एक समूह के साथ काम किया था, और मैंने कभी भी CQRS की कोशिश नहीं की, क्योंकि मुझे लगता है कि इवेंट सोर्सिंग के बिना यह बहुत सारे लाभ खो देता है। मैं CQRS ढांचे के रूप में हमारे कॉर्पोरेट Paralect.Domain का उपयोग करूंगा। वह किसी भी तरह से बदतर से बेहतर है। किसी भी मामले में, मैं आपको बाकी लोगों के साथ परिचित होने की सलाह देता हूं। मैं यहाँ केवल कुछ .NET फ्रेमवर्क का उल्लेख करूँगा। सबसे लोकप्रिय हैं NCQRS , लोकद CQRS , SimpleCQRS । आप बड़ी संख्या में विभिन्न डेटाबेस के समर्थन के साथ जोनाथन ओलिवर इवेंट स्टोर को भी देख सकते हैं।

CQRS के साथ शुरू करते हैं

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

यह नहीं कहना कि एक संपूर्ण परिभाषा, लेकिन अब मैं यह समझाने की कोशिश करूंगा कि वास्तव में फाउलर के दिमाग में क्या था।
आज तक, ऐसी स्थिति विकसित हुई है कि व्यावहारिक रूप से हर कोई डेटा मॉडल के साथ सीआरयूडी रिपॉजिटरी के साथ काम करता है। CQRS एक वैकल्पिक दृष्टिकोण प्रदान करता है, लेकिन न केवल डेटा मॉडल को प्रभावित करता है। यदि आप CQRS का उपयोग करते हैं, तो यह आपके एप्लिकेशन की वास्तुकला को बहुत प्रभावित करता है।

इस तरह मैंने CQRS फ्लोचार्ट का चित्रण किया


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

इवेंट सोर्सिंग

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



यदि आप उस कोड को देखते हैं जो डेटाबेस से यूनिट को उठाता है, तो आप पारंपरिक दृष्टिकोण के साथ कोई अंतर नहीं देख सकते हैं।

var user = Repository.Get<UserAR>(userId); 

वास्तव में, रिपॉजिटरी डेटाबेस (AR = एग्रीगेट रूट) से उपयोगकर्ता के एकत्रीकरण की तैयार स्थिति को नहीं लेती है, यह डेटाबेस से उन सभी घटनाओं का चयन करती है जो इस उपयोगकर्ता से जुड़ी हैं, और फिर उन्हें एग्री के ऑन () तरीके से पास करने के लिए खेलती हैं।

उदाहरण के लिए, उपयोगकर्ता स्थिति में उपयोगकर्ता आईडी को उपयोगकर्ता आईडी को पुनर्स्थापित करने के लिए निम्न विधि होनी चाहिए

 protected void On(User_CreatedEvent created) { _id = created.UserId; } 

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

आइए एक उपयोगकर्ता बनाने का उदाहरण देखें कि CQRS + इवेंट सोर्सिंग कैसे काम करता है।

टीम बनाना और भेजना

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

 public class User_CreateCommand: Command { public string UserId { get; set; } public string Password { get; set; } public string Email { get; set; } } 

टीम का वर्ग नाम आपको भ्रमित न करें, यह आम तौर पर स्वीकृत दिशानिर्देशों के अनुरूप नहीं है, लेकिन यह आपको तुरंत समझने की अनुमति देता है कि यह किस इकाई से संबंधित है और क्या कार्रवाई की है।

 var command = new User_CreateCommand { UserId = “1”, Password = “password”, Email = “test@test.com”, }; command.Metadata.UserId = command.UserId; _commandService.Send(command); 

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

 public class User_CreateCommandHandler: CommandHandler<User_CreateCommand> { public override void Handle(User_CreateCommand message) { var ar = new UserAR(message.UserId, message.Email, message.Password, message.Metadata); Repository.Save(ar); } } 

देखते हैं कि यूनिट डिजाइनर कैसा दिखता है।

 public UserAR(string userId, string email, string password, ICommandMetadata metadata): this() { _id = userId; SetCommandMetadata(metadata); Apply(new User_CreatedEvent { UserId = userId, Password = password, Email = email }); } 

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

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

 public void Handle(User_CreatedEvent message) { var doc = new UserDocument { Id = message.UserId, Email = message.Email, Password = message.Password }; _users.Save(doc); } 

एक घटना में कई हैंडलर हो सकते हैं। यह आर्किटेक्चर डेटा अखंडता को बनाए रखने में मदद करता है अगर आपका डेटा भारी रूप से विकृत हो। मान लें कि मुझे अक्सर उपयोगकर्ताओं की कुल संख्या दिखाने की आवश्यकता है। लेकिन मेरे पास उनमें से बहुत सारे हैं और सभी पर गणना ऑपरेशन मेरे डेटाबेस के लिए बहुत महंगा है। फिर मैं एक और ईवेंट हैंडलर लिख सकता हूं जो पहले से ही आँकड़ों को संदर्भित करेगा और हर बार जब मैं किसी उपयोगकर्ता को जोड़ूंगा, तो मैं कुल उपयोगकर्ता काउंटर को 1 से बढ़ा दूंगा। और मुझे यकीन है कि कोई भी काउंटर अपडेट किए बिना उपयोगकर्ता नहीं बनाएगा। यदि मैंने CQRS का उपयोग नहीं किया है, लेकिन यदि मेरे पास सामान्य ORM था, तो मुझे हर उस स्थान पर चलना होगा जहाँ इसे जोड़ा जाता है और उपयोग करने के लिए हटा दिया जाता है ताकि काउंटर अपडेट हो जाए।
और इवेंट सोर्सिंग का उपयोग मुझे अतिरिक्त लाभ देता है। यहां तक ​​कि अगर मुझे कुछ EventHandler में कोई गलती हुई है या मुझे जहां भी आवश्यकता है, उस घटना को संसाधित नहीं करता है, तो मैं आसानी से इसे पढ़ने के डेटाबेस को सही व्यावसायिक तर्क के साथ पुनर्निर्देशित करके आसानी से ठीक कर सकता हूं।

रचना के साथ समझ में आता है। परिवर्तन और टीम सत्यापन कैसे होता है? पासवर्ड बदलने के उदाहरण पर विचार करें।
मैं केवल कमांड हैंडलर और ChangePassword () एग्रीगेट विधि दूंगा, क्योंकि अन्य जगहों पर यह अंतर आम तौर पर बड़ा नहीं होता है।

कमान संभालनेवाला

 public class User_ChangePasswordCommandHandler: IMessageHandler<User_ChangePasswordCommand> { //   public void Handle(User_ChangePasswordCommand message) { //     var user = _repository.GetById<UserAR>(message.UserId); //   user.SetCommandMetadata(message.Metadata); //   user.ChangePassword(message.OldPassword, message.NewPassword); //   _repository.Save(user); } } 

अलग जड़

 public class UserAR : BaseAR { //... public void ChangePassword(string oldPassword, string newPassword) { //      ,   if (_password != oldPassword) { throw new AuthenticationException(); } //    -   Apply(new User_Password_ChangedEvent { UserId = _id, NewPassword = newPassword, OldPassword = oldPassword }); } //       protected void On(User_Password_ChangedEvent passwordChanged) { _password = passwordChanged.NewPassword; } //           protected void On(User_CreatedEvent created) { _id = created.UserId; _password = created.Password; } } } 

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

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

सूत्रों का कहना है

ASP.NET MVC पर पूरी तरह से काम करने वाला उदाहरण यहाँ है ।
वहाँ कोई डेटाबेस नहीं है, सब कुछ स्मृति में संग्रहीत है। यदि वांछित है, तो यह केवल इसे पेंच करने के लिए पर्याप्त है। बॉक्स के बाहर भी घटनाओं के भंडारण के लिए MongoDB पर ईवेंट स्टोर का एक तैयार-निर्मित कार्यान्वयन है।
Global.asax फ़ाइल में इसे पेंच करने के लिए, यह InMemoryTransitionRepository को MongoTransitionRepository के साथ बदलने के लिए पर्याप्त है।
रीड मॉडल के रूप में, मेरे पास एक स्थिर संग्रह है, इसलिए हर बार जब मैं पुनरारंभ करता हूं, तो डेटा नष्ट हो जाता है।

आगे क्या है?

इस विषय पर लेखों के बारे में मेरे कई विचार हैं। और सुझाव दें। कहो क्या सबसे दिलचस्प है।

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