डीडीडी - कुल

Question

के भीतर बाल वस्तुओं के संशोधन मुझे काफी जटिल परिदृश्य को संभालने का सबसे अच्छा तरीका काम करने में कुछ कठिनाई हो रही है। मैंने कुछ समान प्रश्न देखे हैं, लेकिन किसी ने भी इस परिदृश्य को मेरी संतुष्टि के लिए संबोधित नहीं किया है।

एकाधिक ऑर्डरलाइन (बाल संस्था) के साथ एक ऑर्डर (कुल रूट) बनाया गया है। व्यापार नियमों के मुताबिक, प्रत्येक ऑर्डरलाइन को ऑर्डर के जीवन के लिए एक ही पहचान बनाए रखना चाहिए। ऑर्डरलाइन में कई (20+) गुण होते हैं और आदेश को "लॉक" माना जाने से पहले काफी बार उत्परिवर्तित किया जा सकता है। इसके अलावा, ऐसे आविष्कार हैं जिन्हें रूट स्तर पर लागू किया जाना चाहिए; उदाहरण के लिए, प्रत्येक ऑर्डर लाइन में मात्रा होती है और ऑर्डर के लिए कुल मात्रा X.

से अधिक नहीं हो सकती है। मुझे यकीन नहीं है कि ऑर्डरलाइन में परिवर्तनों पर विचार करते समय इस परिदृश्य को कैसे मॉडल करें। मैं 4 विकल्प है कि मैं के गर्भ धारण कर सकते हैं, लेकिन कोई भी संतोषजनक प्रतीत:

1) समय, एक ऑर्डर लाइन संशोधित करने के लिए यह रूट द्वारा प्रदान किए गए संदर्भ का उपयोग कर आता है। लेकिन मैं जड़ में invariant तर्क की जांच करने की क्षमता खो देता है।

var orderLine = order.GetOrderLine(id); 
orderLine.Quantity = 6; 

2) आदेश पर एक विधि को कॉल करें। मैं सभी अपरिवर्तनीय तर्क लागू कर सकते हैं, लेकिन फिर मैं तरीकों का प्रसार ऑर्डर लाइन के कई गुण को संशोधित करने के साथ अटक कर रहा हूँ:

order.UpdateOrderLineQuantity(id, 6); 
order.UpdateOrderLineDescription(id, description); 
order.UpdateOrderLineProduct(id, product); 
... 

3) अगर मैं एक मूल्य वस्तु के रूप में ऑर्डर लाइन का इलाज किया यह आसान हो सकता है, लेकिन इसे प्रति व्यावसायिक आवश्यकताओं के समान पहचान बनाए रखना है।

4) मैं उन संशोधनों के लिए ऑर्डरलाइन के संदर्भ ले सकता हूं जो इनवेरिएंट को प्रभावित नहीं करते हैं, और जो लोग करते हैं उनके लिए ऑर्डर के माध्यम से जाते हैं। लेकिन फिर क्या होगा यदि अधिकांश ऑर्डरलाइन गुणों से इनवेरिएंट प्रभावित होते हैं? यह आपत्ति कल्पित है, क्योंकि केवल कुछ गुण इनवेरिएंट को प्रभावित कर सकते हैं, लेकिन जब हम अधिक व्यावसायिक तर्क को उजागर करते हैं तो यह बदल सकता है।

किसी भी सुझाव की सराहना की जाती है ... अगर मैं घना हो रहा हूं तो मुझे बताने में संकोच न करें।

Answer 1

1. इष्टतम नहीं है क्योंकि यह डोमेन आविष्कार को तोड़ने की अनुमति देता है।

2. परिणामस्वरूप कोड डुप्लिकेशन और अनावश्यक विधि विस्फोट होगा।

3. 1 जैसा ही है)। वैल्यू ऑब्जेक्ट का उपयोग डोमेन इनवेरिएंट को बनाए रखने में मदद नहीं करेगा।

4. यह विकल्प मैं साथ जाऊंगा। मैं भौतिक होने तक संभावित और काल्पनिक परिवर्तनों के बारे में भी चिंता नहीं करता। डिजाइन डोमेन की आपकी समझ के साथ विकसित होगा और हमेशा बाद में रिफैक्टर हो सकता है। भविष्य में होने वाले कुछ बदलावों के लिए आपके मौजूदा डिज़ाइन में बाधा डालने में वास्तव में कोई मूल्य नहीं है जो ऐसा नहीं हो सकता है।

Answer 2

