CQRS: एक प्रोग्रामर की सेवा में "फूट डालो और जीतो" का सिद्धांत

पफ वास्तुकला उद्यम विकास की दुनिया में मुक्ति है। इसकी मदद से, आप लोहे को अनलोड कर सकते हैं, प्रक्रियाओं को समानांतर कर सकते हैं और कोड में आदेश को बहाल कर सकते हैं। हमने कॉर्पोरेट प्रोजेक्ट विकसित करते समय CQRS पैटर्न का उपयोग करने की कोशिश की। सब कुछ अधिक तार्किक और ... अधिक जटिल हो गया है। हाल ही में, मैंने पांडा-मीटअप सी # .नेट की बैठक में मुझे क्या सामना करना पड़ा, इस बारे में बात की, और अब मैं आपके साथ साझा कर रहा हूं।



क्या आपने कभी गौर किया है कि आपका कॉर्पोरेट आवेदन कैसा दिखता है? यह Apple और Google की तरह क्यों नहीं हो सकता है? हां, क्योंकि हमारे पास समय की निरंतर कमी है। आवश्यकताएं अक्सर बदलती हैं, उनके बदलावों का शब्द आमतौर पर "कल" ​​है। और जो सबसे अप्रिय है, व्यवसाय वास्तव में गलतियों को पसंद नहीं करता है।



किसी तरह इस के साथ रहने के लिए, डेवलपर्स ने अपने अनुप्रयोगों को भागों में विभाजित करना शुरू कर दिया। यह सब सरल शुरू हुआ - डेटा के साथ। कई लोग स्कीम से परिचित होते हैं जब डेटा अलग होता है, क्लाइंट अलग होता है, जबकि लॉजिक डेटा के रूप में एक ही जगह जमा होता है।



अच्छी रूपरेखा। सबसे बड़े DBMS में SQL के लिए पूरी तरह कार्यात्मक प्रक्रियात्मक एक्सटेंशन हैं। Oracle के बारे में एक कहावत है: "जहाँ Oracle है, वहाँ तर्क है।" इस तरह के कॉन्फ़िगरेशन की सुविधा और गति के बारे में बहस करना कठिन है।

लेकिन हमारे पास एक कॉर्पोरेट एप्लिकेशन है, और एक समस्या है: तर्क को स्केल करना मुश्किल है। और DBMS क्षमता को लोड करना अनुचित है, जो पहले से ही डेटा निकालने और अपडेट करने में समस्याओं से ग्रस्त है, और तुच्छ व्यावसायिक कार्य भी।

ठीक है, डीबीएमएस में निर्मित व्यापार तर्क प्रोग्रामिंग उपकरण, ईमानदार होने के लिए, सामान्य कॉर्पोरेट एप्लिकेशन बनाने के लिए कमजोर हैं। टी-एसक्यूएल / पीएल-एसक्यूएल में व्यावसायिक तर्क को बनाए रखना एक दर्द है। यह इस कारण के बिना नहीं है कि OOP भाषाएँ कॉर्पोरेट अनुप्रयोगों के बीच इतनी व्यापक हैं: C #, Java, आपको उदाहरण के लिए दूर नहीं जाना है।



यह एक तार्किक समाधान प्रतीत होगा: हम व्यापारिक तर्क को उजागर करते हैं। वह अपने सर्वर पर, अपने दम पर, क्लाइंट के दम पर जिएगी।

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

परतों को बढ़ाने में मदद मिलेगी। यह समाधान लगभग सही दिखता है, इसमें किसी प्रकार की आंतरिक सुंदरता होती है।



हमारे पास एक डीएएल (डेटा एक्सेस लेयर) है - डेटा को तर्क से अलग किया जाता है, आमतौर पर सीआरएम रिपॉजिटरी का उपयोग ओआरएम का उपयोग करके किया जाता है, साथ ही जटिल प्रश्नों के लिए संग्रहीत प्रक्रियाएं। यह विकल्प आपको जल्दी से पर्याप्त विकसित करने की अनुमति देता है, और एक स्वीकार्य प्रदर्शन है।

