डीडीडी

Question

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

मान लें कि मैं एक काफी जटिल तीन परत अनुप्रयोग का निर्माण कर रहा हूं और मैं डीडीडी का उपयोग करना चाहता हूं। मेरा सवाल है, मुझे अपना व्यवसाय तर्क कहां रखना चाहिए? कुछ लोग कहते हैं कि इसे सेवाओं (सेवा परत) में रखा जाना चाहिए और यह समझ में आता है। एकल जिम्मेदारी सिद्धांत का पालन करने वाली कई सेवाएं होने से समझ में आता है।

हालांकि, कुछ लोगों ने कहा कि यह एक विरोधी पैटर्न है और सेवा तर्क में व्यावसायिक तर्क लागू नहीं किया जाना चाहिए। ऐसा क्यों है?

मान लें कि हमारे पास IAuthenticationService है जिसमें bool UsernameAvailable(string username) हस्ताक्षर के साथ एक विधि है। विधि यह सुनिश्चित करने के लिए सभी आवश्यक तर्क लागू करेगी कि उपयोगकर्ता नाम उपलब्ध है या नहीं।

"यह एक एंटीपेटर्न" भीड़ के अनुसार समस्या क्या है?

Answer 1

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

ऐसा करके आप एक वास्तविक एंटी-पैटर्न, एक एनीमिक डोमेन मॉडल के साथ समाप्त कर सकते हैं। मार्टिन फाउलर here द्वारा गहराई से चर्चा की गई है।

IAuthenticationService का आपका उदाहरण शायद समस्या पर चर्चा करने के लिए सबसे अच्छा नहीं है - प्रमाणीकरण के आसपास के अधिकांश तर्क को सेवा में रहने के रूप में देखा जा सकता है और वास्तव में डोमेन ऑब्जेक्ट्स से संबद्ध नहीं है। एक बेहतर उदाहरण हो सकता है यदि आपके पास उपयोगकर्ता को प्रमाणित करने के लिए किसी प्रकार की IUserValidationService थी, या यहां तक ​​कि ऐसी प्रक्रिया भी बदतर है जो प्रक्रिया आदेशों की तरह कुछ करता है - सत्यापन सेवा उपयोगकर्ता ऑब्जेक्ट से तर्क को अलग कर रही है और ऑर्डर प्रोसेसिंग सेवा तर्क से दूर है आपके ऑर्डर ऑब्जेक्ट्स, और संभावित रूप से ग्राहकों, डिलीवरी नोटिस आदि का प्रतिनिधित्व करने वाली वस्तुओं से भी ...

Answer 2

यदि आप अपने सभी व्यावसायिक तर्क को एक (अंतर्निहित स्टेटलेस) सेवा परत में डालते हैं तो आप प्रक्रियात्मक कोड लिख रहे हैं। डेटा से व्यवहार को कम करके, आप ऑब्जेक्ट उन्मुख कोड लिख रहे हैं।

यह हमेशा बुरा नहीं होता है: यह आसान है, और यदि आपके पास साधारण व्यापार तर्क है तो पूर्ण ऑब्जेक्ट उन्मुख domain model में निवेश करने का कोई कारण नहीं है।

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

Martin Fowler's article on Anemic Domain Models संभवतः समझने के लिए सबसे अच्छा प्रारंभिक बिंदु है (और किस परिस्थितियों में) लोग सेवा स्तर में व्यावसायिक तर्क डालने का विरोध करते हैं।