ये प्रश्न एक अच्छी वास्तुकला में कहाँ फिट होते हैं?
मैं थोड़ी देर के लिए एक समस्या के बारे में सोच रहा था और मुझे वास्तव में यह नहीं लगता कि मैंने इसे कैसे संपर्क किया है।
मैं डीडीडी के साथ अधिक से अधिक काम करने की कोशिश कर रहा हूं लेकिन कुछ प्रस्तुति परिदृश्य वास्तव में प्रदर्शन के मामले में इसके साथ फिट नहीं हैं।
मान लीजिए कि हमारे पास किराए की कारों के लिए एक प्रणाली है, और वहां हमारा एक विचार है कि सभी कारों को प्रदर्शित किया जाना चाहिए और उन्हें कितनी बार किराए पर दिया गया है।
डीडीडी-दुनिया में मुझे लगता है कि मेरे पास मेरी किराये की कारों के लिए एक भंडार होगा और "किराए के लिए" के लिए कुछ भंडार होगा। मैं यह भी अनुमान लगाता हूं कि कोई ऐसी सेवा हो सकती है जो उनके बीच बातचीत, समझौते बनाने आदि को संभालती है।
लेकिन जब किराये की कारों और किराए की संख्या के साथ दृश्य प्रस्तुत करने की बात आती है, तो मुझे यकीन नहीं है कि इसे कहां रखा जाए। चूँकि आवश्यकताएँ इस दृष्टिकोण के लिए बहुत विशिष्ट हैं, इसलिए मेरा अनुमान है कि सबसे अधिक प्रदर्शन करने वाले संस्करण में किसी प्रकार का "रेंटलकार्सवर्व्यू" होगा, जो कि भंडार द्वारा लौटाया गया था। लेकिन यह उन रिपॉजिटरी को "प्रदूषित" कर देगा, जो बहुत ही विशिष्ट हैं।
इसलिए मैं सोच रहा हूं कि क्या किसी ने भी समान मुद्दों का सामना किया है और इसे कैसे हल किया गया है? मैं इसे अलग करने के लिए CQRS को देख रहा हूं, इस तरह के विचारों और अपडेट के लिए मेरे डोमेन मॉडल के लिए प्रश्नों का उपयोग कर रहा हूं। क्या यह एक अच्छा तरीका है?
इसके अलावा, इन क्वेरी-हैंडलर्स में कच्चे एसक्यूएल को "ओके" करना ठीक होगा या एक अंतर्निहित रिपॉजिटरी के साथ इन्हें भी अमूर्त कर देगा?
जवाब
इन दिनों, सामान्य उत्तर यह है कि आपके क्वेरी कोड पथ "डोमेन मॉडल" को बायपास कर देंगे, और सीधे आपकी जानकारी की प्रतियों के साथ काम करेंगे।
यहाँ तर्क यह है कि एक क्वेरी डोमेन मॉडल में संग्रहीत जानकारी को परिवर्तित नहीं करती है, और इसलिए हमें उस समारोह से लाभ नहीं होता है जो उस जानकारी को डोमेन ऑब्जेक्ट में डाल देता है ताकि उन्हें फिर से बाहर निकाल सकें।
उदाहरण के लिए, यदि आपकी सभी जानकारी समान रिलेशनल डेटाबेस में संग्रहीत है, तो आप डेटाबेस को क्वेरी करने की बहुत संभावना रखते हैं, और परिणाम में सूचना को सही आकार में बदल देते हैं, और क्लाइंट को वापस भेज देते हैं।
जब आपको क्वेरी का उत्तर देने की आवश्यकता होती है, तो इसे कई सिस्टमों में वितरित किया जाता है, फिर रिपोर्ट तैयार करने के लिए और अधिक काम आता है। जब रिपोर्ट उत्पन्न करने के लिए आवश्यक समय आपके विलंबता लक्ष्य से अधिक हो जाता है, तो आप उन डिज़ाइनों को देखना शुरू कर देते हैं जहाँ आप रिपोर्ट के महंगे भागों को कैश कर सकते हैं । कुछ मामलों में, इसका मतलब होगा कि पूरी रिपोर्ट कैश की गई है।
CQRS और DDD एक आदर्श मैच हैं।
कमांड आपके रिपॉजिटरी और डीडीडी मॉडल से गुजरते हैं। क्वेरी कच्चे SQL या हल्के ORM हो सकते हैं, विशेष रूप से प्रत्येक दृश्य के लिए अलग-अलग मॉडल।
अपने सिस्टम को इस तरह से तैयार करना आपको जटिल व्यावसायिक नियमों को संभालने का एक ठोस तरीका देता है, जिसमें पठन के लिए सर्वोत्तम संभव प्रदर्शन होता है।
आइए यह इंगित करना शुरू करें कि स्मार्ट क्वेरीज़ एक DDD कोड गंध है। ज्यादातर बार, आपको बस इतना करना है
- अपनी आईडी द्वारा एक कुल प्राप्त करें (बात कर रहे हैं: GET / उपयोगकर्ताओं / xyz)
- दिए गए रूट (/ उपयोगकर्ता? पृष्ठ = 0 और सीमा = 10) के साथ सभी समुच्चय प्राप्त करें
- कुछ सरल फ़िल्टर के साथ समुच्चय का उपसमूह पुनः प्राप्त करें (RESTful बात करते हुए: GET / users? username_startsWith = johnd & page = 0 & limit = 10)
जटिल अनुप्रयोगों को जटिल चीजें करने की आवश्यकता होती है, स्पष्ट, इसलिए आपको अपने कुल से अनुमानों का निर्माण करने की आवश्यकता हो सकती है । जाहिर है, आपके समुच्चय का कोई सुराग नहीं होना चाहिए कि एक प्रक्षेपण क्या है, लेकिन वहाँ आप उन्हें बनाने के लिए सभी आवश्यक डेटा पा सकते हैं, क्योंकि आप अपने डोमेन को न केवल निरंतर रूप से उत्परिवर्तित करने के लिए डिज़ाइन कर रहे हैं, बल्कि इसका पालन भी किया जा सकता है
यह CQRS अवधारणाओं को शुरू किए बिना भी एक उचित दृष्टिकोण है। हमारे अधिकांश अनुप्रयोग CRUD अनुप्रयोग + कुछ डोमेन सत्यापन नियम हैं। यदि आप " अवलोकन " " रिपोर्ट " " आंकड़े " " सारांश " " इतिहास " जैसे शब्दों से मिलते हैं , तो आपकी आवश्यकताओं / कहानियों / कोड में बस कुछ ही बार, आप जानते हैं कि आप उन्हें विशिष्ट प्रश्नों के माध्यम से मेमोरी में केवल लोडिंग एग्रीगेट प्रबंधित कर सकते हैं, कुछ एकत्रीकरण कह सकते हैं। विधि (मायने रखता है, रकम, औसत) ई कुछ प्रक्षेपण डीटीओ के खिलाफ मानचित्रण करते हैं
जब आपकी परियोजना में उपरोक्त मामले प्रमुख हैं, जब केवल कुछ जानकारी एकत्र करने के लिए समुच्चय लोड करना आपके सिस्टम के लिए बहुत बड़ा बोझ है, तो हाँ, आप उन दो उपयोग मामलों में से एक को पूरा कर रहे हैं जिनमें CQRS मददगार है
आप अपना समुच्चय प्रदान करेंगे (अर्थात्, राइट-साइड-एग्रीगेट) हर बार एक उल्लेखनीय राज्य परिवर्तन के दौरान डोमेन ईवेंट को ट्रिगर करने की क्षमता हो गई है
आप एक अलग मॉड्यूल का निर्माण करेंगे, जहां आपके पास प्रक्षेपण विशिष्ट रिपोजिटरी और इवेंट हैंडलर होंगे (आपके मामले में onEvent (CarRentedOutEvt evt) जैसी कुछ चीज़ों को अपडेट करने और अपने अनुमानों को सहेजने के लिए।
आपके पास (फिर से आराम से बोलना) GET / rents / ओवरव्यू एडमिन एपीआई होगा जो बहुत विनम्रतापूर्ण व्यवहार करेगा। सभी जटिलता अपडेट-टाइम पर लोड हो जाती है
आपको एक से अधिक पढ़े गए मॉडल की अनुमति है और इस मामले में, एक "रिपोर्टिंग" रीड मॉडल है कि यह "रेंटेड आउट" ईवेंट प्राप्त होने पर खुद को अपडेट करने के लिए आवश्यक घटनाओं की सदस्यता लेता है।