2 के विपरीत 4 की एक कमी स्थिरता की कमी है। कुछ मामलों में ऑर्डर लाइन आइटम अपडेट करने के संबंध में स्थिरता की डिग्री बनाए रखने के लिए फायदेमंद हो सकता है। यह तुरंत स्पष्ट नहीं हो सकता है क्यों कुछ अपडेट आदेश के माध्यम से किया जाता है आदेश पंक्ति आइटम के माध्यम से दूसरों है। इसके अलावा, यदि आदेश लाइनों 20+ गुण होते हैं, शायद यह है कि एक संकेत है उन गुणों के क्रम लाइन पर कम गुण है, जिसके परिणामस्वरूप में समूहीकरण के लिए क्षमता है है। कुल मिलाकर, दृष्टिकोण 2 या 4 जब तक ठीक के रूप में आप संचालन, परमाणु सुसंगत और सर्वव्यापी भाषा के साथ पत्राचार में रखना सुनिश्चित करें है।

Answer 3

ऐसा करने का पांचवां तरीका है। आप domain event (उदा। QuantityUpdatedEvent(order, product, amount)) को आग लगा सकते हैं। ऑर्डरलाइन की सूची के माध्यम से इसे आंतरिक रूप से संभालने दें, मिलान करने वाले उत्पाद के साथ एक का चयन करें और इसकी मात्रा अपडेट करें (या ऑपरेशन को OrderLine पर अपडेट करें जो कि बेहतर है)

Answer 4

डोमेन ईवेंट सबसे मजबूत समाधान है।

हालांकि अगर यह ओवरकिल है तो आप पैरामीटर ऑब्जेक्ट पैटर्न का उपयोग करके # 2 की भिन्नता भी कर सकते हैं - इकाई रूट पर एक एकल ModfiyOrderItem फ़ंक्शन है। एक नया, अद्यतन ऑर्डर आइटम सबमिट करें, और फिर आंतरिक रूप से ऑर्डर इस नई ऑब्जेक्ट को मान्य करता है और अपडेट करता है।

तो अपने ठेठ कार्यप्रवाह की तरह

var orderItemToModify = order.GetOrderItem(id); 
orderItemToModify.Quantity = newQuant; 

var result = order.ModifyOrderItem(orderItemToModfiy); 
if(result == SUCCESS) 
{ 
    //good 
} 
else 
{ 
    var reason = result.Message; etc 
} 

मुख्य कमी यहाँ यह एक प्रोग्रामर आइटम को संशोधित करने की अनुमति देता है कुछ में बदल जाते हैं जाएगा, लेकिन नहीं यह प्रतिबद्ध और कहा कि पता ही नहीं। हालांकि यह आसानी से एक्स्टेंसिबल और टेस्टेबल है।

Answer 5

यदि आपका प्रोजेक्ट छोटा है और आप डोमेन ईवेंट की जटिलता से बचना चाहते हैं तो यह एक और विकल्प है। एक सेवा है जो आदेश के लिए नियमों को संभालती बनाएँ और ऑर्डर लाइन पर विधि करने के लिए इसे पारित:

public void UpdateQuantity(int quantity, IOrderValidator orderValidator) 
{ 
    if(orderValidator.CanUpdateQuantity(this, quantity)) 
     Quantity = quantity; 
} 

CanUpdateQuantity वर्तमान ऑर्डर लाइन और तर्क के रूप में नए मात्रा ले जाता है। इसे ऑर्डर को देखना चाहिए और यह निर्धारित करना चाहिए कि अद्यतन कुल ऑर्डर मात्रा में उल्लंघन का कारण बनता है या नहीं। (आपको यह निर्धारित करना होगा कि आप एक अद्यतन उल्लंघन को कैसे संभालना चाहते हैं।)

यदि आपका प्रोजेक्ट छोटा है और आपको डोमेन ईवेंट की जटिलता की आवश्यकता नहीं है तो यह एक अच्छा समाधान हो सकता है।

इस तकनीक का नकारात्मक पक्ष यह है कि आप ऑर्डरलाइन में ऑर्डर के लिए सत्यापन सेवा उत्तीर्ण कर रहे हैं, जहां यह वास्तव में संबंधित नहीं है। इसके विपरीत, एक डोमेन इवेंट उठाकर ऑर्डरलाइन को ऑर्डरलाइन से बाहर ले जाता है। ऑर्डरलाइन केवल दुनिया को कह सकती है, "अरे, मैं अपनी मात्रा बदल रहा हूं।" और ऑर्डर सत्यापन तर्क एक हैंडलर में हो सकता है।