php - डीडीडी, पीएचपी डोमेन ऑब्जेक्ट और बिजनेस लॉजिक




model domain-driven-design domain-object (4)

मुझे यकीन नहीं है कि इन प्रकार के सवालों के लिए सही उत्तर है, क्योंकि डीडीडी लागू करना वास्तव में उस विशेष डोमेन पर निर्भर करता है जिसे आप इसे लागू कर रहे हैं। ऐसी जगहें हैं जहां आपका कार्यान्वयन पूरी तरह से मान्य हो सकता है, अगर यह व्यवसाय की जरूरतों को पूरा करता है दूसरों में, जैसा कि आप करों और पसंद के साथ उल्लेख किया है, यह नहीं होगा इसलिए मैं कहूंगा कि आपको अपने डोमेन के बारे में सवाल पूछने की ज़रूरत है ताकि ये समझ सकें कि उन्हें कोड में अनुवाद करने से पहले आपकी आवश्यकताओं की क्या ज़रूरत है।

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

class InvoiceProducer {

    public function __construct(TaxProvider $taxProvider) {
        $this->taxProvider = $taxProvider;
    }

    public function invoiceFor(array $items) {
        new Invoice($items, $this->calculateValue($items));
    }

    private function calculateValue(array $items) {
        $sum = array_reduce($items, function($acc, $item){
            $acc += $item->value;
        }

        return $this->taxProvider->applyTaxTo($sum);
    }
}

एक अन्य विकल्प कुछ प्रकार की रणनीति पद्धति का उपयोग करने के लिए होगा, जो कि आपके क्रियान्वयन को अब जिस तरह से है, उसी तरह से अलग करता है, लेकिन आप अपने कॉल से जिस तरह से आप कर गणना करना चाहते हैं, उससे गुजरना होगा:

public function getInvoiceValue(TaxProvider $taxProvider)
{
    $sum = 0;
    foreach($this->items as $item) {
        $sum += $item->value;
    }

    return $taxProvider->applyTaxFor($sum);
}

फिर, यह वास्तव में निर्भर करता है कि आपका विशिष्ट डोमेन कैसे काम करता है, लेकिन जैसा कि आप देख सकते हैं, यह कार्यान्वयन एक बड़ा सौदा नहीं होना चाहिए। आपके डोमेन में यह सब कैसे फिट बैठता है इसके बारे में अधिक है

मैं हाल ही में डीडीडी और मॉडल परत की अवधारणाओं को समझने की कोशिश में बहुत व्यस्त हूं। लेखों, उदाहरणों, क्यू और ए के कई टन पढ़ें, उस पर कई घंटे बिताए। और फिर भी मुझे यकीन नहीं है कि मुझे कुछ सिद्धांत मिलते हैं।

इनमें से एक प्रश्न का उत्तर है: डोमेन ऑब्जेक्ट्स में कितना व्यापार तर्क मौजूद होना चाहिए? कुछ सूत्रों का कहना है कि डोमेन ऑब्जेक्ट्स को पूरे बिजनेस लॉजिक से जोड़ा जाना चाहिए, दूसरी तरफ, मैं ऐसे लेखों में आया जहां मैंने यह ग्रहण किया कि यह जितना संभव हो उतना छोटा होना चाहिए और केवल उसके मूल्यों का प्रतिनिधित्व करना चाहिए। यह मुझे सच में उलझन में आता है।

मेरी समझ में, डोमेन ऑब्जेक्ट क्लासेस हैं, जो डोमेन में संस्थाओं का प्रतिनिधित्व करते हैं।

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

class Invoice
{
    public $id;
    public $items = [];
    public $status;

    const STATUS_PAID = 'paid';
    const STATUS_NOT_PAID = 'not_paid';

    public function isPaid()
    {
        return $this->status == self::STATUS_PAID;
    }

    public function getInvoiceValue()
    {
        $sum = 0;
        foreach($this->items as $item) {
            $sum += $item->value;
        }
        return $sum;
    }
}

मेरी समझ में, विधि है पेड () सही जगह पर है। यह अपने डेटा को संदर्भित करता है लेकिन मुझे यकीन है कि नहीं मिलता है इनवॉइस वैल्यू () हम यहां अन्य डोमेन ऑब्जेक्ट्स पर काम करते हैं।

शायद हमें केवल डोमेन का प्रतिनिधित्व करने के लिए डोमेन ऑब्जेक्ट का उपयोग करना चाहिए, लेकिन अधिक सजावट करने के लिए अधिक उन्नत कार्य करने के लिए उपयोग करना चाहिए?

अग्रिम में धन्यवाद।


डोमेन ऑब्जेक्ट में कितना व्यापार तर्क मौजूद होना चाहिए?

यह सब (यदि संभव हो तो) डीडीडी का मुद्दा आपके डोमेन में अपने व्यापारिक तर्क को पकड़ना है - विभिन्न सामरिक प्रतिमानों का उपयोग यहां (सकल, संस्थाएं, मान वस्तुएं, डोमेन सेवा आदि) में मदद के लिए किया जा सकता है।

डोमेन ऑब्जेक्ट्स वर्ग हैं, जो डोमेन में संस्थाओं का प्रतिनिधित्व करते हैं

आपके डोमेन की कक्षाएं सिर्फ संस्थाओं से अधिक का प्रतिनिधित्व कर सकती हैं समुच्चय, संस्थाएं, मूल्य वस्तुएं, डोमेन सर्विसेज आदि का आपके डोमेन में सभी वर्गों द्वारा प्रतिनिधित्व किया जा सकता है

लेकिन मुझे यकीन है कि नहीं मिलता है इनवॉइस वैल्यू () हम यहां अन्य डोमेन ऑब्जेक्ट्स पर काम करते हैं।

चालान का उदाहरण आप एक समग्र - चालान का एक उत्कृष्ट उदाहरण है जिसमें इनवॉइस आइटम्स शामिल होंगे। getInvoiceValue () ठीक है यहाँ।

हमारे मामले में, चालान एक समग्र है। सकल रूट ही इंवॉइस है, लेकिन यह भी इकाई है, है ना? इसकी अपनी पहचान है हालांकि (चालान संख्या अद्वितीय है)।

हाँ सही

इनवॉइस क्या हैं? क्या मैं इनवॉइस आईटम रिपॉजिटरी से सीधे उन्हें प्राप्त कर सकता हूं (अगर मुझे इस तरह बनाना चाहिए), या क्या मुझे केवल एकमात्र पर काम करना है?

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


डोमेन ऑब्जेक्ट में कितना व्यापार तर्क मौजूद होना चाहिए? [...] मैं उन लेखों में आया जहां मैंने यह ग्रहण किया था जितना संभव हो उतना छोटा होना चाहिए और केवल उसके मूल्यों का प्रतिनिधित्व करना चाहिए।

एनीमिक डोमेन मॉडल से सावधान रहें जो लगभग अनन्य रूप से डेटा के होते हैं और व्यवहार का अभाव है डीडीडी एक व्यवहार-समृद्ध डोमेन मॉडल बनाने के बारे में है इस प्रकार डोमेन वर्गों में तर्क जोड़ना ठीक है

डीडीडी अच्छे ऑब्जेक्ट ओरिएंटेड डिज़ाइन पर जोर देता है, तरीके और डेटा को एक साथ रखता है, जिससे अत्यधिक संयोजक सिस्टम को बढ़ावा देता है।


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





php model domain-driven-design domain-object