कुल सीमाओं को कैसे डिज़ाइन करें?

Question

मैं एक आवेदन लिखना चाहूंगा जैसे कि ईकॉमर्स।

और आप जानते हैं कि समान अनुप्रयोगों में उत्पादों के विभिन्न गुण और विशेषताएं हो सकती हैं। ऐसे अवसर का अनुकरण करने के लिए मैंने निम्नलिखित डोमेन मॉडल इकाइयाँ बनाई हैं:

श्रेणी - यह कुछ ऐसा है जैसे "इलेक्ट्रॉनिक्स> रीकॉम्पूअर" अर्थात उत्पादों के प्रकार। श्रेणी में संपत्तियों की एक सूची होती है (सूची <संपत्ति>)।

संपत्ति - स्वतंत्र इकाई जिसमें नाम, माप की इकाइयाँ, डेटा प्रकार शामिल हैं। उदाहरण के लिए "नाम", "वजन", "स्क्रीन आकार"। एक ही संपत्ति में अलग-अलग उत्पाद हो सकते हैं।

उत्पाद - बस गुणों से संबंधित मानों का नाम और सूची है। मूल्य एक ऐसी वस्तु है जिसमें सिर्फ मूल्य फ़ील्ड और संपत्ति का फ़ील्ड आईडी शामिल है।

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

अगला चरण ठीक है मैंने एक अलग एग्रीगेट में अलग प्रॉपर्टी का फैसला किया, लेकिन फिर यह साधारण संस्थाओं के साथ एक सूची होगी।

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

इस व्यावसायिक मामले को डिजाइन करने के लिए क्या विकल्प हैं?

Comments

क्या आप किसी श्रेणी, संपत्ति और उत्पाद का अधिक संपूर्ण उदाहरण प्रदान कर सकते हैं? इलेक्ट्रॉनिक्स या कंप्यूटर एक श्रेणी होगी, iPhone X एक उत्पाद का एक उदाहरण होगा, और एक संपत्ति वास्तव में क्या होगी? 11 "इंच का प्रदर्शन?

— नील

आप लगभग सही हैं। मैंने कुछ स्पष्टीकरण जोड़े

— cephei

ऐसा लगता है कि आप विशेष रूप से "डेटा कंटेनर" के परिप्रेक्ष्य से समग्र डिजाइन देख रहे हैं। आप अपने आवेदन के मामलों के उपयोग के बारे में भी सोचना चाह सकते हैं, लेन-देन के पहलुओं, सहयोग / समवर्ती उपयोग, घटनाओं को घटित करना, राज्य परिवर्तन, आदि

— guillaume31

Answer 1

DDD परिप्रेक्ष्य में Category, Productऔर Propertyसंस्थाएं हैं: वे सभी उन वस्तुओं के अनुरूप हैं जिनकी अपनी पहचान है।

विकल्प 1: आपका मूल डिज़ाइन

आपने Categoryएक एकल का मूल बनाया । एक तरफ, यह समझ में आता है, क्योंकि कुल स्थिरता सुनिश्चित करेगा जब अपनी वस्तुओं संशोधित कर रहे हैं, और Productहोना आवश्यक है Propertiesइसकी की Category:

लेकिन दूसरी तरफ, एकल समुच्चय का अर्थ है कि इसकी सभी वस्तुएं एक जड़ से संबंधित हैं जो उनके मालिक हैं, और सभी बाहरी संदर्भों को इस समग्र जड़ के माध्यम से बनाया जाना चाहिए। यह बताता है कि:

• एक विशिष्ट Productएक और केवल एक के अंतर्गत आता है Category। यदि Categoryहटा दिया गया है, तो इसके हैं Products।
• एक विशिष्ट Propertyएक और केवल एक के अंतर्गत आता है Category। अन्यथा कहा जाता है, अगर "टीवी स्क्रीन" और "कंप्यूटर मॉनिटर" दो श्रेणियां होंगी, "टीवी स्क्रीन: आकार" और "कंप्यूटर मॉनिटर: आकार" दो अलग-अलग गुण होंगे।

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

विकल्प 2: कुल के बाहर की संपत्ति

यदि Propertyस्वतंत्र रूप से मौजूद है Categories, तो यह कुल के बाहर होना चाहिए। और यदि आप Propertiesबीच साझा करना चाहते हैं Categories(जो ऊंचाई, चौड़ाई, आकार, आदि के लिए समझ में आता है ...)। यह निश्चित रूप से मामला है।

परिणाम के बीच लिंक पर है Propertyऔर चीजें जो कुल से संबंधित हैं: जब आप कुल के आंतरिक से नेविगेट कर सकते Propertyहैं, तो आपको अब Propertyसंबंधित मानों से सीधे जाने की अनुमति नहीं है । यह नौवहन क्षमता प्रतिबंध यूएमएल आरेख में दिखाया जा सकता है:

