रिच बनाम एनीमिक डोमेन मॉडल [बंद]

Question 1

बंद हो गया । यह सवाल राय आधारित है । यह वर्तमान में उत्तर स्वीकार नहीं कर रहा है।

इस प्रश्न को सुधारना चाहते हैं? प्रश्न को अपडेट करें ताकि इस पोस्ट को संपादित करके तथ्यों और उद्धरणों के साथ उत्तर दिया जा सके ।

10 महीने पहले बंद हुआ ।

इस प्रश्न को सुधारें

मैं तय कर रहा हूं कि क्या मुझे एनीमिक डोमेन मॉडल पर रिच डोमेन मॉडल का उपयोग करना चाहिए, और दोनों के अच्छे उदाहरणों की तलाश करनी चाहिए।

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

मैंने एरिक इवान की डीडीडी किताब पढ़ी है, और वह (फाउलर और अन्य के साथ) लगता है कि एनीमिक डोमेन मॉडल एक विरोधी पैटर्न है।

इसलिए मैं वास्तव में इस समस्या में कुछ अंतर्दृष्टि प्राप्त करना चाहता था।

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

Question 2

अंतर यह है कि एनेमिक मॉडल डेटा से तर्क को अलग करता है। तर्क अक्सर नामित वर्गों में रखा गया है **Service, **Util, **Manager, **Helperऔर पर इतना। ये वर्ग डेटा व्याख्या तर्क को लागू करते हैं और इसलिए डेटा मॉडल को एक तर्क के रूप में लेते हैं। उदाहरण के लिए

public BigDecimal calculateTotal(Order order){
...
}

जबकि समृद्ध डोमेन दृष्टिकोण डेटा व्याख्या तर्क को समृद्ध डोमेन मॉडल में रखकर इसका उलटा करता है। इस प्रकार यह तर्क और डेटा को एक साथ रखता है और एक समृद्ध डोमेन मॉडल इस तरह दिखाई देगा:

order.getTotal();

इससे वस्तु की संगति पर बड़ा प्रभाव पड़ता है। चूंकि डेटा व्याख्या तर्क डेटा को लपेटता है (डेटा को केवल ऑब्जेक्ट विधियों के माध्यम से एक्सेस किया जा सकता है) अन्य डेटा के राज्य परिवर्तनों के लिए तरीके प्रतिक्रिया कर सकते हैं -> इसे हम व्यवहार कहते हैं।

एनीमिक मॉडल में डेटा मॉडल यह गारंटी नहीं दे सकते कि वे एक कानूनी स्थिति में हैं जबकि एक समृद्ध डोमेन मॉडल में वे कर सकते हैं। एक समृद्ध डोमेन मॉडल OO सिद्धांतों को लागू करता है जैसे कि एनकैप्सुलेशन, जानकारी को छिपाना और डेटा और तर्क को एक साथ लाना और इसलिए एनीमिक मॉडल OO के दृष्टिकोण से एक विरोधी पैटर्न है।

गहरी जानकारी के लिए मेरे ब्लॉग https://www.link-intersystems.com/blog/2011/10/01/anemic-vs-rich-domain-models/ पर एक नज़र डालें

Question 3

Bozhidar Bozhanov इस ब्लॉग पोस्ट में एनीमिक मॉडल के पक्ष में बहस करते दिख रहे हैं ।

यहाँ सारांश वह प्रस्तुत करता है:

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

अपडेट करें

मैंने हाल ही में इस लेख को पढ़ा है जहां लेखक एक प्रकार के हाइब्रिड दृष्टिकोण का पालन करने की वकालत करता है - डोमेन ऑब्जेक्ट्स उनके राज्य पर आधारित विभिन्न प्रश्नों का उत्तर दे सकते हैं (जो पूरी तरह से एनीमिक मॉडल के मामले में शायद सेवा परत में किया जाएगा)

Question 4

मेरी बात यह है:

एनीमिक डोमेन मॉडल = डेटाबेस टेबल ऑब्जेक्ट्स (केवल फ़ील्ड मान, कोई वास्तविक व्यवहार नहीं) के लिए मैप किया गया

रिच डोमेन मॉडल = वस्तुओं का एक संग्रह जो व्यवहार को उजागर करता है

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

