सबसे पहले, मैं यह कहना चाहता हूं कि यह एक उपेक्षित प्रश्न / क्षेत्र है, इसलिए यदि इस प्रश्न में सुधार की आवश्यकता है, तो मुझे यह एक महान प्रश्न बनाने में मदद करें जो दूसरों को लाभ पहुंचा सके! मैं उन लोगों से सलाह और मदद की तलाश कर रहा हूं जिन्होंने इस समस्या को हल करने वाले समाधानों को लागू किया है, न कि केवल विचारों को आजमाने के लिए।
मेरे अनुभव में, एक एप्लिकेशन के दो पक्ष हैं - "कार्य" पक्ष, जो काफी हद तक डोमेन संचालित है और वह है जहां उपयोगकर्ता डोमेन मॉडल (एप्लिकेशन के "इंजन") और रिपोर्टिंग पक्ष, जहां उपयोगकर्ता हैं के साथ बड़े पैमाने पर बातचीत करते हैं कार्य पक्ष पर क्या होता है इसके आधार पर डेटा प्राप्त करें।
कार्य की ओर, यह स्पष्ट है कि एक समृद्ध डोमेन मॉडल के साथ एक आवेदन डोमेन मॉडल में व्यावसायिक तर्क होना चाहिए और डेटाबेस का उपयोग ज्यादातर दृढ़ता के लिए किया जाना चाहिए। चिंताओं का पृथक्करण, प्रत्येक पुस्तक इसके बारे में लिखी गई है, हम जानते हैं कि क्या करना है, भयानक।
रिपोर्टिंग पक्ष का क्या? क्या डेटा वेयरहाउस स्वीकार्य हैं, या क्या वे खराब डिज़ाइन हैं क्योंकि वे डेटाबेस और बहुत ही डेटा में व्यावसायिक तर्क को शामिल करते हैं? डेटाबेस से डेटा को डेटा वेयरहाउस डेटा में एकत्रित करने के लिए, आपने डेटा के लिए व्यावसायिक तर्क और नियम लागू किए होंगे, और यह तर्क और नियम आपके डोमेन मॉडल से नहीं आए थे, यह आपके डेटा एकत्रीकरण प्रक्रियाओं से आया था। क्या वह गलत है?
मैं बड़े वित्तीय और परियोजना प्रबंधन अनुप्रयोगों पर काम करता हूं जहां व्यापार तर्क व्यापक है। इस डेटा पर रिपोर्टिंग करते समय, रिपोर्ट / डैशबोर्ड के लिए आवश्यक जानकारी खींचने के लिए मेरे पास अक्सर बहुत सारे एकत्रीकरण होंगे और एकत्रीकरण में बहुत सारे व्यावसायिक तर्क होते हैं। प्रदर्शन के लिए, मैं इसे उच्च एकत्रित तालिकाओं और संग्रहीत प्रक्रियाओं के साथ कर रहा हूं।
उदाहरण के रूप में, मान लीजिए कि एक रिपोर्ट / डैशबोर्ड को सक्रिय परियोजनाओं (10,000 परियोजनाओं की कल्पना) की एक सूची दिखाने के लिए आवश्यक है। प्रत्येक परियोजना को इसके साथ दिखाए गए मैट्रिक्स के एक सेट की आवश्यकता होगी, उदाहरण के लिए:
- कुल बजट
- तिथि करने का प्रयास
- जलने की दर
- वर्तमान जल दर पर बजट थकावट की तारीख
- आदि।
इनमें से प्रत्येक में बहुत सारे व्यावसायिक तर्क शामिल हैं। और मैं सिर्फ संख्या या कुछ सरल तर्क को गुणा करने की बात नहीं कर रहा हूं। मैं बजट प्राप्त करने के बारे में बात कर रहा हूं, आपको 500 अलग-अलग दरों के साथ एक दर पत्रक लागू करना होगा, प्रत्येक कर्मचारी के समय के लिए (कुछ परियोजनाओं पर, दूसरे का गुणक है), खर्चों और किसी भी उपयुक्त मार्कअप को लागू करना होगा, आदि। तर्क व्यापक है। क्लाइंट के लिए उचित समय में इस डेटा को प्राप्त करने के लिए बहुत सारे एकत्रीकरण और क्वेरी ट्यूनिंग हुई।
क्या इसे पहले डोमेन के माध्यम से चलाया जाना चाहिए? प्रदर्शन के बारे में क्या? यहां तक कि सीधे एसक्यूएल प्रश्नों के साथ, मैं क्लाइंट को समय की उचित मात्रा में प्रदर्शित करने के लिए मुश्किल से इस डेटा को तेजी से प्राप्त कर रहा हूं। अगर मैं इन सभी डोमेन ऑब्जेक्ट्स को पुन: प्राप्त कर रहा हूं, और एप्लिकेशन लेयर में उनके डेटा को मिक्स एंड मैच कर रहा हूं या एग्रीगेट कर रहा हूं, या एप्लिकेशन में डेटा एग्रीगेट करने की कोशिश कर रहा हूं, तो मैं इस डेटा को तेजी से प्राप्त करने की कोशिश नहीं कर सकता।
इन मामलों में ऐसा लगता है कि SQL डेटा क्रंच करने में अच्छा है, और इसका उपयोग क्यों नहीं किया जाता है? लेकिन फिर आपके पास अपने डोमेन मॉडल के बाहर व्यावसायिक तर्क हैं। व्यावसायिक तर्क में कोई परिवर्तन आपके डोमेन मॉडल और आपकी रिपोर्टिंग एकत्रीकरण योजनाओं में बदलना होगा।
मैं वास्तव में इस बात के लिए नुकसान में हूं कि डोमेन संचालित डिजाइन और अच्छी प्रथाओं के संबंध में किसी भी एप्लिकेशन के रिपोर्टिंग / डैशबोर्ड भाग को कैसे डिज़ाइन किया जाए।
मैंने MVC टैग जोड़ा क्योंकि MVC डिज़ाइन फ़्लेवर डु पत्रिका है और मैं इसे अपने वर्तमान डिज़ाइन में उपयोग कर रहा हूं, लेकिन यह पता नहीं लगा सकता कि रिपोर्टिंग डेटा इस प्रकार के एप्लिकेशन में कैसे फिट बैठता है।
मैं इस क्षेत्र में किसी भी मदद की तलाश कर रहा हूं - किताबें, डिजाइन पैटर्न, मुख्य शब्द Google, लेख, कुछ भी। मुझे इस विषय पर कोई जानकारी नहीं मिल रही है।
संपादित करें और अन्य उदाहरण
एक और आदर्श उदाहरण मैं आज भर में चला। ग्राहक ग्राहक बिक्री टीम के लिए एक रिपोर्ट चाहता है। वे चाहते हैं कि एक साधारण मीट्रिक जैसा लगता है:
प्रत्येक विक्रय व्यक्ति के लिए, आज तक की उनकी वार्षिक बिक्री क्या है?
लेकिन यह जटिल है। प्रत्येक बिक्री व्यक्ति ने कई बिक्री अवसरों में भाग लिया। कुछ वे जीते, कुछ उन्होंने नहीं जीते। प्रत्येक बिक्री अवसर में, कई बिक्री वाले लोग होते हैं जिन्हें प्रत्येक को उनकी भूमिका और भागीदारी के अनुसार बिक्री के लिए क्रेडिट का प्रतिशत आवंटित किया जाता है। तो अब इसके लिए डोमेन के माध्यम से जाने की कल्पना करें ... ऑब्जेक्ट रिहाइड्रेशन की मात्रा आपको प्रत्येक बिक्री व्यक्ति के लिए डेटाबेस से इस डेटा को खींचने के लिए करना होगा:
सभी प्राप्त करें
SalesPeople->
प्रत्येक के लिए अपनाSalesOpportunities->
प्राप्त करें प्रत्येक के लिए अपनी बिक्री का प्रतिशत प्राप्त करें और अपनी बिक्री राशि की गणना करें और
फिर अपनी सभीSalesOpportunityबिक्री राशि जोड़ें ।
और वह एक मीट्रिक है। या आप एक SQL क्वेरी लिख सकते हैं जो इसे जल्दी और कुशलता से कर सकती है और इसे तेज करने के लिए ट्यून करती है।
EDIT 2 - CQRS पैटर्न
मैंने CQRS पैटर्न के बारे में पढ़ा है और, जबकि पेचीदा, यहां तक कि मार्टिन फाउलर का कहना है कि यह परीक्षण नहीं किया गया है। तो यह समस्या अतीत में हल कैसे हुई। इसका किसी न किसी बिंदु पर सभी को सामना करना पड़ा होगा। सफलता के ट्रैक रिकॉर्ड के साथ एक स्थापित या अच्छा पहनावा क्या है?
संपादन 3 - रिपोर्टिंग सिस्टम / उपकरण
इस संदर्भ में एक और बात पर विचार करना उपकरण है। रिपोर्टिंग सेवा / क्रिस्टल रिपोर्ट, विश्लेषण सेवाएँ और कॉग्नोसेंटी, आदि सभी SQL / डेटाबेस से डेटा की उम्मीद करते हैं। मुझे संदेह है कि आपका डेटा आपके व्यवसाय के माध्यम से बाद में इनके लिए आएगा। और फिर भी वे और उनके जैसे अन्य लोग बहुत बड़ी प्रणालियों में रिपोर्टिंग का एक महत्वपूर्ण हिस्सा हैं। इन आंकड़ों के लिए डेटा को कैसे ठीक से संभाला जाता है जहां इन प्रणालियों के डेटा स्रोत में व्यावसायिक तर्क भी है और संभवत: स्वयं रिपोर्ट में भी?