ध्यान दें कि यह डिज़ाइन आपको एक संदर्भ शब्दार्थ (जैसे जावा) के साथ एक List<Property>में आने से नहीं रोकता है Category: सूची में प्रत्येक संदर्भ Propertyएक भंडार में एक साझा करने योग्य वस्तु को संदर्भित करता है।

इस डिज़ाइन के साथ एकमात्र समस्या यह है कि आप Propertyइसे बदल सकते हैं या इसे हटा सकते हैं: जैसा कि एग्रीगेट के बाहर है, एग्रीगेट अपने आक्रमणकारियों की निरंतरता का ध्यान नहीं रख सकता है। लेकिन यह कोई समस्या नहीं है। यह डीडीडी सिद्धांतों और वास्तविक दुनिया की जटिलता का परिणाम है। यहाँ एरिक इवांस ने अपनी सेमिनल बुक " डोमेन-ड्रिवेन डिज़ाइन: टेकलिंग कॉम्प्लेक्सिटी इन द हार्ट ऑफ़ सॉफ्टवेयर " का एक उद्धरण दिया :

कोई भी नियम जो AGGREGATES तक फैला है , हर समय अप-टू-डेट होने की उम्मीद नहीं की जाएगी। घटना प्रसंस्करण, बैच प्रसंस्करण, या अन्य अद्यतन तंत्र के माध्यम से, अन्य निर्भरताएँ कुछ निर्दिष्ट समय के भीतर हल की जा सकती हैं। लेकिन AGGREGATE के भीतर लागू किए गए चालानों को प्रत्येक लेनदेन के पूरा होने के साथ लागू किया जाएगा।

तो हां, यदि आप इसे बदलते हैं, तो आपको Propertyयह सुनिश्चित करना होगा कि कोई सेवा चेक श्रेणियों की जांच कर रही है, जो आवश्यकतानुसार अद्यतन की गई हैं।

विकल्प 3: श्रेणी, संपत्ति और उत्पाद विभिन्न समुच्चय में

मुझे आश्चर्य होता है कि क्या यह धारणा कि एक का Productसंबंध Categoryस्थापित है:

• मैं अक्सर ऑनलाइन दुकानों Productको कई के तहत एक का प्रस्ताव देखता हूं Categories। उदाहरण के लिए, आपको "लैपटॉप ब्रांड एक्स मॉडल वाई" श्रेणी "लैपटॉप" और श्रेणी "कंप्यूटर", और श्रेणी "प्रिंटर", "स्कैनर" और "फैक्स" के तहत एक "मल्टीफ़ंक्शन प्रिंटर जेड" मिलेगा।
• क्या यह संभव नहीं है कि कोई व्यक्ति Productपहले बनाता है , और केवल बाद में उसे श्रेणियाँ देता है और मूल्यों को भरता है?
• यदि आप किसी श्रेणी को विभाजित करना चाहते हैं, तो क्या आप वास्तव में उसके उत्पाद हटा देंगे और फिर उन्हें नई श्रेणियों के तहत पुनः बनाएंगे?

यह समुच्चय को सरल नहीं करेगा, और आपके पास और भी नियम होंगे जो समुच्चय को बढ़ाते हैं। लेकिन आपका सिस्टम भविष्य में बहुत अधिक प्रमाण होगा।

Comments

बहुत बहुत धन्यवाद यह एक बहुत ही उपयोगी व्याख्या है। लेकिन मैं कुछ बिंदुओं को स्पष्ट करना चाहूंगा। मैं दूसरे विकल्प के साथ शुरुआत करना चाहता हूं और कौन जानता है, शायद मैं तीसरे नंबर पर आऊंगा। अगर मैं कुल Propertyकी सीमाओं से परे ले Categoryजाऊं तो क्या इसका मतलब यह है कि यह Propertyअपने आप में एक समुच्चय बन जाता है और एक भंडार की जरूरत है? यदि यह सच है तो कैसे की आवश्यकता पारित करने List<Property>में Categoryउदाहरण? कंस्ट्रक्टर के माध्यम से? यह सही होगा? और मुझे कैसे पता चलेगा कि Propertyआईडी की सूची Categoryअभी तक नहीं बनाई गई है?

— सेफेई

