मैं एक और अधिक लचीला डोमेन मॉडल जहां डाटा और व्यवहार का एक जुदाई है के लिए देख रहा हूँ, लेकिन मैं नहीं मानता कि सेवा परत व्यवहार के लिए उपयुक्त परत है । इसके बजाए, शायद, कोई साधारण बिजनेस लॉजिक लेयर दृष्टिकोण ले सकता है जहां बिजनेस एंटिटी ऑब्जेक्ट्स केवल डेटा का खुलासा करते हैं और बिजनेस प्रोसेस ऑब्जेक्ट्स केवल व्यवहार का पर्दाफाश करते हैं, और उन व्यवहारों में सत्यापन विधियां होती हैं।
एक लाभ, व्यापार प्रक्रिया युग्मन कितना ढीला है, इस पर निर्भर करता है कि आप कॉन्वर्स और व्यापक रूप से यहां तक कि परिवर्तनीय प्रकारों की विस्तृत श्रृंखला के सत्यापन को लागू कर सकते हैं।"फर्स्टनाम" और "लास्टनाम" फ़ील्ड को मान्य करने के लिए एक पल के लिए विचार करें, और आगे विचार करें कि ये फ़ील्ड किसी भी बड़े सिस्टम में आधे दर्जन या उससे अधिक विभिन्न इकाइयों पर मौजूद हो सकती हैं। डेटा से अलग प्रक्रिया सुनिश्चित करने के लिए आप एक बार अपनी सत्यापन प्रक्रियाओं को लागू कर सकते हैं और उन्हें कई ऑब्जेक्ट्स पर लागू कर सकते हैं जो समान डेटा प्रदान करते हैं।
मैंने देखा है कि डोमेन मॉडल 'डोमेन होना चाहिए' डोमेन ऑब्जेक्ट्स जो कि डेटा और व्यवहार दोनों का संलयन है, फॉउलर/इवांस की एक अवधारणा है, लगभग 2000-2002 (शीघ्रता से एक तेज़ माइग्रेशन के बाद) 2-स्तरीय अनुप्रयोगों के बजाय वितरित सूचना प्रणाली की ओर।)
विचार?
स्रोत
2012-07-12 11:13:53
मैं यह भी जोड़ूंगा कि समन्वय करने के लिए कुछ व्यावसायिक वस्तुएं भी मौजूद हो सकती हैं। उदाहरण के लिए, आप एक चालान में ऑर्डर बदलने के लिए आवश्यक व्यवहार नहीं लिखेंगे, आपके पास ऑर्डर कनवर्टर होगा जो ऑर्डर की जांच करेगा और यदि वैल्यूड इसे कन्वर्ट करेगा। जो मैं आम तौर पर "सेवा" वस्तुओं के रूप में देखता हूं वे मूल रूप से मुश्किल से संबंधित तरीकों का डंपिंग ग्राउंड होते हैं। वे सब एक दुकान में कुछ करते हैं, लेकिन इसके अलावा अन्य संबंधित नहीं हैं। सीएसएलए में इन तरीकों को आम तौर पर अलग-अलग वर्गों में शामिल किया जाएगा, जिनके पास उपयोग के बारे में पूर्ण ज्ञान है, यह एक चालान आदेश कैसे करें, इस बारे में सबकुछ जानता है – Andy