DDD में, सत्यापन एप्लिकेशन लॉजिक या डोमेन लॉजिक है?


26

मान लीजिए कि हम DDD का उपयोग करके एक फॉर्म का निर्माण कर रहे हैं; प्रपत्र में कुछ प्रकार के व्यावसायिक नियम जुड़े हो सकते हैं - शायद आपको एक छात्र नहीं होने पर आय को निर्दिष्ट करने की आवश्यकता होगी, और आपको अपने बच्चों को सूचीबद्ध करने की आवश्यकता है यदि आप इंगित करते हैं कि आप शादीशुदा हैं। और यदि आपने एक देश निर्दिष्ट किया है, तो उसके पास एक वैध देश होना चाहिए।

क्या इस तरह का सत्यापन डोमेन या एप्लिकेशन परत में रहता है? कुछ अन्य मुद्दों पर मैं विचार कर रहा था:

  • कुछ चौखटे, जैसे कि लारवेल, सत्यापन नियम प्रदान करता है जो नियंत्रक के अनुरोध से पहले इनपुट को मान्य कर सकता है। अगर उस स्तर पर सत्यापन किया जाता है तो क्या यह डीडीडी को तोड़ देता है?

  • यह निर्धारित करने जैसे मामलों के लिए कि क्या देश वैध है, आमतौर पर मैं दुनिया के सभी देशों की एक डेटाबेस तालिका को क्वेरी करूंगा। हालाँकि, DDD में, यह (मेरी समझ से) डोमेन लेयर पर होने की संभावना है। क्या डोमेन परत को DB तक पहुंचने की अनुमति है, या मुझे वैध देश का निर्धारण करने के लिए गैर-SQL खोज का उपयोग करना चाहिए?

  • क्या आवेदन और डोमेन परत दोनों पर इनपुट को मान्य करना आवश्यक है?


6
आप सवाल उठाते हैं कि हमेशा एक होता है, सबकुछ डालने के लिए सही जगह। वहाँ नहीं है
रॉबर्ट हार्वे

1
@RobertHarvey क्या कहते हैं। सत्यापन हमेशा "आवेदन" (आवेदन का मॉडल हिस्सा नहीं है) द्वारा किसी भी सत्यापन की परवाह किए बिना, मॉडल पर होना चाहिए। "एप्लिकेशन" में कोई भी सत्यापन केवल मॉडल के सत्यापन की पुनरावृत्ति होना चाहिए - यूआई की जवाबदेही को बढ़ाने के लिए, या केवल "एप्लिकेशन" तर्क (जैसे: ") से संबंधित होना चाहिए इस फॉर्म पर आप केवल दर्ज कर सकते हैं। .. ", लेकिन मैं इकाई सत्यापन मान रहा था)। डोमेन सत्यापन के लिए "एप्लिकेशन" परत पर कभी भरोसा न करें, हो सकता है कि यह जानकारी भेजने वाला आपका ग्राहक न हो ...
मार्जन वेनमा

जवाबों:


29

क्या इस तरह का सत्यापन डोमेन या एप्लिकेशन परत में रहता है?

आवेदन। आप चाहते हैं कि जादू खोज शब्द भ्रष्टाचार विरोधी परत है

आमतौर पर, आपके आवेदन द्वारा प्राप्त संदेश डीटीओ का कुछ स्वाद होगा। आपकी एंटी करप्शन लेयर आम तौर पर वैल्यू टाइप्स बनाएगी जो डोमेन को पहचानेगा। डोमेन मॉडल को भेजे गए वास्तविक आदेश को मान्य मूल्य प्रकारों के संदर्भ में व्यक्त किया जाएगा।

उदाहरण: डिपॉजिटमनी कमांड में एक राशि और एक मुद्रा प्रकार शामिल होगा। डीटीओ प्रतिनिधित्व शायद एक पूर्णांक के रूप में राशि और एक स्ट्रिंग के रूप में मुद्रा कोड को व्यक्त करेगा। एंटी करप्शन लेयर डीटीओ को डिपॉजिट वैल्यू टाइप में बदल देगा, जिसमें एक वेलिडेटेड अमाउंट (जो नॉन नेगेटिव होना चाहिए) और एक वैलिड करेंसीकोड (जो कि डोमेन में सपोर्टेड कोड में से एक होना चाहिए) शामिल होगा।

डोमेन मॉडल को समझने वाले प्रकार में कमांड को सफलतापूर्वक पार्स करने के बाद, कमांड को डोमेन में निष्पादित किया जाता है, जो अभी भी इस आधार पर कमांड को अस्वीकार कर सकता है कि यह व्यवसाय के अनौपचारिक उल्लंघन करेगा (खाता अभी तक मौजूद नहीं है, खाता अवरुद्ध है, इस विशेष खाते को उस मुद्रा का उपयोग करने की अनुमति नहीं है? आदि)।

