2010-12-15 23 views
11

मेरी टीम ग्रीनफील्ड आवेदन के कार्यान्वयन की शुरुआत है, बहु किरायेदारी के लिए एक आवश्यकता के साथ। मैं सरल स्केलेबिलिटी के लिए पैटर्न पर बड़ी मात्रा में शोध कर रहा हूं, खासतौर पर वितरित क्लाउड-आधारित आधारभूत संरचना पर, और सीक्यूआरएस buzzword du jour (अब तक "आर्किटेक्चर एडिक्ट्स के लिए क्रैक" कहलाता है, जिसे मुझे काफी मजेदार लगता है)। फायदे और नुकसान अलग-अलग हैं, ग्रेग यंग के अलावा किसी को भी ढूंढना मुश्किल है जिसने इस विचार का उत्पादन उत्पादन ऐप्स में बड़े पैमाने पर (या बिल्कुल) किया है और इसके लिए वास्तविक दुनिया मार्गदर्शन प्रदान कर सकता है।बहु किरायेदार CQRS वास्तुकला

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

संदर्भ के लिए, आवेदन नेट में लिखा जाएगा, और सामने के छोर शुरू में वेब आधारित (ASP.NET MVC), संभवतः मोबाइल और मोटी ग्राहकों को बढ़ाया जा रहा हो जाएगा। समेकन, लेनदेन संबंधी गतिविधि, और डेटा वॉल्यूम सभी आवेदन के जीवनकाल में अपेक्षाकृत कम रहने की उम्मीद है (उच्च मात्रा वित्तीय ऐप्स और इसी तरह की तुलना में)। बुनियादी ढांचे के लिए, हम Azure का उपयोग करने की योजना बना रहे हैं।

+0

(इसे एक टिप्पणी के रूप में सबमिट करना कोई जवाब नहीं है क्योंकि यह वास्तव में आपके प्रश्न के विनिर्देशों को संबोधित नहीं करता है) यदि आप पहले से नहीं हैं, तो मैं सुझाव देता हूं कि यहां उडी के सीक्यूआरएस स्पष्टीकृत आलेख को पढ़ा जाए: http: // www.udidahan.com/2009/12/09/clarified-cqrs/ और यहां पर उसका वीडियो देख रहे हैं: http://skillsmatter.com/podcast/open-source-dot-net/udi-dahan-command-query- जिम्मेदारी-पृथक्करण/आरएल -311 –

+2

विशेष रूप से .NET Azure CQRS के लिए http://abdullin.com/ और लोकड प्रोजेक्ट http://code.google.com/p/lokad-cqrs/ –

+0

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

उत्तर

6

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

2

मुझे नहीं लगता कि बहु-टेनेंट किसी भी कठिन/आसान CQRS का उपयोग कर रहा है। यदि आप मैसेजिंग का उपयोग करते हैं तो आपके पास कई फायदे हैं: आप हेडर डेटा के रूप में आदेशों और घटनाओं में किरायेदार पहचान एम्बेड कर सकते हैं, पहचान के आधार पर एक ईवेंटस्टोर का चयन कर सकते हैं, बहु-किरायेदार को बहु-उदाहरण के साथ जोड़ सकते हैं। फिर भी, अपने आप से पूछना है कि आपके डोमेन अत्यधिक सहयोगी है और अपने निपटान में एक डोमेन विशेषज्ञ है ... अन्यथा आप आदेश/घटना-CUD ;-)

7
  1. बहु किरायेदारी थोड़ा CQRS पक्ष पढ़ने बदल जाएगा साथ खत्म । आपको विचारों को फ़िल्टर करने और केवल किरायेदार से संबंधित डेटा लौटने की आवश्यकता होगी। और आप किसी भी अन्य वास्तुकला का उपयोग कर एक ही समस्या का सामना करेंगे।
  2. मैं CQRS की सलाह देते हैं, क्योंकि यह आपके आवेदन एक कार्य-आधारित (एक CRUD आधारित नहीं) कर देगा होगा। इसका मतलब है कि आपके पास यूआई से प्राप्त आदेश होंगे और वे डीटीओ से अधिक सार्थक होंगे। यदि आप डीडीडी सिद्धांतों के साथ अपना कोर लिखना चाहते हैं तो एनीमिक डोमेन मॉडल (http://martinfowler.com/bliki/AnemicDomainModel.html) से बचने का प्रयास करें। ऐसा करने के लिए दृष्टिकोण - डोमेन ऑब्जेक्ट्स पर सभी डोमेन-विशिष्ट तर्क को स्थानांतरित करें। आपके कमांड हैंडलर को बहुत सरल होना चाहिए (प्रमाणित करें, कुल रूट लोड करें, विधि कॉल पर कमांड ऑब्जेक्ट का अनुवाद करें, अगर कोई अपवाद नहीं फेंक दिया गया है - परिवर्तन लागू करें)। यह ग्रेग के वर्ग रिकॉर्ड (6 घंटे और एक आधा) को देखने के लिए योग्य है: http://cqrsinfo.com/video/ ने माइकल को Shimmins कहा कि अगर आप अपने मंच के रूप में Azure उपयोग करने की योजना - यह Lokad.CQRS परियोजना को देखने के लिए लायक है। मैंने इसे हमारी परियोजनाओं में से एक को लागू करने के लिए उपयोग किया।
  3. यदि आपको वास्तव में सरल सीआरयूडी आवेदन (कार्य-आधारित नहीं) की आवश्यकता है तो सीक्यूआरएस फिट नहीं होगा। सीक्यूआरएस को नए आने वालों के सिद्धांतों को समझने के लिए अधिक समय की आवश्यकता होती है। दूसरी ओर यह डोमेन-कोर प्रोग्रामर और कम अनुभवी दृश्य-> dto-> UI प्रोग्रामर के बीच dev कार्यों को अलग करने की अनुमति देगा।
संबंधित मुद्दे