2009-06-10 9 views
12

मैं समेकित और कुल जड़ों के साथ संघर्ष कर रहा हूं। मेरे पास एक प्राकृतिक कुल रूट है जो उपयोगकर्ता अनुरोधों के लगभग 60% के लिए काम करती है। अर्थात। वे अनुरोध कुल रूट पर स्वाभाविक रूप से लागू होते हैं।डोमेन संचालित डिजाइन - कुल रूट

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

तो, मुझे लगता है कि मैं कुछ विकल्प होते हैं:

  1. वे वे दोनों आधार पर कुल जड़ों जिस पर आपरेशन उपयोगकर्ता द्वारा अनुरोध किया जा रहा है हो सकता है।
  2. सभी परिचालनों को शीर्ष स्तर समग्र रूट के माध्यम से जाना है।

ध्यान दें कि शीर्ष स्तर की समग्र रूट इस अन्य इकाई का संग्रह रखेगी।


उदाहरण:

मुख्य सकल जड़: कार

दूसरा इकाई: सीट (एक कार या तो 2 या 4 प्रकार के आधार पर सीटें हैं)। मेरी डोमेन सीटों में केवल एक कार के हिस्से के रूप में मौजूद हो सकता है।

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

सीट और कार दोनों समग्र जड़ों हो सकते हैं? या मुझे हमेशा कार से शुरू करना चाहिए?

धन्यवाद

उत्तर

13

एक समग्र के विचार स्थिरता की गारंटी करने, डेटा अखंडता और मजबूर कर अपरिवर्तनशीलताओं के लिए रूट जिम्मेदार जा रहा है।

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

आईएमएचओ, यदि अखंडता या इनवेरिएंट को मजबूर करना कोई मुद्दा नहीं है, तो कुल मिलाकर वास्तव में आवश्यकता नहीं होती है। लेकिन, यदि यह जरूरी है, तो मेरी सलाह है कि कार के साथ सब कुछ शुरू करना है। लेकिन हमेशा मॉडल के बारे में सोचें। अगर इन तरह के आविष्कार हैं, तो इन आविष्कारों को कौन लागू करता है? फिर इस विचार को कोड में पास करने का प्रयास करें, और सब कुछ ठीक होना चाहिए।

1

एक कार्ट और लाइन आइटम के साथ एक शॉपिंग कार्ट के मामले में मेरे पास कुल जड़ों के रूप में दोनों हैं क्योंकि मैं अक्सर उन्हें स्वतंत्र रूप से संशोधित करता हूं।

public class Cart : IAggregateRoot 
{ 
    public List<LineItem> LineItems {get;} 
} 

public class LineItems : IAggregateRoot 
{ 
    public List<LineItem> LineItems {get;} 
} 

हालांकि, मैं आदेश के लिए एक अलग घिरे संदर्भ है और इस मामले में मैं केवल एक कुल जड़ है के बाद से मैं अब स्वतंत्र रूप से लाइन आइटम संशोधित करने की आवश्यकता की जरूरत है।

public class Order : IAggregateRoot 
{ 
    public List<LineItem> LineItems {get;} 
} 

दूसरा विकल्प एक बच्चे आईडी से कुल रूट को देखने का एक तरीका है।

Car GetCarFromSeatID(guid seatID) 
2

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

जब यह केवल सिस्टम कार्यान्वयन पर बाहर निकलता है, तो आप डोमेन की समीक्षा करने के लिए वापस जाते हैं या आपने कुछ नाजुकता की खोज की है, जिसका फीडबैक डोमेन के समृद्ध और बेहतर मॉडल बनाने के लिए व्यवसाय के संबंधित विवरणों पर कुल परिवर्तन कर सकता है ।

कार उदाहरण में, मैंने दो समेककों के दृष्टिकोण का उपयोग किया जो विभिन्न संदर्भों से संबंधित हैं। पहला "कार सीट" दृष्टिकोण होगा, और इस कुल में "सीट" के लिए संभावित कार्रवाइयां केवल "कार के हिस्से के रूप में सीट" के लिए समझदार होंगी। उदाहरण: साफ करें।

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