ऑडिट फ़ील्ड अपडेट करने के लिए कब? DDD

Question

मैं एक बैठक वस्तु है:

Meeting{id, name, time, CreatedBy, UpdatedBy}

और एक

MeetingAssignee{id, MeetingID, EmployeeId, CreatedBy, UpdatedBy)

बैठक, सकल रूट के रूप में, एक विधि AssignEmployee है।

मैं वर्तमान उपयोगकर्ता में मीटिंग ऑब्जेक्ट में पास होने वाला था क्योंकि मैं AssignEmployee को कॉल करता हूं, ताकि वह तदनुसार अपने ऑडिट फ़ील्ड अपडेट कर सके।

लेकिन यह सही नहीं लगता है - है ना? जाहिर है, मैं ऑडिट फ़ील्ड को सार्वजनिक रख सकता हूं और बाद में उन्हें बदल सकता हूं - शायद सेवा स्तर पर?

इन क्षेत्रों को अपडेट करने के लिए हर किसी की पसंदीदा विधि क्या है?

कृपया ध्यान दें: हम निबर्ननेट का उपयोग नहीं कर रहे हैं, लेकिन एक कस्टम ओआरएम जिसमें स्वचालित रूप से कुछ भी नहीं है।

धन्यवाद।

Answer 1

ऑडिटिंग और लॉगिंग मजेदार हैं क्योंकि उन्हें आमतौर पर एप्लिकेशन में हर जगह की आवश्यकता होती है और वे दोनों आवश्यकताएं हैं (लॉगिंग ओपीएस लोगों की आवश्यकता है)।

अपने मॉडल के ज्यादा जानने के बिना, और के बाद से लेखा परीक्षा एक आवश्यकता होना चाहिए, मैं वर्तमान उपयोगकर्ता AssignEmployee करने और इसके बजाय कि कहते हैं AuditBlahBlahBlah, मैं एक घटना (शायद MeetingUpdated या AssigneeAdded जोड़ना होगा एक लाइन वहाँ होने के पास होता .. आपको एक अच्छा नाम मिलेगा) और वह घटना उस कक्षा में भेजी जाती है जो लेखा परीक्षा करता है। इस तरह मीटिंग क्लास में लेखापरीक्षा उद्देश्यों के लिए ऑडिटिंग और प्रेषण व्यावसायिक घटनाओं के बारे में कोई जानकारी नहीं है (जो, मेरे विचार में, बहुत डीडीडीश है)।

मुझे आश्चर्य है कि दूसरे लोग क्या कह सकते हैं (उम्मीद, मैं कुछ नया सीख सकते हैं!)

Answer 2

आप संभवतः सेवा परत से लेखा परीक्षा सेवा के लिए कॉल कर सकते हैं जब बने या संस्थाओं को अद्यतन करने, लेखा परीक्षा सेवा के साथ किसी भी सेवा में इंजेक्शन दिया जा रहा है जिसके लिए लेखापरीक्षा कार्यक्षमता की आवश्यकता होती है, और जितनी जल्दी हो सके नव निर्मित इकाइयों को जारी रखती है।

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

मुझे दिलचस्पी होगी कि व्यापार-बंद क्या होगा।

Answer 3

डोमेन घटनाओं का उपयोग करने पर विचार करें।

आपके डोमेन मॉडल में जो कुछ भी दिलचस्प है, उसे जो कुछ हुआ है उसके बारे में चिल्लाते हुए एक घटना को उठाना चाहिए। बाहर से, बस लॉग हैंडलर संलग्न करें जो उन्हें डीबी या कहीं और डंप करता है।

इस तरह - आपको किसी प्रकार की IAuditService के साथ अपने डोमेन को गड़बड़ करने की आवश्यकता नहीं है।

यहां तक ​​कि बेहतर - डोमेन मॉडल ईवेंटिंग का उपयोग स्वयं के अंदर संवाद करने के तरीके के रूप में कर सकता है।
यह दिखाने के लिए कि यह एक अच्छा विचार क्यों है - कल्पना करें कि हम सुबह, सूर्योदय और फूलों के डोमेन मॉडल का वर्णन कर रहे हैं।

क्या सूर्य की ज़िम्मेदारी उन सभी फूलों को बताने के लिए है जो उन्हें खोलना चाहिए? ज़रुरी नहीं। सूर्य को केवल चमकदार रूप से चमकने की आवश्यकता है (एक घटना को बढ़ाने के लिए), प्रकाश को पृथ्वी पर यात्रा करना चाहिए (कुछ प्रकार का बुनियादी ढांचा होना चाहिए जो घटना को संभव बनाता है) और प्रकाश प्राप्त करने के दौरान फूलों को खुद को प्रतिक्रिया देनी चाहिए (अन्य डोमेन मॉडल घटनाओं को संभालना चाहिए)।

एक और समानता - यह देखने के लिए ड्राइवर की ज़िम्मेदारी है कि ट्रैफिक लाइट का रंग क्या है।