* ध्यान दें कि वस्तु व्यवहार का दृढ़ता से कोई लेना-देना नहीं है। डोमेन ऑब्जेक्ट्स को बनाए रखने के लिए एक अलग परत (डेटा मैपर्स, रिपॉजिटरी आदि) जिम्मेदार है।

Question 5

सबसे पहले, मैंने इस लेख के जवाब को कॉपी किया http://msdn.microsoft.com/en-gb/magazine/dn385704.aspx

चित्र 1 एक एनीमिक डोमेन मॉडल दिखाता है, जो मूल रूप से गेटर्स और सेटर के साथ एक स्कीमा है।

Figure 1 Typical Anemic Domain Model Classes Look Like Database Tables

public class Customer : Person
{
  public Customer()
  {
    Orders = new List<Order>();
  }
  public ICollection<Order> Orders { get; set; }
  public string SalesPersonId { get; set; }
  public ShippingAddress ShippingAddress { get; set; }
}
public abstract class Person
{
  public int Id { get; set; }
  public string Title { get; set; }
  public string FirstName { get; set; }
  public string LastName { get; set; }
  public string CompanyName { get; set; }
  public string EmailAddress { get; set; }
  public string Phone { get; set; }
}

इस समृद्ध मॉडल में, केवल पढ़ने और लिखने के लिए संपत्तियों को उजागर करने के बजाय, ग्राहक की सार्वजनिक सतह स्पष्ट तरीकों से बनी होती है।

Figure 2 A Customer Type That’s a Rich Domain Model, Not Simply Properties

public class Customer : Contact
{
  public Customer(string firstName, string lastName, string email)
  {
    FullName = new FullName(firstName, lastName);
    EmailAddress = email;
    Status = CustomerStatus.Silver;
  }
  internal Customer()
  {
  }
  public void UseBillingAddressForShippingAddress()
  {
    ShippingAddress = new Address(
      BillingAddress.Street1, BillingAddress.Street2,
      BillingAddress.City, BillingAddress.Region,
      BillingAddress.Country, BillingAddress.PostalCode);
  }
  public void CreateNewShippingAddress(string street1, string street2,
   string city, string region, string country, string postalCode)
  {
    ShippingAddress = new Address(
      street1,street2,
      city,region,
      country,postalCode)
  }
  public void CreateBillingInformation(string street1,string street2,
   string city,string region,string country, string postalCode,
   string creditcardNumber, string bankName)
  {
    BillingAddress = new Address      (street1,street2, city,region,country,postalCode );
    CreditCard = new CustomerCreditCard (bankName, creditcardNumber );
  }
  public void SetCustomerContactDetails
   (string email, string phone, string companyName)
  {
    EmailAddress = email;
    Phone = phone;
    CompanyName = companyName;
  }
  public string SalesPersonId { get; private set; }
  public CustomerStatus Status { get; private set; }
  public Address ShippingAddress { get; private set; }
  public Address BillingAddress { get; private set; }
  public CustomerCreditCard CreditCard { get; private set; }
}

Question 6

समृद्ध डोमेन कक्षाओं के लाभों में से एक यह है कि आप किसी भी परत में वस्तु के संदर्भ में उनके व्यवहार (तरीकों) को कॉल कर सकते हैं। इसके अलावा, आप छोटे और वितरित तरीके लिखते हैं जो एक साथ सहयोग करते हैं। एनीमिक डोमेन कक्षाओं में, आप वसा प्रक्रियात्मक तरीके (सेवा परत में) लिखते हैं जो आमतौर पर उपयोग के मामले से प्रेरित होते हैं। अमीर डोमेन वर्गों की तुलना में वे आमतौर पर कम रखरखाव योग्य हैं।

व्यवहार के साथ डोमेन कक्षाओं का एक उदाहरण:

class Order {

     String number

     List<OrderItem> items

     ItemList bonus

     Delivery delivery

