c# - DDD में अलग डोमेन मॉडल और दृढ़ता मॉडल होने




orm architecture (2)

मैं डेटाबेस संचालित डिजाइन के बारे में पढ़ रहा हूं और डेटाबेस बनाने के लिए कोड पहले दृष्टिकोण का उपयोग करते हुए इसे कैसे लागू किया जाए। मैंने जो पढ़ा है और जिस पर शोध किया है, उससे इस विषय में दो राय हैं:

  1. 1 वर्ग है जो एक डोमेन मॉडल और दृढ़ता मॉडल दोनों के रूप में कार्य करता है

  2. 2 अलग-अलग वर्ग हैं, एक डोमेन लॉजिक को लागू करता है और एक कोड-प्रथम दृष्टिकोण के लिए उपयोग किया जाता है

अब मुझे पता है कि 1) छोटे समाधानों को सरल बनाने के लिए कहा जाता है, जो कि डोमेन और हठ मॉडल के बीच बहुत अंतर नहीं है, लेकिन मुझे लगता है कि यह एकल जिम्मेदारी सिद्धांत को तोड़ता है और इसके द्वारा बहुत सारे मुद्दों का परिचय देता है जब ORD के सम्मेलन DDD में हस्तक्षेप करते हैं।

मेरे लिए एक आश्चर्य की बात है कि राय को लागू करने के तरीके के कई कोड उदाहरण हैं)। लेकिन राय 2 को कैसे लागू किया जाए और 2 वस्तुओं को कैसे मैप किया जाए, इसका एक भी उदाहरण नहीं मिला है। (संभवत: ऐसे उदाहरण हैं लेकिन मैं C # एक खोजने में विफल रहा)

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

मान लीजिए कि मेरे पास एक टिकट प्रणाली है और टिकटों की समाप्ति तिथि है। मेरा डोमेन मॉडल इस तरह दिखेगा:

/// <summary>
/// Domain Model
/// </summary>
public class TicketEntity
{
    public int Id { get; private set; }

    public decimal Cost { get; private set; }

    public DateTime ExpiryDate { get; private set; }

    public TicketEntity(int id, decimal cost, DateTime expiryDate)
    {
        this.Id = id;
        this.Cost = cost;
        this.ExpiryDate = expiryDate;
    }

    public bool IsTicketExpired()
    {
        if (DateTime.Now > this.ExpiryDate)
        {
            return true;
        }
        else
        {
            return false;
        }
    }
}

ORM के रूप में एंटिटी फ्रेमवर्क का उपयोग करने वाला दृढ़ता मॉडल लगभग एक जैसा दिखेगा लेकिन जैसा कि समाधान बढ़ता है, ऐसा नहीं हो सकता है

/// <summary>
/// ORM code first Persistence Model
/// </summary>
public class Ticket
{
    [Key]
    public int Id { get; set; }

    public decimal Cost { get; set; }

    public DateTime ExpiryDate { get; set; }
}

सब कुछ बहुत अच्छा लग रहा है अब तक। अब मुझे यकीन नहीं है कि रिपॉजिटरी से Ticket दृढ़ता मॉडल प्राप्त करने के लिए सबसे अच्छी जगह कौन सी है और इसे Ticket डोमेन मॉडल में कैसे मैप किया जाए

मैंने यह एक एप्लीकेशन / सर्विस लेयर में किया है।

public class ApplicationService
{
    private ITicketsRepository ticketsRepository;

    public ApplicationService(ITicketsRepository ticketsRepository)
    {
        this.ticketsRepository = ticketsRepository;
    }

    public bool IsTicketExpired(int ticketId)
    {
        Ticket persistanceModel = this.ticketsRepository.GetById(ticketId);
        TicketEntity domainModel = new TicketEntity(
            persistanceModel.Id,
            persistanceModel.Cost,
            persistanceModel.ExpiryDate);

        return domainModel.IsTicketExpired();
    }
}

मेरे प्रश्न हैं:

  1. क्या कोई कारण राय 1) विकास को गति देने और कोड का पुन: उपयोग करने के अलावा अन्य राय 2) को प्राथमिकता दी जाएगी।

  2. क्या मॉडल के मानचित्रण के मेरे दृष्टिकोण में कोई समस्या है? क्या ऐसा कुछ है जो मैंने याद किया है कि जब कोई समाधान बढ़ता है तो क्या मुद्दे सामने आएंगे?


