मैं जानना चाहूंगा कि एनीमिक डोमेन मॉडल (नीचे लिंक देखें) का उपयोग करने के लिए पेशेवरों और विपक्ष क्या हैं।
मैं जानना चाहूंगा कि एनीमिक डोमेन मॉडल (नीचे लिंक देखें) का उपयोग करने के लिए पेशेवरों और विपक्ष क्या हैं।
जवाबों:
गुण:
विपक्ष:
"एनीमिक डोमेन मॉडल" के पैटर्न के विरोधी होने के कारण, इतनी सारी प्रणालियाँ क्यों हैं जो इसे लागू करती हैं?
मुझे लगता है कि इसके कई कारण हैं
1. प्रणाली की जटिलता
अगर मैं लागू करना चाहता हूं तो एक सरल प्रणाली में (जो लगभग सभी उदाहरण और नमूना कोड जो आप इंटरनेट पर पाते हैं):
ऑर्डर करने के लिए उत्पाद जोड़ना
मैंने यह फ़ंक्शन ऑर्डर पर रखा
public void Order.AddOrderLine(Product product)
{
OrderLines.Add(new OrderLine(product));
}
अच्छी और सुपर ऑब्जेक्ट ओरिएंटेड।
अब कहते हैं कि मुझे यह सुनिश्चित करने की आवश्यकता है कि उत्पाद को सूची में मौजूद है और यदि वह नहीं है तो अपवाद को फेंकने की आवश्यकता है।
मैं वास्तव में इसे किसी भी लंबे समय तक आदेश पर नहीं रख सकता, क्योंकि मैं नहीं चाहता कि मेरा आदेश इन्वेंटरी पर निर्भर हो, इसलिए अब इसे सेवा पर जाने की जरूरत है
public void OrderService.AddOrderLine(Order order, Product product)
{
if (!InventoryService.Has(product)
throw new AddProductException
order.AddOrderLine(product);
}
मैं IInventoryService को Order.AddOrderLine पर भी पारित कर सकता हूं, जो एक और विकल्प है, लेकिन फिर भी यह ऑर्डर को InventoryService पर निर्भर करता है।
ऑर्डर.एडऑडरलाइन में अभी भी कुछ कार्यक्षमता है, लेकिन आमतौर पर यह ऑर्डर स्कोप तक सीमित है, जबकि मेरे अनुभव में ऑर्डर स्कोप से बहुत अधिक बिजनेस लॉजिक है।
जब सिस्टम अधिक होता है, तो बस बुनियादी सीआरयूडी, आप ऑर्डरस् सेवा में अपने अधिकांश तर्क के साथ समाप्त हो जाएंगे और ऑर्डर में बहुत कम।
2. OOP के डेवलपर का दृष्टिकोण
इंटरनेट पर बहुत सारे गर्म विचार-विमर्श हैं जिनके बारे में तर्क संस्थाओं पर जाना चाहिए।
कुछ इस तरह
आदेश दें
ऑर्डर को पता होना चाहिए कि खुद को कैसे बचाया जाए या नहीं? मान लीजिए कि हमारे पास इसके लिए रिपॉजिटरी हैं।
अब आदेश आदेश लाइनें जोड़ सकते हैं? अगर मैं सरल अंग्रेजी का उपयोग करके इसका अर्थ निकालने की कोशिश करता हूं, तो यह वास्तव में समझ में नहीं आता है। उपयोगकर्ता ऑर्डर करने के लिए उत्पाद जोड़ता है, तो क्या हमें User.AddOrderLineToOrder () करना चाहिए? जो ओवरकिल की तरह लगता है।
ऑर्डरस् सेवा के बारे में कैसे। AddOrderLine ()। अब यह थोड़े समझ में आता है!
OOP के बारे में मेरी समझ यह है कि इनकैप्सुलेशन के लिए आप उन कक्षाओं पर कार्य करते हैं जहाँ फ़ंक्शन को कक्षा की आंतरिक स्थिति तक पहुँचने की आवश्यकता होगी। अगर मुझे ऑर्डर.ऑर्डरलाइन संग्रह का उपयोग करने की आवश्यकता है, तो मैं ऑर्डर पर ऑर्डर.एडऑर्डररलाइन () डाल देता हूं। इस तरह वर्ग की आंतरिक स्थिति उजागर नहीं होती है।
3. आईओसी कंटेनर
IoC कंटेनर का उपयोग करने वाले सिस्टम आमतौर पर पूरी तरह से एनीमिक होते हैं।
इसका कारण यह है कि आप अपनी सेवाओं / रिपॉजिटरी का परीक्षण कर सकते हैं जिनमें इंटरफेस हैं, लेकिन डोमेन ऑब्जेक्ट्स (आसानी से) का परीक्षण नहीं कर सकते, जब तक कि आप उन सभी पर इंटरफेस नहीं डालते।
चूंकि "IoC" वर्तमान में आपकी सभी प्रोग्रामिंग समस्याओं के समाधान के रूप में प्रशंसित है, बहुत सारे लोग नेत्रहीन रूप से इसका पालन करते हैं और इस तरह से एनीमिक डोमेन मॉडल समाप्त होता है।
4. OOP कठिन है, प्रक्रियात्मक आसान है
मेरे पास इस पर एक " ज्ञान का अभिशाप " है, लेकिन मुझे पता चला है कि डीटीओ और सेवाओं वाले नए डेवलपर्स रिच डोमेन की तुलना में बहुत आसान हैं।
संभवतः ऐसा इसलिए है क्योंकि रिच डोमेन के साथ यह जानना अधिक कठिन है कि तर्क को किस वर्ग में रखा जाए। नई कक्षाएं कब बनाएं? कौन से पैटर्न का उपयोग करें? आदि..
स्टेटलेस सेवाओं के साथ आप इसे निकटतम नाम के साथ सेवा में थप्पड़ मारते हैं।
इसके बाद, मेरे दिमाग में बहुत लंबे समय से एक विचार चल रहा है। यह मेरा विश्वास है कि "ओओपी" शब्द एक अर्थ पर लिया गया है जो वास्तव में इसके लिए अभिप्रेत नहीं है। विपर्यय का अर्थ है "वस्तु उन्मुख प्रोग्रामिंग", जैसा कि हम सभी जानते हैं। पाठ्यक्रम का फोकस "उन्मुख" शब्द पर है। यह "ओएमपी" नहीं है, जिसका अर्थ है "ऑब्जेक्ट अनिवार्य प्रोग्रामिंग"। एडीएम और आरडीएम दोनों ओओपी के उदाहरण हैं। वे वस्तु, गुण, विधियों के इंटरफेस और आगे का उपयोग करते हैं। हालाँकि, एडीएम और आरडीएम के बीच एक अंतर है कि हम चीजों को कैसे बदलना चाहते हैं। वे दो अलग चीजें हैं। यह कहना कि एडीएम खराब है ओओपी एक सटीक बयान नहीं है। हो सकता है कि हमें इसके बजाय अलग-अलग स्तरों के विभिन्न स्तरों के लिए अलग-अलग शब्दों की आवश्यकता हो। इसके अलावा, मुझे कभी भी एंटी-पैटर्न शब्द पसंद नहीं आया। यह आमतौर पर एक विरोधी समूह के सदस्यों द्वारा कुछ को सौंपा जाता है। एडीएम और आरडीएम दोनों वैध पैटर्न हैं, उनके पास सरल लक्ष्य हैं, जो विभिन्न लक्ष्यों को ध्यान में रखते हैं और विभिन्न व्यावसायिक आवश्यकताओं को हल करने के लिए हैं। हम में से जो लोग डीडीडी का अभ्यास करते हैं, उन्हें कम से कम, इसकी सराहना करनी चाहिए, और एडीएम को लागू करने के लिए चुनने वालों को कोसने से दूसरों के स्तर तक नहीं गिरना चाहिए। बस मेरे विचार।
"यह एक विरोधी पैटर्न है, इसलिए अन्य डेवलपर्स पूछेंगे कि क्या आप ऑब्जेक्ट ओरिएंटेड डिज़ाइन की अवधारणाओं को समझते हैं।"
"एनीमिक डोमेन मॉडल एक एंटी-पैटर्न है। एंटी-पैटर्न के पास कोई नियम नहीं है।"
क्या एनीमिक डोमेन मॉडल एक विरोधी पैटर्न है, यह एक राय का विषय है। मार्टिन फाउलर कहते हैं, यह कई डेवलपर्स हैं, जो बाहर ओओ को जानते हैं, ऐसा नहीं है। तथ्य के रूप में राय देना शायद ही मददगार है।
एक, भले ही इसे सार्वभौमिक रूप से एक विरोधी पैटर्न के रूप में स्वीकार किया गया था, संभावना है कि यह अभी भी कुछ (हालांकि अपेक्षाकृत कम) उल्टा होगा।
the chances are it would still have some (though relatively little) upside.तो कुछ नाम कृपया! परिकल्पना के बजाय कम से कम एक!
यह मुझे लगता है कि फाउलर की मुख्य आपत्ति यह है कि एडीएम निम्नलिखित अर्थों में ओओ नहीं हैं। यदि कोई निष्क्रिय डेटा संरचनाओं के चारों ओर "खरोंच से" एक प्रणाली को डिज़ाइन करता है जिसे कोड के अन्य टुकड़ों द्वारा हेरफेर किया जाता है, तो यह निश्चित रूप से ऑब्जेक्ट-ओरिएंटेड डिज़ाइन की तुलना में प्रक्रियात्मक डिज़ाइन की तरह महक देता है।
मेरा सुझाव है कि कम से कम दो बल हैं जो इस तरह के डिजाइन का उत्पादन कर सकते हैं:
डिजाइनर / प्रोग्रामर जो अभी भी सोचते हैं कि एक वस्तु-उन्मुख वातावरण में काम करने के लिए प्रक्रियात्मक रूप से आवश्यक है (या यह मानते हुए कि वे कर सकते हैं ...) एक नई प्रणाली का उत्पादन करने के लिए , और
गैर-ओओ फैशन (भाषा की परवाह किए बिना) में डिज़ाइन की गई विरासत प्रणाली पर सेवा-जैसा "चेहरा" डालने का काम करने वाले डेवलपर्स ।
यदि, उदाहरण के लिए, कोई मौजूदा COBOL मेनफ्रेम एप्लिकेशन की कार्यक्षमता को उजागर करने के लिए सेवाओं का एक सेट बना रहा था, तो कोई एक वैचारिक मॉडल के संदर्भ में सेवाओं और इंटरफेस को परिभाषित कर सकता है जो आंतरिक COBOL डेटा संरचनाओं को प्रतिबिंबित नहीं करता है । हालाँकि, यदि सेवा मौजूदा-लेकिन-छिपे हुए कार्यान्वयन का उपयोग करने के लिए नए मॉडल को विरासत डेटा में मैप करती है, तो नया मॉडल बहुत अच्छी तरह से फाउलर के लेख के अर्थ में "एनीमिक" हो सकता है - उदाहरण के लिए TransferObject- शैली परिभाषाओं का एक सेट। और कोई वास्तविक व्यवहार नहीं के साथ संबंध।
इस तरह का समझौता उन सीमाओं के लिए बहुत सामान्य हो सकता है, जिन पर आदर्श रूप से शुद्ध OO सिस्टम को मौजूदा, गैर-OO वातावरण के साथ बातचीत करनी चाहिए।
एनीमिक डोमेन मॉडल (एडीएम) एक अच्छा विकल्प हो सकता है यदि आपकी टीम एक अमीर डोमेन मॉडल (आरडीएम) बनाने में असमर्थ है या इसे समय के साथ बनाए रखने के लिए तैयार नहीं है। आरडीएम के साथ जीतने पर सिस्टम में उपयोग किए जाने वाले प्रमुख सार पर ध्यान देने की आवश्यकता होती है। चित्रा, किसी भी देव समूह में, आधे से अधिक नहीं और शायद इसके सदस्यों में से केवल दसवां हिस्सा गर्भपात के साथ सक्षम है। जब तक यह कैडर (शायद केवल एक ही डेवलपर) पूरे समूह की गतिविधियों पर प्रभाव बनाए रखने में सक्षम होता है, आरडीएम एन्ट्रापी का शिकार होगा।
और एन्ट्रापिक आरडीएम दर्द होता है, विशेष रूप से। इसके डेवलपर्स कठोर सबक सीखेंगे। सबसे पहले वे अपने हितधारकों की अपेक्षाओं को पूरा करने में सक्षम होंगे, क्योंकि उनके पास रहने के लिए कोई इतिहास नहीं होगा। लेकिन जैसा कि उनका सिस्टम अधिक जटिल हो जाता है (जटिल नहीं) यह भंगुर हो जाएगा; डेवलपर्स कोड का पुन: उपयोग करने की कोशिश करेंगे लेकिन विकास में नए कीड़े या पीछे ट्रैक करने के लिए प्रेरित करेंगे (और इस तरह उनके अनुमानों से आगे निकल गए)।
इसके विपरीत, ADM डेवलपर अपने लिए निम्न अपेक्षाएँ निर्धारित करेंगे, क्योंकि वे नई सुविधाओं के लिए अधिक कोड का पुन: उपयोग करने की अपेक्षा नहीं करेंगे। समय के साथ उनके पास कई विसंगतियों वाला एक सिस्टम होगा, लेकिन यह संभवतः अनपेक्षित रूप से नहीं टूटेगा। बाजार में उनका समय एक सफल आरडीएम की तुलना में लंबा होगा, लेकिन उनके हितधारकों को इस संभावना की संभावना नहीं है।
"एक गैर-ओओ फैशन (भाषा की परवाह किए बिना) में डिज़ाइन की गई विरासत प्रणाली पर" फेस "की तरह काम करने वाले डेवलपर्स।"
यदि आप कई एलओबी अनुप्रयोगों के बारे में सोचते हैं, तो ये विरासत सिस्टम अक्सर उसी डोमेन मॉडल का उपयोग नहीं करेंगे जैसा आप करते हैं। एनीमिक डोमेन मॉडल सेवा वर्गों में व्यावसायिक तर्क के उपयोग के साथ इसे हल करता है। आप यह सभी इंटरफ़ेस कोड अपने मॉडल (पारंपरिक OO अर्थ में) के अंदर रख सकते हैं - लेकिन आप आमतौर पर प्रतिरूपकता खो देते हैं।
जब मैं पहली बार एनीमिक डोमेन मॉडल लेख में आया था तो मैंने सोचा था कि "पवित्र एस ***, यही मैं करता हूं। डरावना!" मैं एक अच्छा उदाहरण बनने के लिए एरिक इवान की पुस्तक के संदर्भों पर कायम रहा और उसका अनुसरण किया, और स्रोत को डाउनलोड किया। यह पता चला है कि "एनीमिक डोमेन मॉडल का उपयोग नहीं करना" का अर्थ "सेवा वर्गों का उपयोग नहीं करना, मध्यस्थों का उपयोग नहीं करना, रणनीतियों का उपयोग नहीं करना" या यहां तक कि "वर्ग में हेरफेर किया जा रहा है" पर तर्क करना है।
DDD के उदाहरणों में सर्विस क्लासेस, XyzUpdaters, singletons और IoC हैं।
मैं वास्तव में एक एनीमिक डोमेन मॉडल से भ्रमित हूं। मुझे उम्मीद है "जब मैं इसे देखूंगा तो मुझे पता चल जाएगा"। अभी के लिए मैं अच्छे डिजाइन के सकारात्मक उदाहरण के साथ संतुष्ट हूं।
एक एडीएम के साथ 'परिपक्व' प्रणाली के साथ काम करने और मुझे लगता है कि मैं इस सवाल पर कुछ, कम से कम, महत्वपूर्ण प्रतिक्रिया प्रदान कर सकता हूं।
1) एनकैप्सुलेशन की कमी
एडीएम के साथ एक लाइव सिस्टम में लिखने की संभावना है जैसे 'obj.x = 100; obj.save ', भले ही यह व्यावसायिक तर्क का उल्लंघन करता हो। इससे कई कीड़े हो जाते हैं जिनका सामना नहीं किया जाता है यदि ऑब्जेक्ट पर इनवेरिएंट्स को मॉडल किया गया था। यह इन बगों की गंभीरता और व्यापकता है जो मुझे लगता है कि एक एडीएम के लिए सबसे गंभीर नकारात्मक है।
मुझे यहां यह बताना महत्वपूर्ण है कि यह वह जगह है जहां एक कार्यात्मक समाधान है, और एडीएम के प्रक्रियात्मक समाधान में काफी भिन्नता है और किसी भी समानता है कि दूसरों को एक एडीएम और कार्यात्मक समाधान के बीच सतह समानता के लिए तैयार किया जा सकता है आकस्मिक हैं।
2) कोड ब्लोट
मेरा अनुमान है कि ADM में उत्पादित कोड की मात्रा 5-10x है, जो OOP / RDM समाधान बनाता है। यह शायद 50% कोड पुनरावृत्ति, 30% बायलर प्लेट कोड और 20% होने वाली समस्याओं के समाधान या समाधान के लिए जिम्मेदार है जो एक आरडीएम की कमी से उत्पन्न होते हैं।
3) डोमेन की समस्याओं की खराब समझ
एक एडीएम और डोमेन की खराब समझ कुछ हद तक हाथ से जाती है। Naive समाधान उत्पन्न होते हैं, आवश्यकताओं को मौजूदा DM के साथ समर्थन करने की कठिनाई के कारण खराब माना जाता है, और ADM व्यवसाय के नवाचार के लिए एक महत्वपूर्ण अवरोध बन जाता है जिसे लंबे समय तक विकास और लचीलेपन की कमी दी जाती है।
4) रखरखाव की कठिनाई
यह सुनिश्चित करने के लिए कड़ाई के एक निश्चित स्तर की आवश्यकता है कि यह व्यक्त की गई सभी जगहों पर एक डोमेन अवधारणा बदल जाती है, यह देखते हुए कि अवधारणा सिर्फ कॉपी और पेस्ट-कार्यान्वयन नहीं हो सकती है। यह अक्सर एक ही कीड़े की जांच और कई मौकों पर तय होता है।
5) ऑन-बोर्डिंग के साथ बढ़ी हुई कठिनाई
मुझे लगता है कि आरडीएम के लाभों में से एक अवधारणा का सामंजस्य है जो डोमेन की तेज समझ की अनुमति देता है। एक ADM अवधारणाओं के साथ खंडित और स्पष्टता की कमी हो सकती है, इसलिए नए डेवलपर्स के लिए अधिग्रहण करना कठिन है।
मुझे एक एडीएम के लिए एक RDM से अधिक होने के लिए परिचालन समर्थन लागत को शामिल करने के लिए भी लुभाया गया था लेकिन यह कई कारकों पर निर्भर करेगा।
जैसा कि अन्य लोगों ने बताया है, आरडीएम के लाभों के लिए डीडीडी (ग्रेग इवांस, विंस वॉन और स्कॉट मिलेट) को देखें।
यह अधिकांश विरोधी प्रतिमानों के समान है: यह आपको बहुत से लोगों को लंबे समय तक व्यस्त रखने की अनुमति देता है। जब प्रबंधकों को अधिक भुगतान किया जाता है जब वे अधिक लोगों को प्रबंधित करते हैं, तो सुधार न करने के लिए एक मजबूत प्रोत्साहन होता है।
एरिक पी के जवाब के साथ-साथ ऊपर के कुछ अन्य लोगों ने जो लिखा है, ऐसा लगता है कि एडीएम का मुख्य नुकसान ओओडी का नुकसान है, विशेष रूप से एक डोमेन अवधारणा के तर्क और डेटा को एक साथ रखने के लिए ताकि कार्यान्वयन विवरण छिपा हो। एपीआई समृद्ध हो सकता है।
एरिक यह बताता है कि एक डोमेन वर्ग के बाहर अक्सर ऐसी जानकारी होती है जो उस वर्ग पर अभिनय करने के तर्क के लिए आवश्यक होती है, जैसे किसी आइटम को ऑर्डर में जोड़ने से पहले इन्वेंट्री की जांच करना। मैं सवाल करता हूं, हालांकि, क्या उत्तर एक सेवा परत है जो इस अतिव्यापी तर्क को रखती है, या क्या यह ऑब्जेक्ट डिज़ाइन के हिस्से के रूप में बेहतर रूप से संभाला जाता है। किसी को इन्वेंटरी ऑब्जेक्ट, प्रोडक्ट ऑब्जेक्ट और ऑर्डर ऑब्जेक्ट के बारे में जानना होगा। शायद यह केवल एक ऑर्डरसिस्टम ऑब्जेक्ट है, जिसमें एक इन्वेंटरी सदस्य, आदेशों की एक सूची और इसके आगे है। यह एक सेवा से बहुत अलग नहीं लगेगा, लेकिन मुझे लगता है कि यह वैचारिक रूप से अधिक सुसंगत है।
या इसे इस तरह से देखें: आपके पास आंतरिक क्रेडिट बैलेंस वाला एक उपयोगकर्ता हो सकता है, और हर बार जब User.addItemToOrder (आइटम) कहा जाता है, तो यह आइटम की कीमत प्राप्त करता है और इसे जोड़ने से पहले क्रेडिट की जांच करता है, आदि जो एक उचित OO लगता है। डिज़ाइन। मुझे यकीन नहीं है कि Service.addItemToUserOrder (उपयोगकर्ता, आइटम) के साथ प्रतिस्थापित करने से क्या खो गया है, लेकिन मुझे यकीन नहीं है कि क्या प्राप्त हुआ है, या तो। मुझे लगता है कि एक नुकसान कोड की अतिरिक्त परत होगी, साथ ही लेखन की क्लिंकर शैली और अंतर्निहित डोमेन मॉडल की लागू अज्ञानता होगी।
यह ध्यान दिया जाना चाहिए कि जैसे-जैसे प्रणालियां जटिलता की विविधता और विविधता में बढ़ती जाती हैं, एक अच्छी तरह से डिज़ाइन किए गए संदेश-पासिंग ऑब्जेक्ट मॉडल द्वारा वहन किए जाने वाले इंटरफ़ेस बिंदुओं का एनकैप्सुलेशन और समेकन व्यापक रूप से रिफैक्टरिंग के बिना महत्वपूर्ण कोड को बदलने और बनाए रखने के लिए अधिक सुरक्षित बनाता है।
एडीएम द्वारा बनाई गई सेवा परतें, निश्चित रूप से लागू करने में आसान हैं (क्योंकि उन्हें अपेक्षाकृत कम विचार की आवश्यकता है और कई विकेन्द्रीकृत इंटरफ़ेस बिंदु हैं) संभवतः सड़क के नीचे परेशानी पैदा करेगा जब यह एक लाइव और बढ़ती प्रणाली को संशोधित करने का समय है।
मैं यह भी जोड़ सकता हूं कि सभी मामले डोमेन मॉडल के लिए बिल्कुल भी कॉल नहीं करते हैं (अकेले एडीएम को छोड़ दें)। कभी-कभी कार्य की अधिक प्रक्रियात्मक / कार्यात्मक शैली का उपयोग करना बेहतर होता है डेटा चालित होता है और यह एप्लिकेशन-वाइड लॉजिक / व्यावसायिक नियमों पर निर्भर नहीं करता है।
यदि आप एक संपूर्ण ऐप के लिए पेशेवरों और विपक्षों पर निर्णय लेने की कोशिश कर रहे हैं, तो मुझे लगता है कि पहले यह डिजाइन करना महत्वपूर्ण है कि हर कोई आपके दिए गए आवेदन के लिए कैसा दिख सकता है, इससे पहले कि आप कोड की एक भी पंक्ति लिखना शुरू कर दें। एक बार जब आप CRC'd या वायर-फ्रेम किए गए अपने आवेदन को दोनों शैलियों में ले लेंगे, तो एक कदम पीछे ले जाएं और निर्णय लें कि कौन सा अधिक समझ में आता है और एप्लिकेशन को बेहतर बनाता है।
आगे यह भी सोचिए कि किसको बनाए रखना आसान होगा ...
यह बेहतर भविष्यवाणी करता है। प्रबंधकों को यह पसंद है, खासकर अगर परियोजना को समय और सामग्री का भुगतान किया जाता है। हर बदलाव का मतलब बहुत काम होता है, इसलिए बहुत सारे दोहराव वाले काम के पीछे मुश्किल काम को छिपाया जा सकता है। एक अच्छी तरह से डिजाइन की गई DRY प्रणाली में, पूर्वानुमानशीलता बहुत खराब है, क्योंकि आप लगातार नई चीजें कर रहे हैं।
डोमेन-संचालित डिज़ाइन के बारे में एरिक इवांस की किताब को पढ़ने के बाद मैंने वास्तव में यह नहीं समझा कि यह अच्छे डोमेन मॉडल कक्षाओं को डिजाइन करने के लिए केवल सामरिक पैटर्न का एक गुच्छा नहीं है।
विषय के बारे में अधिक जानने के बाद और रणनीतिक पैटर्न का उपयोग करने के साथ-साथ अंत में मुझे यह समझ में आने लगा कि सबसे पहले यह उन व्यावसायिक समस्याओं की गहरी समझ पाने के बारे में है जिन्हें आप हल करने की कोशिश कर रहे हैं।
और उसके बाद ही आप यह तय कर सकते हैं कि सिस्टम के कौन से भाग सामरिक पैटर्न जैसे एग्रीगेट, एंटिटी , रिपॉजिटरी इत्यादि के साथ-साथ तथाकथित समृद्ध डोमेन मॉडल (जैसे एनीमिक के विपरीत ) लागू करने के लिए फिट होंगे । लेकिन इन पैटर्नों से लाभान्वित होने के लिए सिस्टम के उस हिस्से के लिए व्यावसायिक तर्क से संबंधित पर्याप्त जटिलता होनी चाहिए ।
इसलिए जब हाथ में समस्या के समाधान को लागू करने की बात आती है, तो पहले यह निर्धारित किया जाना चाहिए कि क्या यह विशिष्ट समस्या सीआरयूडी आधारित दृष्टिकोण का उपयोग करने या एक समृद्ध डोमेन मॉडल के साथ-साथ उल्लिखित सामरिक पैटर्न के साथ निवेश करने के लिए बेहतर है ।
यदि CRUD अधिक समझ में आता है, उदाहरण के लिए, यदि कोई जटिल व्यावसायिक तर्क नहीं है और अधिकांश तर्क एक डोमेन मॉडल को लागू करने वाले डेटा को बदलने, स्थानांतरित करने और बनाए रखने से संबंधित है, तो यह एक अनावश्यक अतिव्याप्ति हो सकती है। इसका मतलब यह नहीं है कि काम करने के लिए बहुत कुछ नहीं होगा लेकिन बस यह व्यावसायिक नियम नहीं हैं जो सबसे अधिक कार्यान्वयन के प्रयास का उत्पादन करते हैं। लेकिन इस मामले में एनीमिक डोमेन मॉडल जैसी कोई चीज नहीं है , सिर्फ इसलिए कि कोई डोमेन मॉडल नहीं है । आप जो देखेंगे, वह ऐसी चीजें हैं जैसे डीटीओ (डेटा ट्रांसफर ऑब्जेक्ट) या डीएओ(डेटा एक्सेस ऑब्जेक्ट) और सेवा वर्ग जो डेटा पर काम करेंगे। और संबंधित परिचालनों का एक हद तक डेटा को एक प्रतिनिधित्व से दूसरे में बदलने और बहुत कम या लगभग कोई व्यावसायिक तर्क नहीं होने के साथ डेटा स्थानांतरित करने से संबंधित हैं।
यदि आपने निर्धारित किया है कि बहुत सारे जटिल व्यावसायिक तर्क हैं जो समय के साथ एक डोमेन मॉडल में निवेश करने की तुलना में भी बदल जाएंगे - मेरे अनुभव से - एक अच्छा विचार है। कारण यह है कि कोड के माध्यम से व्यावसायिक दृष्टिकोण का प्रतिनिधित्व करना आसान है और व्यवसाय के डोमेन को प्रतिबिंबित करने वाले संबंधित कार्यों को समझना आसान है और यह नियम है। इसका मतलब यह नहीं है कि हर उपयोग के मामले में डोमेन मॉडल कक्षाएं होनी चाहिए। उदाहरण के लिए, यदि कोई राज्य उत्परिवर्तित होने की स्थिति में नहीं है और वहाँ कायम है तो केवल वही डोमेन सेवाएँ हो सकती हैं जिनमें डोमेन लॉजिक को शुद्ध कार्यों से अधिक कार्यान्वित किया जाता है।
लेकिन अगर वहाँ भी उत्परिवर्तित होने की स्थिति है और इस बात पर कायम है कि व्यावसायिक क्षेत्र में भी उद्देश्य और अर्थ है और राज्य को बदलने वाले व्यवहार को संक्षिप्त किया जाना चाहिए । इसके साथ कोई भी व्यावसायिक नियमों के आस-पास नहीं पहुंच सकता है जो आसान है और इसके कारण गंभीर विफलताओं के साथ अमान्य राज्यों तक ले जाते हैं। तथाकथित एनीमिक डोमेन मॉडल अक्सर ऐसी समस्याओं के स्रोत होते हैं जो । यह अक्सर ऐसा होता है जब आप उस कोड को देखते हैं जहां विभिन्न घटक एक ही "एनीमिक" डोमेन मॉडल वर्ग पर काम करते हैं, यह उसके कुछ हिस्से की जाँच करता है और उस व्यावसायिक इकाई के समग्र चालकों के बारे में परवाह किए बिना या उसके बारे में जानने के बिना इसका कुछ हिस्सा बदल रहा है। यह एक विरोधी पैटर्न कॉल करने के लिए आवश्यक नहीं है, लेकिन यह समझना महत्वपूर्ण हैआप समृद्ध डोमेन मॉडल के बहुत सारे लाभ खो देते हैंउल्लेखित समस्याओं के साथ एक DDD आधारित दृष्टिकोण में। डोमेन मॉडल का उपयोग करते समय जहां व्यवहार और उसके डेटा को एक ही वर्ग में रखा जाता है, वहां उस वर्ग के विभिन्न "क्लाइंट" कॉलिंग ऑपरेशंस भी हो सकते हैं, लेकिन उन्हें यह ध्यान रखने की आवश्यकता नहीं है कि व्यवसाय इकाई के व्यवसाय के रूप में पालन किया जाता है। डोमेन मॉडल वर्ग हमेशा इस बात का ध्यान रखेगा और "क्लाइंट" को अवैध संचालन के बारे में सूचित कर सकता है या सुरक्षा नेट के रूप में अपवाद भी फेंक सकता है।
इसलिए नीचे की पंक्ति , मुझे लगता है कि एनीमिक डोमेन मॉडल कक्षाओं के साथ वर्गों (जैसे डीटीओ या डीएओ) जैसी डेटा-संरचना को भ्रमित नहीं करना महत्वपूर्ण है । ध्यान से और जानबूझकर चुने गए CRUD आधारित दृष्टिकोण में एक डोमेन मॉडल का उपयोग करने की कोशिश करने का कोई फायदा नहीं है क्योंकि बहुत कम जटिल व्यावसायिक तर्क है।
तक कमजोर डोमेन मॉडल मैं कोड है जहाँ से मैं देख सकता हूँ जटिल व्यापार तर्क और व्यापार के नियम है कि विभिन्न घटकों जो बल्कि डेटा इन तर्क बदल रहा है के करीब होना चाहिए में फैले हुए हैं की एक बहुत कुछ है कि वहाँ का उल्लेख होगा।
एक और सबक भी है जो मैंने रास्ते में सीखा है: यदि आप अपने कोड में उसी व्यावसायिक भाषा (जिसे सर्वव्यापी भाषा के रूप में भी संदर्भित किया गया है ) का उपयोग करने का प्रयास करते हैं, जो स्टेकहोल्डर अपनी दैनिक कार्यशैली में उपयोग कर रहे हैं, तो आप पहले से ही इतने सारे फायदे जीत लेते हैं कि आप समझ में नहीं आते हैं व्यवसाय डोमेन और आपके कोड की पठनीयता में सुधार करने में मदद करेगा जो कि अगर आप CRUD आधारित या डोमेन मॉडल आधारित दृष्टिकोण का उपयोग करते हैं, तो इससे आपको कोई फर्क नहीं पड़ता।
माइकल के उत्तर का विस्तार करने के लिए मैंने सोचा था कि यह (काफी) स्पष्ट है कि वह कोड कहाँ जाना चाहिए: एक समर्पित मध्यस्थ में जो बातचीत के आदेश और इन्वेंटरी को दांव पर लगाता है।
मेरे POV से डोमेन के बारे में मुख्य बात यह है कि यह सरल परीक्षण व्यवहार के isInThisState()तरीकों आदि को धारण करता है । मेरे अनुभव में ये अधिकांश कंपनियों में सेवा के आँसू (बिखरे हुए) भी बिखरे हुए हैं, और या तो कॉपी किए गए हैं। जिनमें से सभी मानक जमाव नियम तोड़ते हैं।
मेरे विचार में दृष्टिकोण एक डीएम के लिए लक्ष्य होना चाहिए जो अधिक से अधिक बिज़ बीहैरव के रूप में हो जो व्यावहारिक हो, बाकी को स्पष्ट रूप से नामित क्षेत्रों में रखें (अर्थात सेवाओं में नहीं)
मेरी टीम व्यक्तिगत रूप से ADM को प्राथमिकता देती है। हमारे पास व्यावसायिक वस्तुओं का एक समूह है जो हमारे डोमेन के विशिष्ट भागों का प्रतिनिधित्व करता है। हम इन वस्तुओं को db पर सहेजने के लिए सेवाओं का उपयोग करते हैं। हमारी व्यावसायिक वस्तुओं में विधियाँ हैं, हालाँकि ये विधियाँ केवल आंतरिक स्थिति में हेरफेर करती हैं।
RDM पर ADM का उपयोग करने में हमारे लिए लाभ यह देखा जा सकता है कि हम वस्तुओं को db में कैसे बनाए रखते हैं। हमारे विरासत कोड सिस्टम पर काम करने वाले डेवलपर्स हमारी व्यावसायिक वस्तुओं (नई प्रणाली से) का उपयोग कर सकते हैं और इन वस्तुओं को डीबी पर जारी रखने के लिए अपनी वर्तमान डेटा एक्सेस परत का उपयोग जारी रख सकते हैं। आरडीएम का उपयोग हमारी विरासत प्रणाली के डेवलपर्स को रिपॉजिटरी ऑब्जेक्ट्स को हमारे व्यवसाय मॉडल में इंजेक्ट करने के लिए मजबूर करेगा ... जो कि उनके वर्तमान डेटा एक्सेस परत के अनुरूप नहीं होगा।
एक कमजोर डोमेन मॉडल एक विरोधी पैटर्न है। एंटी-पैटर्न में कोई नियम नहीं है।