     void addItem(Item item) { // add bonus if necessary }

     ItemList needToDeliver() { // items + bonus }

     void deliver() {
         delivery = new Delivery()
         delivery.items = needToDeliver()
     }

}

विधि needToDeliver()उन वस्तुओं की सूची लौटाएगी जिन्हें बोनस सहित वितरित करने की आवश्यकता है। इसे कक्षा के अंदर, किसी अन्य संबंधित वर्ग से, या किसी अन्य परत से बुलाया जा सकता है। उदाहरण के लिए, यदि आप Orderदेखना चाहते हैं, तो आप उपयोगकर्ताओं की पुष्टि करने के लिए आइटम की सूची प्रदर्शित करने needToDeliver()के लिए चयनित Orderका उपयोग कर सकते हैं , इससे पहले कि वे सहेजने के लिए सेव बटन पर क्लिक करें Order।

टिप्पणी करने के लिए प्रतिक्रिया

यह है कि मैं नियंत्रक से डोमेन वर्ग का उपयोग कैसे करता हूं:

def save = {
   Order order = new Order()
   order.addItem(new Item())
   order.addItem(new Item())
   repository.create(order)
}

का निर्माण Orderऔर इसके LineItemएक लेन-देन में है। यदि LineItemकोई नहीं बनाया जा सकता है, तो कोई निर्माण नहीं किया Orderजाएगा।

मेरे पास ऐसी विधि है जो एकल लेनदेन का प्रतिनिधित्व करती है, जैसे:

def deliver = {
   Order order = repository.findOrderByNumber('ORDER-1')
   order.deliver()       
   // save order if necessary
}

अंदर कुछ भी deliver()एक ही लेनदेन के रूप में निष्पादित किया जाएगा। यदि मुझे एक ही लेनदेन में कई असंबंधित तरीकों को निष्पादित करने की आवश्यकता है, तो मैं एक सेवा वर्ग बनाऊंगा।

आलसी लोडिंग अपवाद से बचने के लिए, मैं जेपीए 2.1 नामित इकाई ग्राफ का उपयोग करता हूं। उदाहरण के लिए, डिलीवरी स्क्रीन के लिए नियंत्रक में, मैं deliveryविशेषता लोड करने और अनदेखा करने के लिए विधि बना सकता हूं bonus, जैसे कि repository.findOrderByNumberFetchDelivery()। बोनस स्क्रीन में, मैं एक और तरीका कहता हूं जो bonusविशेषता को लोड करता है और अनदेखा करता है delivery, जैसे कि repository.findOrderByNumberFetchBonus()। इसके बाद से मुझे इस बात की आवश्यकता है कि मैं अब भी deliver()बोनस स्क्रीन के अंदर कॉल नहीं कर सकता ।

Question 7

जब मैं अखंड डेस्कटॉप ऐप लिखता था तो मैंने रिच डोमेन मॉडल बनाया था, उन्हें बनाने में आनंद आता था।

अब मैं छोटे HTTP माइक्रोसर्विसेज लिखता हूं, एनीमिक डीटीओ सहित यथासंभव कम कोड है।

मुझे लगता है कि अखंड डेस्कटॉप या सर्वर ऐप युग से DDD और यह एनामिक तर्क तिथि है। मुझे वह युग याद है और मैं मानूंगा कि एनीमिक मॉडल विषम हैं। मैंने एक बड़ा अखंड एफएक्स ट्रेडिंग ऐप बनाया और कोई मॉडल नहीं था, वास्तव में, यह भयानक था।

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

एक आदेश microservice बहुत कम कार्य हो सकता है, RESTful संसाधनों के रूप में या SOAP के माध्यम से या जो कुछ भी कहा जाता है। आदेश microservice कोड अत्यंत सरल हो सकता है।

एक और अधिक अखंड एकल (माइक्रो) सेवा, विशेष रूप से एक जो इसे रैम में मॉडल रखती है, डीडीडी से लाभ उठा सकती है।

Question 8

मुझे लगता है कि समस्या की जड़ झूठे द्वंद्ववाद में है। इन 2 मॉडलों को निकालना संभव है: अमीर और "एनीमिक" और उन्हें एक दूसरे के विपरीत करना? मुझे लगता है कि यह केवल तभी संभव है जब आपके पास एक वर्ग के बारे में गलत विचार हो । मुझे यकीन नहीं है, लेकिन मुझे लगता है कि मैंने इसे Youtube में Bozhidar Bozhanov वीडियो में से एक में पाया। एक वर्ग इस डेटा पर डेटा + विधियाँ नहीं है। यह पूरी तरह से अमान्य समझ है जो कक्षाओं को दो श्रेणियों में विभाजित करता है: डेटा केवल, इसलिए एनीमिक मॉडल और डेटा + विधियाँ - इतना समृद्ध मॉडल (अधिक सही होने के लिए एक 3 श्रेणी है: केवल विधियाँ भी)।

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

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

इसलिए, हम तर्क को दूसरे वर्ग में ले जा सकते हैं और मूल एक में डेटा छोड़ सकते हैं, लेकिन इसका कोई मतलब नहीं है क्योंकि कुछ अवधारणा में विशेषता और संबंध / प्रक्रिया / विधियाँ शामिल हो सकती हैं और उनमें से एक अलगाव 2 नामों के तहत अवधारणा की नकल करेगा जो कि हो सकता है पैटर्न में कमी: "OBJECT-Attributes" और "OBJECT-Logic"। यह प्रक्रियात्मक और कार्यात्मक भाषाओं में उनकी सीमा के कारण ठीक है, लेकिन यह एक ऐसी भाषा के लिए अत्यधिक आत्म-संयम है जो आपको सभी प्रकार की अवधारणाओं का वर्णन करने की अनुमति देता है।

Question 9

एनीमिक डोमेन मॉडल ओआरएम और नेटवर्क पर आसान हस्तांतरण (सभी कॉमरेड एप्लिकेशन के जीवन-रक्त) के लिए महत्वपूर्ण हैं, लेकिन OO आपके कोड के 'ट्रांसेक्शनल / हैंडलिंग' भागों को इनकैप्सुलेशन और सरल बनाने के लिए बहुत महत्वपूर्ण है।

इसलिए जो महत्वपूर्ण है वह एक दुनिया से दूसरी दुनिया में पहचान और परिवर्तित करने में सक्षम हो रहा है।

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

User(AnemicUser au)

और परिवहन / दृढ़ता के लिए एनीमिक वर्ग बनाने के लिए एडेप्टर विधि

User::ToAnemicUser()

परिवहन / हठ के बाहर हर जगह कोई भी एनीमिक उपयोगकर्ता का उपयोग करने का लक्ष्य न रखें

Question 10

यहाँ एक उदाहरण है जो मदद कर सकता है:

रक्तहीनता से पीड़ित

class Box
{
    public int Height { get; set; }
    public int Width { get; set; }
}

गैर कमजोर

class Box
{
    public int Height { get; private set; }
    public int Width { get; private set; }

    public Box(int height, int width)
    {
        if (height <= 0) {
            throw new ArgumentOutOfRangeException(nameof(height));
        }
        if (width <= 0) {
            throw new ArgumentOutOfRangeException(nameof(width));
        }
        Height = height;
        Width = width;
    }

    public int area()
    {
       return Height * Width;
    }
}

Question 11

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

इस बदलाव का कारण यह है कि अब हम एक एपीआई पहले बनाम यूएक्स पहले दृष्टिकोण की ओर बढ़ रहे हैं। REST ने इसमें बहुत महत्वपूर्ण भूमिका निभाई है। पारंपरिक एपीआई दृष्टिकोण (SOAP की वजह से) शुरू में एक कमांड आधारित एपीआई बनाम HTTP क्रिया (POST, PUT, PATCH, GET और DELETE) पर निर्धारित किया गया था। एक कमांड आधारित एपीआई रिच मॉडल ऑब्जेक्ट ओरिएंटेड दृष्टिकोण के साथ अच्छी तरह से फिट बैठता है और अभी भी बहुत वैध है। हालाँकि, साधारण CRUD आधारित API, हालांकि वे एक रिच मॉडल के भीतर फिट हो सकते हैं, बाकी हिस्सों को ऑर्केस्ट्रेट करने के लिए साधारण एनीमिक मॉडल, वैलिडेटर और डोमेन सेवाओं के साथ बहुत बेहतर है।

मुझे डीडीडी से बहुत प्यार है जो इसे पेश करना है, लेकिन एक समय आता है जब आपको लगातार बदलते रहने और वास्तुकला के लिए बेहतर दृष्टिकोण के लिए इसे थोड़ा सा खिंचाव की आवश्यकता होती है।