संक्षेप में @zetetic: हाँ, आपको एक स्वतंत्र संपत्ति भंडार की आवश्यकता होगी। या तो आप श्रेणी के कारखाने के लिए मौजूदा गुणों की एक सूची पास करते हैं, या आप खाली श्रेणियाँ बनाते हैं और एक addProperty विधि के साथ सूची को पॉप्युलेट करते हैं। बदले में प्रश्न: कल्पना करें कि आप "अनिवार्य" और "वैकल्पिक" गुण रखना चाहते हैं, और अनिवार्य विशेषता श्रेणी पर निर्भर करती है। आप इसे कैसे संभालेंगे ?

— क्रिस्टोफ

आपके प्रश्न का उत्तर देते हुए पहली बात यह ध्यान में आती है कि मैं एक विशेष इकाई बना सकता हूं Featureऔर यह केवल उसी की होगी Product। और यह इकाई खोज में भाग नहीं लेगी। तुम्हारा क्या कहना है ?

— सेफे

@zetetic क्यों नहीं! मैंने मानों को छोड़ दिया है क्योंकि वे इस समय उत्पाद में हैं, और श्रेणी के लिए फीचर से जुड़ा होगा। एक श्रेणी में एन विशेषताएं (इसके कुल का हिस्सा) है, एक संपत्ति एम विशेषताओं को परिभाषित करती है (लेकिन लिंक श्रेणी-> सुविधा के माध्यम से जाती है)। आपने तब समग्र सीमा को स्पष्ट करते हुए कई-से-अधिक संबंधों को अधिक प्रबंधनीय तत्वों में विघटित कर दिया था। अंत में रिपॉजिटरी इंजेक्शन के बारे में: यदि आप पहचान द्वारा अन्य समुच्चय का संदर्भ देते हैं, तो यह आवश्यक नहीं है (इस लेख को पढ़िए मुखबिर / बयान / लेख.प्रा . ? ==2020371&seqNum=4 )

— क्रिस्टोफ

Answer 2

जैसा कि मैंने देखा है, आप इसे दो तरीकों में से एक में हल कर सकते हैं:

श्रेणी एक विशेष प्रकार का उत्पाद है

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

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

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

इसका नकारात्मक पहलू यह है कि उत्पाद में मौजूद अतिरिक्त जानकारी जो किसी श्रेणी के लिए समझ में नहीं आती है, वह उत्पाद में अजीब अप्रयुक्त क्षेत्रों का निर्माण करेगी। जबकि यह समाधान आपके आवेदन में अधिक लचीला होगा, यह कुछ हद तक सहज भी है।

कई-कई रिश्ते

प्रॉपर्टी के साथ उत्पाद अब समग्र संबंध में नहीं हैं। आप उत्पाद तालिका और प्रॉपर्टी टेबल दोनों की विदेशी कुंजियों के साथ एक ProductProperty टेबल बनाते हैं जो दोनों को लिंक करती है। इसी तरह, आपके पास संपत्ति तालिका और श्रेणी तालिका और संपत्ति तालिका दोनों की विदेशी कुंजियों के साथ श्रेणीबद्धता तालिका के साथ कई-से-कई संबंध वाली एक श्रेणी तालिका है।

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

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

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

निष्कर्ष

एक पेशेवर संदर्भ में, मैं कई-कई दृष्टिकोण का उपयोग करके संपत्ति से उत्पाद और उत्पाद से अतिरिक्त मील और दूरी की श्रेणी में जाऊंगा। डेटा के ओवरलैप होने की कोई संभावना नहीं होगी, और एक अर्थ में, इन तीनों में से प्रत्येक को अपनी इकाई के रूप में समझना आसान है। हालाँकि, किसी भी तरह से पहला समाधान बुरा नहीं है क्योंकि यह आपको एक सरल अनुप्रयोग लिखने की सुविधा देता है। बस यह जान लें कि अगर आपको लगता है कि आपको अंततः एक समाधान से दूसरे समाधान में स्थानांतरित करने की आवश्यकता हो सकती है, तो संभवतः दूसरे को चुनना आपके सर्वोत्तम हित में होगा।

सौभाग्य!

Comments

विस्तृत और दिलचस्प जवाब के लिए धन्यवाद! डेटाबेस स्तर पर मैंने पहले ही मॉडलिंग की है जैसा कि आपने दूसरे मामले में समझाया था, इस पैटर्न को इकाई-विशेषता-मूल्य कहा जाता है, लेकिन मैं कोड स्तर पर अर्थात् एग्रीगेट की परिभाषा पर अटका हुआ हूं। ज्यादातर मामलों में, इन सभी संस्थाओं का एक साथ उपयोग किया जाता है। एक समुच्चय में संयोजन करना संभव है, लेकिन ऐसे मामले हैं जो निर्देशिकाओं को भरना पसंद करते हैं जो समझदारी से समुच्चय से बाहर हो जाते हैं।

— सेफेई