CQRS ओवरइंजीनियरिंग नहीं है?


16

मुझे अभी भी रिपॉजिटरी के अच्छे पुराने दिन याद हैं। लेकिन रिपॉजिटरी समय के साथ बदसूरत हो जाते थे। तब CQRS को मुख्यधारा मिली। वे अच्छे थे, वे ताजी हवा की सांस थे। लेकिन हाल ही में मैं खुद से बार-बार पूछ रहा हूं कि क्यों न मैं तर्क को एक कंट्रोलर के एक्शन मेथड (विशेषकर वेब एपि में जहां एक्शन अपने आप में किसी प्रकार का कमांड / क्वेरी हैंडलर हो) को सही नहीं रखता।

पहले मेरे पास इसके लिए एक स्पष्ट जवाब था: मैं इसे परीक्षण के लिए करता हूं क्योंकि उन सभी अचूक एकल और समग्र बदसूरत ASP.NET बुनियादी ढांचे के साथ नियंत्रक का परीक्षण करना कठिन है। लेकिन समय बदल गया है और ASP.NET अवसंरचना वर्ग आजकल (विशेषकर ASP.NET Core में) अधिक यूनिट परीक्षण अनुकूल हैं।

यहाँ एक विशिष्ट WebApi कॉल है: कमांड जोड़ा गया है और सिग्नलआर क्लाइंट को इसके बारे में सूचित किया गया है:

public void AddClient(string clientName)
{
    using (var dataContext = new DataContext())
    {
        var client = new Client() { Name = clientName };

        dataContext.Clients.Add(client);

        dataContext.SaveChanges();

        GlobalHost.ConnectionManager.GetHubContext<ClientsHub>().ClientWasAdded(client);
    }
}

मैं आसानी से यूनिट टेस्ट / मॉक कर सकता हूं। अधिक, ओविन के लिए धन्यवाद, मैं स्थानीय वेबएपीआई और सिग्नलआर सर्वर को सेटअप कर सकता हूं और एक एकीकरण परीक्षण कर सकता हूं (और वैसे भी बहुत तेजी से)।

हाल ही में मैंने बोझिल कमांड / क्वेरी हैंडलर बनाने के लिए कम और कम प्रेरणा महसूस की और मैं वेब एपि क्रियाओं में कोड रखने के लिए हूं। मैं केवल एक अपवाद बनाता हूं यदि तर्क दोहराया जाता है या यह वास्तव में जटिल है और मैं इसे अलग करना चाहता हूं। लेकिन मुझे यकीन नहीं है कि मैं यहां सही काम कर रहा हूं।

एक सामान्य आधुनिक ASP.NET अनुप्रयोग में तर्क के प्रबंधन के लिए सबसे उचित तरीका क्या है? अपने कोड को कमांड और क्वेरी हैंडलर में स्थानांतरित करना कब उचित है? क्या कोई बेहतर पैटर्न हैं?

अपडेट करें। मुझे डीडीडी-लाइट दृष्टिकोण के बारे में यह लेख मिला । इसलिए ऐसा लगता है कि कोड के जटिल भागों को कमांड / क्वेश्चन हैंडलर्स तक ले जाने के मेरे दृष्टिकोण को CQRS- लाइट कहा जा सकता है।


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

यदि आप अपना कोड इंफ्रास्ट्रक्चर कोड (यानी क्लाइंट आईपी एड्रेस प्राप्त करते हैं) रखते हैं, तो परीक्षण करना कठिन है। यदि आप तर्क को एक क्वेरी / कमांड में अलग करते हैं, तो यह बहुत आसान है। कोड नमूना थोड़ा भ्रमित था, इसलिए मैंने इसे अपडेट किया।
साइबेरियाईगू

1
क्वेरी और कमांड का कोई तर्क नहीं है। वे गूंगे डीटीओ हैं। फिर आपके पास आपकी कमांड / क्वेरी हैंडलर हैं , लेकिन वे बिल्कुल उसी तरह हैं जैसे एप्लिकेशन सर्विसेज, इंटरेक्टर्स, बिजनेस सर्विसेज, आप इसे नाम देते हैं ... एक गैर-सीक्यूआरएस संदर्भ में। नियंत्रक की तुलना में एक अलग वस्तु में आवेदक / उपयोग के मामले का तर्क रखना CQRS विशिष्ट बात नहीं है।
गुरिल्ला 31

इसके अलावा, सिंगलटन बनाम इंजेक्टेड निर्भरता का प्रश्न पूरी तरह से CQRS के लिए रूढ़िवादी है। आपके पास एक कमांडहैंडलर सिंगलटन को कॉल करने वाला एक नियंत्रक हो सकता है जो एक रिपॉजिटरी सिंगलटन कॉल करता है ...
guillaume31

1
@ guillaume31, CQRS रिपॉजिटरी / अप्लायस सर्विस कॉल की तुलना में अधिक बोझिल हो जाता है। उन्हें आमतौर पर 2-3 वर्गों (यानी क्वेरी, क्वेरीहैंडलर, क्वेरीसॉल्ट), बुनियादी ढांचे, आदि की आवश्यकता होती है
साइबेरियाई

जवाबों:


17

क्या CQRS अपेक्षाकृत जटिल और महंगा पैटर्न है? हाँ।

क्या यह ओवर-इंजीनियरिंग है? बिलकुल नहीं।

