"नियंत्रण का उलटा" क्या "एनीमिक डोमेन मॉडल" को बढ़ावा देता है?

Question

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

मैंने अन्य डेवलपर्स द्वारा लिखी गई परियोजनाओं को देखा है जो "इनवर्टर ऑफ कंट्रोल" का उपयोग करते हैं और वे हमेशा "एनीमिक" होते हैं।

चूंकि "एनीमिक डोमेन मॉडल" पैटर्न-विरोधी है, क्या आईओसी और रिच डोमेन का उपयोग करना संभव है? क्या उनके कोई अच्छे उदाहरण हैं, ओपन सोर्स प्रोजेक्ट जो ऐसा करते हैं?

Comments

मुझे लगता है कि हमें मदद करने के लिए आपके विशेष मामले के कुछ विशिष्ट उदाहरण देखने की आवश्यकता होगी।

— मार्टिज़न वेरबर्ग

क्षमा करें, मेरा मतलब था कोड स्निपेट :)

— मार्टिज़न वेरबर्ग

Answer 1

शुरुआत के लिए: DI और IoC समानार्थी नहीं हैं। मुझे खेद है, लेकिन मुझे कहना होगा कि यह (मुझे लगता है कि आपको लगता है कि वे हैं)।

आपकी जांच के लिए ... खैर, डिपेंडेंसी इंजेक्शन सिर्फ एक उपकरण है। आप इस उपकरण का उपयोग कैसे करने जा रहे हैं यह पूरी तरह से अलग चीज है। अन्य उपकरण (डिज़ाइन पैटर्न) भी हैं जो समस्या को जोड़ सकते हैं। उदाहरण के लिए, मुझे लगता है कि एमवीसी पैटर्न को व्यापक रूप से अपनाना एनीमिक डोमेन मॉडल विरोधी पैटर्न बनाने के लिए एक महत्वपूर्ण घटक है: नियंत्रक (सरल अनुप्रयोगों में, अधिक जटिल वाले जो अतिरिक्त सेवा लेयर होंगे) वैध व्यावसायिक नियमों के लिए जिम्मेदारी लेते हैं , उन्हें लागू करने के साथ-साथ डीबी संस्थाओं को कुछ उपयोगी में बदलना, जबकि बिजनेस लेयर सरल डेटा एक्सेस लेयर में बदल जाता है जो डेटाबेस संस्थाओं के लिए एक-से-एक मैपिंग के साथ सादे ओआरएम है।

निश्चित रूप से यह है कि आप अपने एप्लिकेशन को कैसे डिज़ाइन करते हैं - यदि आप चाहें तो एक सही डोमेन मॉडल बना सकते हैं, और ये सभी IoC, DI, MVC आपको रोकते नहीं हैं। आप अपनी टीम को क्या रोक सकते थे। आपको किसी तरह सही रास्ते का उपयोग करने के लिए उन्हें समझाने की जरूरत है और यह कठिन हो सकता है क्योंकि कई सॉफ्टवेयर डेवलपर्स के पास मजबूत वास्तु पृष्ठभूमि नहीं है।

Comments

मैं इसे जोड़ दूंगा कि शायद आप एरिक इवांस और अन्य द्वारा डीडीडी दृष्टिकोण पर एक नज़र डाल सकते हैं।

— मार्टिज़न वर्बर्ग

मैंने एरिक इवांस की किताब पढ़ी। यह सामान्य कार्यप्रणाली और सर्वव्यापी भाषा के लिए अच्छा है, लेकिन वास्तविक दुनिया के उदाहरणों में कुछ कमी है।

— Mag20

डि और IoC के बीच अंतर को इंगित करने के लिए धन्यवाद। मुझे लगता है कि इस मुद्दे को आईओसी के साथ अधिक करना था फिर डीआई। यह प्रतिबिंबित करने के लिए प्रश्न को बदल दिया।

— मैग् 20

डि चौखटे / कंटेनर (स्प्रिंग डि, CDI, एकता) के साथ मेरा अनुभव में, वे वास्तव में करते हैं तो आप एक "सही डोमेन मॉडल" है, जो मुझे लगता है कि डेवलपर्स सच (यानी, स्टेटफुल) वस्तुओं का उपयोग करने से विवश नहीं किया जाना चाहिए मतलब है बनाने से रोक । लेकिन DI वास्तव में इसका समर्थन नहीं करता है।

— रोजेरियो

Answer 2

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

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

संस्थाएं राज्य का भंडारण कर रही हैं और उन्हें व्यावसायिक नियमों के लिए जिम्मेदार होना चाहिए। यदि आपकी सेवाएँ सभी आक्रमणकारियों और अन्य व्यावसायिक नियमों को लागू कर रही हैं, तो संभावना है कि तर्क गलत जगह पर है।

