एनीमिक डोमेन मॉडल और डोमेन सेवा इंजेक्शन

Question

कमजोर डोमेन मॉडल मार्टिन Fowler द्वारा डोमेन संचालित डिजाइन में एक विरोधी पैटर्न के रूप में वर्णित किया गया है। डोमेन मॉडल पर व्यावसायिक तर्क रखने के लिए अक्सर डोमेन सेवाओं का उपयोग किया जाता है। लेकिन डोमेन सेवाओं में डोमेन सेवाओं को इंजेक्ट करना वॉन वर्नोन द्वारा हानिकारक माना जाता है (देखें "डोमेन-संचालित डिज़ाइन, पेज 383 लागू करना)।

मेरे विचार से वे मत विरोधाभासी हैं, क्या यह सच है? दोनों बिंदुओं पर विचार कैसे किया जा सकता है?

क्या यह वास्तव में समृद्ध डोमेन मॉडल है डोमेन इंजेक्शन बनाम एनीमिक डोमेन मॉडल और सामान्य डोमेन सेवाओं के साथ ?

Comments

मैं इस पर कोई विशेषज्ञ नहीं हूं, लेकिन मुझे लगा कि डोमेन सेवाओं में और डोमेन संस्थाओं में तर्क का प्रकार मौलिक रूप से अलग था। एंटिटीज में जाने वाला लॉजिक एक सही स्थिति में ऑब्जेक्ट को रखने के लिए जरूरी लॉजिक है। इसमें सत्यापन और परिवर्तन तर्क शामिल हैं। दूसरी ओर, डोमेन सेवाएँ उच्च स्तर के तर्क के लिए हैं। इसलिए, उदाहरण के लिए, एक डोमेन सेवा एक व्यवसाय प्रक्रिया को मॉडल करेगी जिसमें कई अलग-अलग प्रकार की इकाइयाँ जटिल तरीके शामिल हैं।

— मेटाफ़ाइट

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

— ग्रेग बर्गार्ड्ट

इससे समझ में आता है :)

— MetaFight

Answer 1

एनीमिक मॉडल केवल एक डेटा कंटेनर है। इसमें व्यवहार नहीं है। (यह वास्तव में कार्यात्मक प्रतिमान में एक अच्छी बात माना जा सकता है।) एनीमिक मॉडल के विपरीत डोमेन सेवाओं से भरा एक मॉडल नहीं है। आप दो चरम सीमाओं का वर्णन कर रहे हैं - दोनों खराब हैं।

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

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

Comments

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

— ग्रेग बर्गार्ड्ट

Answer 2

यह विरोधाभासी नहीं है। दोनों प्रस्तावक चाहेंगे कि आप अपना वास्तविक कोड डोमेन ऑब्जेक्ट में ही डालें।

अर्थात।

public class Order
{
    private string status = "not bought";
    public void Buy()
    {
        this.status = "bought";
    }
}

बनाम एडीएम

public class Order
{
    public string Status = "not bought";
}

public class BuyingService
{
    public Order Buy(Order order)
    {
         Order o = new Order();
         o.status = "bought";
         return o;
    }
}

बनाम इंजेक्शन वाली सेवाएं

public class Order
{
    public Order(IBuyingService bs)
    {
        _bs = bs;
    }
    private IbuyingService _bs;
    private string status = "not bought";
    public void Buy()
    {
        this.status = _bs.Buy();
    }
}

public class BuyingService : IBuyingService
{
    public string Buy()
    {
         return = "bought";
    }
}

सच कहूँ तो प्रत्येक दृष्टिकोण में प्लसस और मिनस हैं। आप जो चुनते हैं वह काफी हद तक व्यक्तिगत प्राथमिकता का मामला है