में मूल लेख जहां मार्टिन Fowler CQRS बारे में बात करती आप CQRS जहां यह लागू नहीं है का उपयोग नहीं के बारे में चेतावनी का एक बहुत देख सकते हैं:

किसी भी पैटर्न की तरह, CQRS कुछ जगहों पर उपयोगी है, लेकिन दूसरों में नहीं।

CQRS सभी संबंधितों के लिए एक महत्वपूर्ण मानसिक छलांग है, इसलिए जब तक लाभ कूद के लायक नहीं है, तब तक निपटना नहीं चाहिए

जबकि मैं CQRS के सफल उपयोग में आया हूं, अब तक जितने भी मामले मैंने चलाए हैं उनमें से अधिकांश इतने अच्छे नहीं हैं ...

इन लाभों के बावजूद, आपको CQRS का उपयोग करने के बारे में बहुत सतर्क रहना चाहिए

... ऐसी प्रणाली में CQRS को जोड़ने से महत्वपूर्ण जटिलता जुड़ सकती है

मेरा जोर ऊपर।

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

और यह संपूर्ण अनुप्रयोग नहीं हो सकता है, लेकिन इसका केवल एक छोटा सा हिस्सा है।

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

CQRS उस समस्या के लिए एकदम सही है जहाँ आपके पास एक ही संसाधन में डेटा या लेखन में समान रूप से सहयोग करने वाले कई कलाकार हैं।

इसके अलावा, आपकी सभी समस्याओं के लिए एक ही समस्या को हल करने के लिए बनाए गए पैटर्न को फैलाना आपके लिए और अधिक समस्याएं पैदा करेगा।


कुछ अन्य उपयोगी लिंक:

http://udidahan.com/2011/04/22/when-to-avoid-cqrs/

http://codebetter.com/gregyoung/2012/09/09/cqrs-is-not-an-architecture-2/


3
"अपेक्षाकृत जटिल और महंगा पैटर्न" भाग को छोड़कर सब पर सहमत हैं। CQRS केवल रीड को लिखने से अलग कर रहा है। आप इसे डक्ट टेप, ज़ीरो मिडलवेयर / कॉम्प्लेक्स टूलिंग, और पहले जैसे ही डेटाबेस रख सकते हैं, के लिए कर सकते हैं।
गिलोय 31

@ guillaume31, यह एक उचित बिंदु है। मुझे लगता है कि यह मूल प्रश्न से विचार को काफी प्रभावित करता है: "वेब एपि में जहां कार्रवाई अपने आप में कुछ प्रकार की कमांड / क्वेरी है"। लेकिन क्या आपने किसी भी सीक्यूआरआरएस नमूने (जीथब को अधिमानतः) देखा है जो कमांड और प्रश्नों के लिए अलग-अलग कक्षाओं का उपयोग नहीं करते हैं? यही कारण है कि जब मैं यह देखने की कोशिश करता हूं कि अन्य लोग .NET में CQRS को कैसे लागू करते हैं।
साइबेरियाईगू

हां, लेकिन यह अतिरंजना नहीं है। यह पैटर्न का मूल आधार है - प्रश्नों को लिखना, डोमेन मॉडल से मॉडल पढ़ना।
गुइलुमे31

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

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

4

CQRS रिपोजिटरी के लिए एक-के-लिए-एक प्रतिस्थापन नहीं है, वास्तव में क्योंकि यह एक जटिल, महंगा पैटर्न है जो केवल कुछ मामलों में उपयोगी है।

यहाँ यूडी दहन को योग्यता में कहना है:

CQRS (और इवेंट सोर्सिंग) का उपयोग करने वाले अधिकांश लोगों को ऐसा नहीं करना चाहिए था।

[...]

मुझे यह कहते हुए खेद है कि अधिकांश नमूना अनुप्रयोग जो आप ऑनलाइन देखेंगे कि CQRS वास्तुशिल्प रूप से गलत हैं। मैं भी फ्रेमवर्क से बेहद सावधान रहूंगा जो आपको एक इकाई-शैली के कुल रूट CQRS मॉडल की ओर मार्गदर्शन करता है।

( स्रोत )

मार्टिन फाउलर:

[...] आपको CQRS का उपयोग करने के बारे में बहुत सतर्क रहना चाहिए । कई सूचना प्रणाली एक सूचना आधार की धारणा के साथ अच्छी तरह से फिट होती हैं जिसे उसी तरह से अपडेट किया जाता है जो कि इस तरह के सिस्टम में CQRS जोड़कर महत्वपूर्ण जटिलता जोड़ सकता है।

( स्रोत )

अंत में, ग्रेग यंग:

CQRS को एक वास्तुशिल्प पैटर्न कहा जा सकता है।

[...]

यह समझना बहुत महत्वपूर्ण है कि अधिकांश वास्तुशिल्प पैटर्न हर जगह लागू करने के लिए अच्छे नहीं हैं। यदि आप एक वास्तुशिल्प दिशानिर्देश में वास्तुशिल्प पैटर्न देखते हैं तो आपको शायद एक समस्या है

[...]

इवेंट सोर्सिंग का उपयोग करने वाले लोगों से मुझे सबसे बड़ी विफलता यह है कि वे हर जगह इसका उपयोग करने की कोशिश करते हैं।

( स्रोत )

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.