अब अगर आपको सही स्थानों पर तर्क मिल गया है और अभी भी ऐसी सेवाओं के साथ समाप्त हो गया है जो बुनियादी ढांचे की चीजों और संस्थाओं के आसपास रैपर से ज्यादा नहीं हैं जो कि सिर्फ संपत्ति बैग हैं तो यह बहुत संभावना है कि डोमेन पर्याप्त नहीं है अपने स्वयं के मॉडल के उपरि। डीडीडी के बारे में आपके द्वारा पढ़ी गई किसी भी चीज़ के बारे में एक अस्वीकरण होगा जो वास्तव में केवल जटिल डोमेन के लिए अभिप्रेत है, लेकिन ऐसा लगता है कि सभी अक्सर भूल गए हैं।

Answer 3

स्रोत पर जाएं एनीमिक डोमेन मॉडल पर फाउलर के टुकड़े से शुरू करें । वह एरिक इवान के डोमेन ड्रिवेन डिज़ाइन को अच्छे अभ्यास के उदाहरण के रूप में संदर्भित करता है। उसके लिए स्रोत कोड यहाँ है । डाउनलोड करो।

निरीक्षण करें कि यह नियंत्रण के व्युत्क्रम (@Autowired के लिए खोज) का उपयोग करता है, और इसमें सेवा वर्ग (BookingService), और "व्यवसाय प्रक्रिया" कक्षाएं (जैसे ItineraryUpdater) हैं।

फाउलर का मूल लेख आपके द्वारा खोजे जा रहे उदाहरण के निशान को शुरू करता है।

Comments

वह नमूना ऐप, वास्तव में, पुस्तक में वर्णित अनुसार DDD के अनुसार नहीं है। पुस्तक के साथ एक विशिष्ट विरोधाभास यह है कि यह पूरी तरह से "बुनियादी ढांचे" की अवधारणा का उल्लंघन करता है, इसे डोमेन-विशिष्ट कोड को शामिल करने की अनुमति देता है; उदाहरण के लिए, VoyageRepositoryHibernateवर्ग, जिसे बुनियादी ढांचे की परत में रखा गया था, लेकिन वास्तव में डोमेन परत पर निर्भर करता है।

— रोजेरियो

हां, पुस्तक पृष्ठ 73 पर कहती है कि बुनियादी ढांचा परत "डोमेन परत" के नीचे है और "इसे उस डोमेन के बारे में कोई विशेष ज्ञान नहीं होना चाहिए जो यह सेवा कर रहा है"। यह सिर्फ मेरे लिए कभी समझ में नहीं आया। एक ऐसी परियोजना पर विचार करें जिसमें दो वॉयोरेज रिपॉजिटरी कार्यान्वयन हों: वॉयोरेज रिपोजिटरी हाइबरनेट और एक वॉयराज रिपोजिटरी जेडडीबीसी वर्ग। उनका कार्यान्वयन आवश्यक रूप से बहुत अलग है, और प्रौद्योगिकी विशिष्ट है। क्या ये डोमेन लेयर में हैं? या बुनियादी ढांचे की परत? हमारे कोड में, पुस्तक के अनुसार, हम इसे पीछे की ओर करते हैं: बुनियादी ढांचे की परत डोमेन परत को संदर्भित कर सकती है, लेकिन इसके विपरीत नहीं।

— जेमी

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

— रोजेरियो

मेरे लिए, सेव (MyDomainObject foo) का कार्यान्वयन विशुद्ध रूप से तकनीकी चिंता है। YMMV।

— जेमी

केवल अगर यह आपको स्तरित वास्तुकला के मूल नियम का उल्लंघन करने के लिए नेतृत्व नहीं करता है: एक निचली परत एक उच्च परत पर निर्भर नहीं कर सकती है । इसलिए, यदि आप save(foo)उस कोड के साथ कार्यान्वित होते हैं जो डोमेन मॉडल में परिवर्तन के अधीन होता है (उदाहरण के लिए, यदि कोई नई विशेषता जोड़ी जाती है MyDomainObject), तो यह डोमेन परत से संबंधित (परिभाषा के अनुसार) होना चाहिए; अन्यथा, आप अभी "लेयर्स" के बारे में बात नहीं कर सकते।

— रोजेरियो

Answer 4

क्या IoC और रिच डोमेन का उपयोग करना संभव है? क्या उनके कोई अच्छे उदाहरण हैं, ओपन सोर्स प्रोजेक्ट जो ऐसा करते हैं?

मुझे लगता है कि आप Io के बजाय DI का मतलब है, और जिस परियोजना पर आपने काम किया है वह स्प्रिंग जैसे DI कंटेनर का उपयोग करती है। IoC के दो मुख्य स्वाद हैं: DI और लोकेटर पैटर्न। मैं यह नहीं देखता कि लोकेटर पैटर्न की समस्या क्यों होनी चाहिए, इसलिए आइए DI पर ध्यान केंद्रित करें।

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

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

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

Comments

जब यह रिच डोमेन मॉडल और डिपेंडेंसी इंजेक्शन के बीच तनाव की बात आती है तो यह जवाब वास्तव में सिर पर कील ठोकता है।

— जराहली