व्यावसायिक तर्क सेवाओं के हिस्से के रूप में जा सकते हैं या एक अलग परत हो सकते हैं। परतों के बीच बातचीत परिवहन वस्तुओं (डीटीओ) के माध्यम से किया जा सकता है।

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

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

एक और स्थिरता: सभी प्रोजेक्ट सबसिस्टम एक ही डेटा के साथ काम करते हैं, आपको यह चिंता करने की आवश्यकता नहीं है कि हमने एक स्थान पर डेटा रिकॉर्ड किया है, और उपयोगकर्ता इसे दूसरे भाग में नहीं देखता है।

लेयर केक 1. एन-टियर

नीचे इन सिद्धांतों पर बनाए गए एप्लिकेशन के एक विशिष्ट टुकड़े का एक उदाहरण है। हमें एक मौद्रिक आवश्यकता है, यहां मैंने एनीमिक मॉडल की जांच की। और एक क्लासिक रिपॉजिटरी है, जिसके साथ ORM काम करता है।



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

यहाँ इस सेवा का एक विशिष्ट तरीका दिखता है। उदाहरण के लिए, एक मौद्रिक दावे का पंजीकरण।



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

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

उदाहरण के लिए, हमारे सिस्टम में डेटा की मात्रा 25 टीबी तक पहुंच गई, समस्याएं दिखाई दीं। हमने खुद को एक प्रसिद्ध कंपनी से कठिन लोगों को आमंत्रित करने की कोशिश की। उन्होंने देखा और कहा: हमें आधार के पूर्ण डाउनटाइम के 14 घंटे चाहिए। हमने सोचा और कहा: दोस्तों, यह काम नहीं किया, व्यवसाय ने इसे स्वीकार नहीं किया।

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

पफ पेस्ट्री 2. सीक्यूआरएस

तो क्या करें? एक समाधान है जो प्राचीन रोम में आविष्कार किया गया था: विभाजित करने और शासन करने के लिए।



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

दूसरा - कमांड - कमांड जो डेटा को वापस किए बिना किसी ऑब्जेक्ट की स्थिति को बदलता है। यही है, आपने कुछ बदलने का आदेश दिया, और बदले में 10 हजार लाइनों की रिपोर्ट की प्रतीक्षा न करें।



यहां, रीड डेटा मॉडल स्पष्ट रूप से राइट मॉडल से अलग है। अधिकांश व्यावसायिक तर्क लेखन कार्यों पर काम करते हैं। पढ़ना एक अलग आधार पर भौतिक रूप से प्रतिनिधित्व या सामान्य रूप से काम कर सकता है। उन्हें घटनाओं या कुछ आंतरिक सेवाओं के माध्यम से विभाजित और सिंक्रनाइज़ किया जा सकता है। कई विकल्प हैं।

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

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

हमारी CQRS परियोजना

यहाँ हम अपनी परियोजना में क्या करना चाहते हैं:



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

यही है, हम नहीं हैं, जैसा कि यह था, ऑब्जेक्ट को अपडेट करना। एक मूल स्थिति है और उसके बगल में वही है जो उस पर लागू किया गया था। इस मामले में, एक बहुत बड़ा प्लस है - हम इतिहास में किसी भी समय किसी वस्तु की स्थिति को पुनर्स्थापित कर सकते हैं। वास्तव में, पत्रिका की अब आवश्यकता नहीं है। जैसा कि हम घटनाओं को संग्रहीत करते हैं, हम समझते हैं कि वास्तव में क्या हुआ था। यही है, यह नहीं है कि "पता" सेल में ग्राहक का मूल्य अपडेट किया गया था, हमारे पास सटीक घटना दर्ज है, उदाहरण के लिए, ग्राहक की चाल।

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



यदि हैंडलर और कमांड / रिक्वेस्ट अलग हो जाते हैं तो स्कीम को और विकसित किया जा सकता है। यहां, एक उदाहरण के रूप में, हमारे पास एक टीम है - एक पंजीकृत मौद्रिक दावा: एक तारीख, राशि, ग्राहक और अन्य क्षेत्र हैं।

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

