2011-01-14 10 views
8

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

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

प्रत्येक उत्पाद का मूल मूल्य होगा, और नियम लागू होने पर मूल मूल्य मूल रूप से जोड़/हटा देंगे।

एक बहुत ही सरल नमूना नियम हो सकता है:

उत्पाद एक्स के लिए, यदि (क्रय उद्देश्य = पुनर्विक्रय और आयु> 25) आधार मूल्य 25 $ जोड़ें।

तो ऐसे 2 प्रकार के उपयोगकर्ता हैं जो सिस्टम, प्रशासकों का उपयोग करते हैं, जो उत्पादों, नियमों और आधारभूत कीमतों को परिभाषित करते हैं; और अन्य उपयोगकर्ता जो परिदृश्य पर आधारित परिदृश्य के आधार पर क्वेरी करते हैं, जो वे यूआई के माध्यम से दर्ज करते हैं।

मेरा भ्रम यहां है: परिदृश्य चलाने से डोमेन की स्थिति में कोई बदलाव नहीं आता है, परिदृश्य निष्पादन के परिणामस्वरूप कोई बाहरी बाहरी प्रणाली/व्यक्ति दिलचस्पी नहीं लेता है, लेकिन चल रहे उपयोगकर्ता स्वयं - यह लौटाता है दिए गए परिदृश्य के लिए लागू नियमों को चलाने के बाद मूल्य गणना का नतीजा। उदाहरण के लिए, उपयोगकर्ता उत्पाद X का चयन कर सकते हैं और किसी दिए गए परिदृश्य के लिए मूल्य निर्धारण कर सकते हैं, जैसे (खरीद उद्देश्य = पुनर्विक्रय और आयु = 40)। दोबारा, चूंकि यह ऑपरेशन डोमेन स्थिति को बिल्कुल नहीं बदलता है, मुझे लगता है कि यह एक प्रश्न है। लेकिन, अंतिम मूल्य की गणना करने के लिए परिदृश्य पर एक नियम इंजन चल रहा है, जो मुझे लगता है कि डोमेन तर्क चलाने के रूप में वर्गीकृत किया जा सकता है। तो - यह तर्क कहां से संबंधित है? क्या यह एक प्रश्न है जो सिर्फ पढ़ने वाले मॉडल से काम करता है, या एक परिदृश्य चला रहा है जिसे डोमेन मॉडल में चलाने की आवश्यकता है? दोबारा, ऐसा लगता है कि डोमेन लेयर इन नियमों के लिए जगह है, लेकिन फिर मैं उपयोगकर्ता को परिदृश्य निष्पादन के परिणाम को कैसे पास करूं (ऐसा लगता है कि इस तरह से सोचने वाली क्वेरी की तरह)। या शायद, सीक्यूआरएस इस विशेष समस्या का सही समाधान नहीं है?

+0

+1 मुझे यह बताने के लिए कि एक [cqrs] (http://blog.fossmo.net/post/Command-and-Query- उत्तरदायित्व- पृथक्करण-%28CQRS%29.aspx) पैटर्न मैंने कभी नहीं देखा पहले। – k3b

उत्तर

4

मेरे पास अपने डोमेन में यह सटीक समस्या थी (ई-शेड्यूलिंग 4 हेल्थकेयर)। असल में सिस्टम को डोमेन मॉडल (लिखने की तरफ) का उपयोग करके कॉन्फ़िगर किया गया है। यह आपके डोमेन में नियम, उत्पाद और आधार मूल्यों को परिभाषित करेगा। डोमेन से क्या आता है? घटनाक्रम, राज्य परिवर्तन, चीजें जो हुआ, साथ ही क्यों हुआ। अब मैंने जो किया वह एक अलग बोल्ड संदर्भ में इन घटनाओं का उपभोग करता था, मेरे मामले में एक जटिल खोज इंजन जो डॉक्टरों, ऑपरेटिंग थियेटर और महंगे उपकरण के कार्यक्रमों में मुफ्त स्लॉट पाता है। यह एक मार्ग हो सकता है जो आप ले सकते हैं, अपने उत्पाद, आधार मूल्य और नियम से संबंधित घटनाओं का उपभोग कर सकते हैं और उन्हें इस तरह से स्टोर कर सकते हैं कि उस डेटा के शीर्ष पर बैठे नियम इंजन, परिदृश्यों के लिए उपयोगकर्ता अनुरोधों को कुशलता से संभाले जा सकते हैं मुमकिन। सबसे अधिक संभावना है कि आप पाएंगे कि परिवर्तन (डोमेन) स्टोर करने के लिए मॉडल उन मॉडलों से अलग है जो परिदृश्य (नियम इंजन) से पूछताछ के लिए अनुकूलित किए गए हैं। आपके डोमेन में शायद "आप एक ही उत्पाद को दो बार निर्दिष्ट नहीं कर सकते" जैसे नियम होंगे या "इस नियम का मिलान कभी नहीं किया जाएगा (आयु & आयु> 25)"। डोमेन केवल वैध राज्य परिवर्तनों की अनुमति के साथ चिंतित है। यह नियम इंजन की चिंता नहीं है। आप डोमेन में परिभाषित अपने नियम इंजन में अवधारणाओं/कक्षाओं का पुन: उपयोग करने का लुत्फ उठाएंगे। आग्रह करें कि आग्रह करें।प्रश्न अगर वे वास्तव में एक ही उद्देश्य की सेवा करते हैं। एक अलग उद्देश्य के लिए इसे दो बार मॉडलिंग करना गंदा या DRY का उल्लंघन नहीं है।

+0

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

+0

आपके प्रतिनिधि, Yves के लिए धन्यवाद। लेकिन, मैं अभी भी 100% स्पष्ट नहीं हूँ। तो क्या मेरे पास 3 बाध्य संदर्भ हैं? 1 - डोमेन मॉडल (साइड मैनेजमेंट स्टेटस लिखें), 2 - परिदृश्य निष्पादन बाउंड कंटेक्स्ट, 3 - यूआई -2 और 3 के लिए मॉडल पढ़ें 1. और सभी 3 की अपनी दृढ़ता तंत्र है? धन्यवाद - कान। – KaanK

+0

संक्षिप्त उत्तर: हां। 3 अलग-अलग मॉडल जो विभिन्न उद्देश्यों को पूरा करते हैं। बस बुलेट काट लें। –

0

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

संक्षेप में, एक प्रश्न एक प्रश्न है, भले ही इसका जवाब खोजने का कार्य कितना जटिल हो।

संबंधित मुद्दे