क्या मुझे एक कमांड या एक घटना का उपयोग करना चाहिए?


14

एक आदेश और बस संचार में एक घटना के बीच का अंतर मुझे थोड़ा अस्पष्ट लगता है। मुझे पता है कि आदेशों को केवल एक बार निष्पादित किया जाना चाहिए, जबकि एक घटना को कई बार नियंत्रित किया जा सकता है, लेकिन फिर भी मुझे यकीन नहीं है कि कमांड या किसी घटना का उपयोग कब करना है।

आइए एक उदाहरण देखें:

जब कोई नया उपयोगकर्ता किसी वेब एप्लिकेशन पर पंजीकरण करता है, तो हमें उसे एक खाता बनाना चाहिए और एक पुष्टिकरण ईमेल भेजना चाहिए।

खाता बनाना - यह CreateUserCommandबस को भेजने और एक विशेष घटक को संभालने के लिए सही जगह है।

या शायद यह भी एक अतुल्यकालिक बस संचार के साथ लागू नहीं किया जाना चाहिए? हम चाहते हैं कि उपयोगकर्ता अभी तुरंत एप्लिकेशन में लॉग इन कर सके। बस के साथ हमें कोई गारंटी नहीं है कि कमांड कब निष्पादित की जाएगी।

ईमेल भेजना - घटक बनाने के बाद खाता मैं 2 संभावनाएं देख सकता हूं

  1. बस में एक और कमांड भेजें SendConfirmationEmailCommand
  2. एक घटना प्रकाशित करें UserAccountCreatedEvent

और ईमेल भेजने वाले घटक को इसे हड़पने और काम करने देने की तुलना में।

एक तरफ मैं चाहता हूं कि पुष्टिकरण ईमेल केवल एक बार भेजा जाए (एक कमांड का उपयोग करें), दूसरी ओर, मेरा मानना ​​है कि नए पंजीकृत उपयोगकर्ताओं में रुचि रखने वाले कई घटक हो सकते हैं। एक लकड़हारा या शायद एक एसएमएस भेजने वाला।

आप इसे कैसे लागू करेंगे?

जवाबों:


16

सिद्धांत रूप में, एक आदेश एक अनुरोध का वर्णन करता है जिसे निष्पादित किया जाना है, जबकि एक घटना कुछ ऐसा वर्णन करती है जो हुआ है:

  • एक कमांड को एक प्रोसेसर द्वारा निष्पादित करने के लिए कुछ कार्रवाई की आवश्यकता होती है, और यह कार्रवाई केवल एक बार इस प्रोसेसर द्वारा की जानी चाहिए।

  • एक घटना कुछ कार्रवाई की अधिसूचना है जिसे पहले से ही निष्पादित किया गया था या एक बाहरी घटना थी। घटना के बारे में जानने के लिए कई प्रोसेसर / एजेंट दिलचस्पी ले सकते हैं। उनमें से कई आगे इस अधिसूचना द्वारा अपनी जिम्मेदारी के क्षेत्र में आदेश या कार्रवाई जारी कर सकते हैं।

आपके परिदृश्य में, मैं समझता हूँ कि:

  • CreateUserCommand एक आदेश है
  • UserAccountCreatedEventएक ऐसी घटना CreateUserCommandहै जिसे खाता प्रबंधन सेवा द्वारा सफलतापूर्वक पूरा किए जाने पर जारी किया जाना चाहिए

अब दो संभावनाएँ हैं:

  1. खाता प्रबंधन सेवा स्वयं SendConfirmationEmailCommandको बस में जारी करती है, क्योंकि यह अपेक्षा करती है कि यह आदेश एक अधिक विशिष्ट सेवा द्वारा निष्पादित किया जाएगा।
  2. खाता प्रबंधन सेवा पूरी होने पर घटना की सूचना भेजने से ज्यादा कुछ नहीं करती है, और किसी अन्य सेवा (जैसे संचार सेवा, सदस्यता सेवा, आदि ...) को ईमेल या एसएमएस / आदि ... या नहीं पर निर्णय छोड़ देती है। SendConfirmationEmailCommandकुछ गेटवे द्वारा निष्पादित करने के लिए एक कमांड जारी करने के लिए आवश्यक है ।

यदि आपने सेवा बस दृष्टिकोण का विकल्प चुना है, तो यह लचीलेपन का उपयोग करने के लिए समझ में आता है जो कि अनुमति देता है, अर्थात विकल्प 2 का पक्ष लें।


धन्यवाद, इससे चीजें साफ हो जाती हैं। विकल्प 2 के बारे में दो और प्रश्न: 1. खाता प्रबंधन सेवा को कमांड के पूरा होने के बारे में कैसे पता चलेगा? मेरा मानना ​​है कि यह विशिष्ट सेवाओं द्वारा अपने कार्यों के पूरा होने पर प्रकाशित घटनाओं को सुनकर है - खाता प्रबंधन सेवा का वास्तविक उद्देश्य क्या है? घटनाओं को पुनः प्रकाशित करने के लिए? यह बेमानी लगता है। 2. मुझे यह भी समझ नहीं आया कि SendConfirmationEmailCommand जारी करने वाला कौन है। खाता प्रबंधन सेवा या "दूसरी सेवा"?
एंड्रीज जीस

1) मेरी धारणा यह थी कि खाता प्रबंधन सेवा ने स्वयं काम किया और जब इसकी समाप्ति सफलतापूर्वक हुई (यानी कोई त्रुटि नहीं हुई) तो ईवेंट भेजें। लेकिन आप सही हैं: यह संभव है कि खाता प्रबंधन सेवा स्वयं को एक दृढ़ता / डेटाबेस सेवा के लिए आदेश भेजती है और उसे कार्य पूरा होने की घटना (जैसे एक अतुल्य उत्तर) की निगरानी करनी है।
क्रिस्टोफ

@gisek 2) एक सेवा बस में, मुझे लगता है कि आपके पास बहुत ही विशिष्ट सेवाएं हैं, जिनमें से प्रत्येक की जिम्मेदारी सीमित है। इस मामले में खाता प्रबंधन केवल निर्माण करता है और यह सूचित करता है कि जो भी रुचि रखता है वह पूरा हो गया है। कुछ अन्य सेवा तब प्रतिक्रिया करने के लिए चीजों की निगरानी करेगी। उदाहरण के लिए, आपके पास एक संचार प्रबंधक हो सकता है, जो उपयोगकर्ताओं को घटनाओं को कब और कैसे संवाद करने के लिए तय करने के लिए व्यावसायिक नियमों को लागू करने के लिए प्रभारी होगा। यदि आप एक ही सेवा में 1) +2) करते हैं, तो आपको शायद ही बस सेवा की आवश्यकता होगी।
क्रिस्टोफ़
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.