डोमेन ईवेंट को कार्यान्वित करते समय ईवेंट हैंडलर को केवल डोमेन की चिंताओं के लिए उपयोग किया जाना चाहिए; कुछ ऐसा जो आप व्यवसाय विशेषज्ञों के साथ चर्चा करेंगे, या वे डोमेन मॉडल में रूचि रखने वाले किसी भी चीज़ द्वारा उपयोग किए जाने के लिए खुले हैं?डोमेन इवेंट हैंडलर - क्या उन्हें एप्लिकेशन परत चिंताओं के लिए उपयोग किया जाना चाहिए?
यह शायद एक साधारण उदाहरण के साथ सबसे अच्छा समझाया गया है, कर्मचारियों को काम शेड्यूल करने के लिए कैलेंडर आवेदन पर विचार करें।
हम निम्नलिखित डोमेन घटनाओं हो सकता है ...
AppointmentRemoved AppointmentContentChanged AppointmentMoved
हम इन घटनाओं के लिए संचालकों है, उदाहरण के लिए जब एक नियुक्ति कर्मचारियों के बाहर एक समय में ले जाया जाता AppointmentAdded कामकाजी घंटों हम एक चेतावनी झंडा सेट।
निश्चित रूप से ऐसी घटनाएं हैं जो इन घटनाओं में रुचि रखते हैं, उदा। जब कैलेंडर में नियुक्ति जोड़ा जाता है, तो हमें इसे कार्य इकाई में जोड़ना चाहिए ताकि हम बाद में परिवर्तन कर सकें।
क्या इन अनुप्रयोगों को डोमेन घटनाओं के उपभोक्ता होने चाहिए, या क्या हमें इसके बजाय अलग सिस्टम घटनाओं को उठाया जाना चाहिए?
मुझे संदेह है कि वे उसी लेनदेन में ईवेंट हैंडलिंग को बढ़ावा देते हैं, जो उस घटना को फायर कर रहे हैं। जैसा कि मुझे याद है कि उडी निर्दिष्ट करता है कि कुल लेनदेन को "आग लगाना और भूलना" बेहतर होता है, खासकर उन मामलों में जब ईवेंट हैंडलरों के पास डोमेन (पूर्व: ईमेल संदेश) से कोई लेना देना नहीं होता है। "आग और भूलने" का अर्थ है कि श्रोताओं को संदेश प्राप्त होने पर आपको परवाह नहीं है, लेकिन आपको किसी संदेश को आग लगाना चाहिए (संदेश भेजें)। कुल मिलाकर एक संदेश भेजें जब कुल मिलाकर यह काम खत्म हो गया है: राज्य परिवर्तन + दृढ़ता। इसलिए मैं दृढ़ता के बाद एक घटना को आग लगाने के लिए उत्सुक हूं। – Tudor
पीएस एक घटना को कुल मिलाकर किसी भी समय निकाल दिया जा सकता है, लेकिन वास्तविक संदेश वितरण को समग्र दृढ़ता के बाद संभाला जाना चाहिए (या एक विशिष्ट आदेश के बाद, जिसने घटना को ट्रिगर किया है, समाप्त हो गया है)। – Tudor