क्या कोई कारण राय 1) विकास को गति देने और कोड का पुन: उपयोग करने के अलावा अन्य राय 2) को प्राथमिकता दी जाएगी।

मैं एक बड़ा एक देख सकता हूं (आगे का सामान): कोई "पर्सिस्टेंस मॉडल" नहीं है। आपको जो भी मिला है वह आपके डेटाबेस में एक रिलेशनल मॉडल और एक डोमेन ऑब्जेक्ट मॉडल है। दोनों के बीच मानचित्रण क्रियाओं का एक समूह है, न कि डेटा संरचनाएँ । क्या अधिक है, यह ठीक है कि ORM क्या करने वाले हैं।

अधिकांश ओआरएम अब उनका समर्थन करते हैं जो उन्हें शुरू से प्रदान करना चाहिए था - अपने डोमेन संस्थाओं को छूने के बिना सीधे कोड में इन कार्यों को घोषित करने का एक तरीका। उदाहरण के लिए एंटिटी फ्रेमवर्क के धाराप्रवाह विन्यास आपको ऐसा करने की अनुमति देते हैं।

आप इस धारणा के अधीन हो सकते हैं कि कोई दृढ़ता मॉडल = एसआरपी का उल्लंघन नहीं कर रहा है और डीडीडी पर रौंद रहा है, क्योंकि कई कार्यान्वयन आपको वहां मिल सकते हैं। लेकिन ऐसा होना जरूरी नहीं है।


क्या कोई कारण राय 1) विकास को गति देने और कोड का पुन: उपयोग करने के अलावा अन्य राय 2) को प्राथमिकता दी जाएगी।

विकल्प 1 केवल शुद्ध आलस्य और विकसित विकास की गति की कल्पना के कारण है। यह सच है कि उन अनुप्रयोगों को संस्करण 1.0 तेजी से बनाया जाएगा। लेकिन जब वे डेवलपर्स एप्लिकेशन के संस्करण 3.0 में पहुंचते हैं, तो उन्हें नहीं लगता कि सभी समझौता होने के कारण एप्लिकेशन को बनाए रखने के लिए यह मजेदार है कि उन्हें ओआरएम मैपर के कारण डोमेन मॉडल में करना पड़ा है।

क्या मॉडल के मानचित्रण के मेरे दृष्टिकोण में कोई समस्या है? क्या ऐसा कुछ है जो मैंने याद किया है कि जब कोई समाधान बढ़ता है तो क्या मुद्दे सामने आएंगे?

हाँ। हठ तंत्र को छिपाने के लिए रिपॉजिटरी को जिम्मेदार होना चाहिए। यह एपीआई केवल डोमेन संस्थाओं के साथ काम करना चाहिए और दृढ़ता संस्थाओं से नहीं।

डोमेन संस्थाओं से / के लिए रूपांतरण करने के लिए रिपॉजिटरी जिम्मेदार है (उन्हें जारी रखने में सक्षम होने के लिए)। डेटाबेस ऑब्जेक्ट / इकाई को लोड करने के लिए एक भ्रूण विधि आमतौर पर ADO.NET या ORM फ्रेमवर्क जैसे ORM का उपयोग करती है। फिर इसे सही व्यावसायिक इकाई में परिवर्तित करें और अंत में इसे वापस कर दें।

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

यदि आप डीडीडी परिभाषा के अनुसार आवेदन सेवाओं के साथ काम करते हैं तो आप संभवतः कमांड / क्वेरी पृथक्करण पैटर्न को देखना चाहेंगे जो कि आवेदन सेवाओं का प्रतिस्थापन हो सकता है। कोड क्लीनर हो जाता है और आपको अपने डोमेन मॉडल को लपेटते हुए बहुत अधिक हल्का एपीआई प्राप्त होता है।





domain-model