दूसरे शब्दों में, एंटी-करप्शन परत के इनपुट की पुष्टि करने के बाद डोमेन मॉडल में व्यावसायिक सत्यापन होने जा रहा है।

सत्यापन नियमों का कार्यान्वयन आम तौर पर या तो मूल्य प्रकार के निर्माणकर्ता में, या मूल्य प्रकार के निर्माण के लिए उपयोग की जाने वाली फैक्टरी विधि के भीतर रहेगा। मूल रूप से, आप ऑब्जेक्ट्स के निर्माण को प्रतिबंधित करते हैं ताकि वे वैध होने की गारंटी दें, तर्क को एक स्थान पर अलग-थलग कर दें, और प्रक्रिया की सीमाओं पर इसे लागू करें।


आवेदन का उत्तर क्यों है? आपके पाठ के अनुसार औपचारिक सत्यापन डोमेन में या अनुप्रयोग और डोमेन में व्यावसायिक सत्यापन दोनों में किया जा सकता है।
inf3rno

@ inf3rno क्योंकि विशेष रूप से एक फॉर्म को मान्य करने के बारे में पूछे गए प्रश्न, जो डोमेन से संबंधित नहीं है
समय

1
इस जवाब का कोई मतलब नहीं है। डीडीडी के भ्रष्टाचार निरोधक परत एक अतिरिक्त कोड है जिसे आप बाहरी (किसी अन्य सिस्टम) डोमेन मॉडल और आपके डीडीडी-आधारित एप्लिकेशन के डोमेन मॉडल से / में अनुवाद करने के लिए लिखते हैं। यदि ऐसी कोई बाहरी व्यवस्था नहीं है, तो कोई भ्रष्टाचार-रोधी परत नहीं है। इसके अलावा, व्यावसायिक नियमों को मान्य करना डोमेन मॉडल (और डोमेन परत) में है, न कि अनुप्रयोग परत पर। डीटीओ के लिए, यह एक तकनीकी घटक है (एप्लिकेशन परत में) जो डीडीडी ऐप में मौजूद हो सकता है या नहीं भी। DTO और Entities / ValueObjects के बीच परिवर्तित करने का भ्रष्टाचार-विरोधी परतों से कोई लेना-देना नहीं है।
रोजरियो

5

आपकी समस्या डोमेन मॉडल में आपके डोमेन व्यवसाय नियम शामिल हैं। मॉडल के तत्वों पर व्यावसायिक नियम बाधा हैं। उनका मतलब है कि एक लिफ्ट दरवाजे के साथ नहीं चलती है, कि खराब होने वाला सामान एक गैर-प्रशीतित कंटेनर में लोड नहीं किया जाता है, और यह कि रद्द आदेश भेज नहीं दिया गया है।

इसका मतलब यह नहीं है कि जब आपका डोमेन मनुष्यों के साथ बातचीत करता है (स्क्रीन, फॉर्म आदि के माध्यम से) कि कोई सत्यापन या सहायता की आवश्यकता नहीं है। बस यह वैकल्पिक है।

इस बात पर विचार करें कि दो प्रकार के व्यावसायिक नियम हैं: - संपत्ति के नियम जो किसी वस्तु की विशेषताओं को बाधित करते हैं, और सहयोग के नियम जो वस्तुओं के बीच सहयोग को जोड़ने और हटाने में बाधा डालते हैं।

व्यावसायिक नियम तर्क नियमों से भिन्न होते हैं, जो आपकी प्रोग्रामिंग भाषा से संबंधित होते हैं और जांचते हैं कि मूल्यों की आपूर्ति की गई है और वे अशक्त नहीं हैं आदि।

नोट: आपके फॉर्म के "मॉडलिंग" के DDD में कोई अवधारणा नहीं है।


0

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

लेकिन थोड़ी समस्या है: मॉडल सत्यापन अक्सर बहुत देर से होता है। अक्सर, हम सत्यापन जल्दी करना चाहते हैं, इसलिए उपयोगकर्ता को बहुत लंबा इंतजार नहीं करना पड़ता है। यही कारण है कि सत्यापन अक्सर आवेदन तर्क में डाल दिया जाता है।

सत्यापन के संदर्भ में: अतिरिक्त डेटा के लिए क्वेरी करने में सक्षम होने की कोई समस्या नहीं है। लेकिन यह ध्यान नहीं देना चाहिए कि वे डेटा कहाँ से आते हैं। यह परवाह नहीं करता है कि यह SQL, फ़ाइल से आता है या केवल हार्ड-कोडित है। यही कारण है कि रिपॉजिटरी मौजूद हैं। डोमेन परिभाषित करता है कि उसे किस प्रकार की क्वेरी की आवश्यकता है और किसी और को कार्यान्वयन की देखभाल करने की अनुमति देता है।


-2

डोमेन परत में सभी सत्यापन तर्क शामिल होने चाहिए। प्रस्तुतीकरण, भ्रष्टाचार विरोधी परतें या अन्य आश्रित परतें इसे प्रतिबिंबित करना चाहिए।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.