हम यह सब कैसे करते हैं? एक डिस्पैचर है जो जानता है कि उसके पास ये सभी हैंडलर कहां संग्रहीत हैं।



डिस्पैचर एपीआई के लिए (एक डीआई कंटेनर के माध्यम से) उदाहरण के लिए पारित किया जाता है। और जब कमांड आती है, यह केवल निष्पादित करता है। वह जानता है कि कंटेनर कहां है, जहां टीमें हैं, और उन्हें निष्पादित करता है। अनुरोधों के साथ - इसी तरह।

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

अतुल्यकालिक संचार के लिए, रेबस सेवा बस का उपयोग किया गया था।



सरल कार्यों के लिए, यह पर्याप्त से अधिक है।

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



यहाँ, उदाहरण के लिए, एक ऐसी विधि है, जिसमें से सब कुछ फालतू में फेंक दिया जाता है। मनी दावा पंजीकरण टीम में, हम मांग को पंजीकृत करते हैं और बस में घटना को प्रकाशित करते हैं कि धन का दावा पंजीकृत है।



इसमें दिलचस्पी रखने वाला कोई भी व्यक्ति इस पर प्रतिक्रिया देगा। उदाहरण के लिए, उपयोगकर्ता प्रमाणीकरण और लॉगिंग वहां काम करेगा।

यहाँ एक उदाहरण अनुरोध है। सब कुछ सरल हो गया: हम भंडार को पढ़ते हैं और देते हैं।



मैं रेबस.गा पर अलग से रहना चाहता हूं। यह एक पैटर्न है जो आपको परमाणु क्रियाओं में व्यापारिक लेनदेन को तोड़ने की अनुमति देता है। यह आपको एक बार में सभी को अवरुद्ध करने की अनुमति नहीं देता है, लेकिन धीरे-धीरे और बदले में।



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

आइए देखें कि इस मामले में धन के दावे को संसाधित करने के लिए वर्ग कैसा दिखता है। सब कुछ स्पष्ट है: आदेश हैं, अनुरोध हैं जो पंजीकरण प्रक्रिया से संबंधित हैं, ठीक है, लॉग के साथ एक बस।



इस मामले में, एक हैंडलर है। जब कोई घटना होती है और एक टीम मौद्रिक दावों को दर्ज करने के लिए आती है, तो वह इसका जवाब देती है। अंदर, सब कुछ पहले जैसा ही है, लेकिन ख़ासियत यह है कि प्रक्रिया द्वारा एक समूहीकरण है।



इस वजह से, यह प्रत्येक फ़ाइल में थोड़ा आसान, कम परिवर्तन हो गया।

निष्कर्ष

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

क्या हर किसी को सब कुछ छोड़ने की जरूरत है और बड़े पैमाने पर CQRS पर स्विच करना है? नहीं, आपको यह देखने की जरूरत है कि किसी विशेष परियोजना के लिए कौन सा परिदृश्य सबसे अच्छा काम करता है। उदाहरण के लिए, यदि आपका सबसिस्टम निर्देशिकाओं के साथ काम करता है, तो CQRS की आवश्यकता नहीं है, क्लासिक स्तरित दृष्टिकोण एक सरल और अधिक सुविधाजनक परिणाम देता है।

पांडा मीटअप में प्रदर्शन का पूरा संस्करण नीचे उपलब्ध है।


यदि आप विषय में गहराई से उतरना चाहते हैं, तो इन संसाधनों का अध्ययन करने के लिए यह समझ में आता है:

CQRS वास्तुकला शैली - Microsoft से

अलेक्जेंडर बेंड्यू का ब्लॉग

कॉम्बीसो विश्वविद्यालय उदाहरण CQRS, MediatR, AutoMapper और अधिक के साथ - जिमी बोगर्ड द्वारा

CQRS - मार्टिन फाउलर द्वारा

रिबास