मुझे लगता है कि आपको इस मामले में दो प्रकार के सत्यापन को अलग करने की आवश्यकता है; डोमेन सत्यापन और आवेदन सत्यापन ।
आवेदन सत्यापन वह है जो आपके पास है जब आप यह सत्यापित करते हैं कि कमांड प्रॉपर्टी 'टेक्स्ट' 20 और 200 अक्षरों के बीच है; इसलिए आप इसे GUI के साथ और एक दृश्य-मॉडल-सत्यापनकर्ता के साथ मान्य करते हैं जो POST के बाद सर्वर पर भी निष्पादित होता है। वही ई-मेल (btw) के लिए जाता है, मुझे आशा है कि आप महसूस करेंगे कि `32.d +" Hello World .42 "@ mindomän.local जैसे ई-मेल RFC के अनुसार एक मान्य है)।
फिर आपके पास एक और सत्यापन है; जाँच करें कि लेख मौजूद है - आपको अपने आप से यह सवाल पूछना है कि लेख मौजूद नहीं होना चाहिए अगर वास्तव में जीयूआई से भेजा गया कमांड है जो इसके बारे में एक टिप्पणी संलग्न करने के बारे में है। क्या आपका GUI अंततः सुसंगत था और आपके पास एक मूल जड़, लेख है, जिसे डेटा स्टोर से भौतिक रूप से हटाया जा सकता है? उस स्थिति में आप कमांड को केवल त्रुटि कतार में ले जाते हैं क्योंकि कमांड हैंडलर कुल रूट को लोड करने में विफल रहता है।
उपरोक्त मामले में, आपके पास अवसंरचना होगी जो जहर संदेशों को संभालती है - वे उदाहरण के लिए संदेश को 1-5 बार पुन: प्रयास करेंगे और फिर इसे एक कविता कतार में ले जाएंगे जहां आप मैन्युअल रूप से संदेशों के संग्रह का निरीक्षण कर सकते हैं और उन प्रासंगिकों को फिर से भेज सकते हैं। निगरानी करना अच्छी बात है।
तो अब हमने चर्चा की है:
आवेदन सत्यापन
- जीयूआई में जावास्क्रिप्ट के साथ
- वेब सर्वर पर एमवीसी-मान्यता के साथ
अनुपलब्ध मूल + विष कतार
उन आदेशों के बारे में जो डोमेन के साथ सिंक से बाहर हैं? शायद आपके डोमेन तर्क में यह कहते हुए नियम है कि किसी लेख पर 5 टिप्पणियों के बाद, केवल 400 वर्णों से नीचे की टिप्पणियों की अनुमति है, लेकिन एक व्यक्ति को 5 वीं टिप्पणी के साथ बहुत देर हो गई और 6 वें स्थान पर पहुंच गया - GUI ने इसे नहीं पकड़ा क्योंकि यह उसके आदेश भेजने के बिंदु पर डोमेन के अनुरूप नहीं था - इस मामले में आपके डोमेन तर्क के एक हिस्से के रूप में आपको 'सत्यापन विफलता' है और आप इसी विफलता की घटना को वापस कर देंगे।
घटना एक संदेश ब्रोकर या आपके कस्टम डिस्पैचर पर एक संदेश के रूप में हो सकती है। वेब सर्वर, यदि एप्लिकेशन अखंड है, तो एक सफलता की घटना और उल्लेखित विफलता घटना दोनों के लिए समान रूप से सुन सकता है और उपयुक्त दृश्य / आंशिक प्रदर्शित कर सकता है।
अक्सर आपके पास कस्टम ईवेंट होता है जिसका अर्थ है कई प्रकार के कमांड के लिए विफलता, और यह वह घटना है जो आप वेब सर्वर के दृष्टिकोण से सदस्यता लेते हैं।
जिस सिस्टम पर हम काम कर रहे हैं, हम MassTransit + RabbitMQ संदेश बस + ब्रोकर पर आदेशों / घटनाओं के साथ अनुरोध-प्रतिक्रिया कर रहे हैं और हमारे पास इस विशेष डोमेन में एक ईवेंट है (नाम में एक वर्कफ़्लो मॉडलिंग) InvalidStateTransitionError। अधिकांश आदेश जो राज्य ग्राफ में बढ़त के साथ जाने की कोशिश करते हैं, इस घटना के कारण हो सकते हैं। हमारे मामले में, हम अंततः लगातार प्रतिमान के बाद जीयूआई को मॉडलिंग कर रहे हैं, और इसलिए हम उपयोगकर्ता को एक 'कमांड स्वीकार किए गए' पृष्ठ पर भेजते हैं और उसके बाद इवेंट सब्सक्रिप्शन के माध्यम से वेब सर्वर के विचारों को निष्क्रिय रूप से अपडेट करते हैं। यह उल्लेख किया जाना चाहिए कि हम समग्र जड़ों में भी घटना-सोर्सिंग कर रहे हैं (और साथ ही साथ साग के लिए भी करेंगे)।
तो आप देखते हैं, आप जिस सत्यापन की बात कर रहे हैं, वह वास्तव में अनुप्रयोग-प्रकार के सत्यापन हैं, वास्तविक डोमेन तर्क नहीं। यदि आपका डोमेन सरल है लेकिन आप DDD कर रहे हैं तो एक साधारण डोमेन मॉडल रखने में कोई समस्या नहीं है। जैसा कि आप अपने डोमेन को जारी रखते हैं, हालाँकि, आपको पता चलेगा कि डोमेन उतना सरल नहीं हो सकता जितना कि यह पहली बार निकला था। कई मामलों में कुल रूट / इकाई केवल एक कमांड के कारण होने वाले एक विधि आह्वान को स्वीकार कर सकती है और अपने राज्य में से कुछ को बिना किसी सत्यापन के भी बदल सकती है - खासकर यदि आप अपनी आज्ञाओं पर भरोसा करते हैं जैसे आप वेब सर्वर में उन्हें मान्य करते हैं तो आप क्या करेंगे आप नियंत्रित करते हैं।
मैं नार्वे डेवलपर कॉन्फ्रेंस 2011 से DDD पर दो प्रस्तुतियों और presentationredev 2010 में ग्रेग की प्रस्तुति को देखने की सिफारिश कर सकता हूं ।
चीयर्स, हेंके