डोमेन क्या है?


104

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


12
दुर्भाग्य से मुझे लगता है कि यह उन शब्दों में से एक है जिनकी स्पष्ट परिभाषा नहीं है और अस्पष्ट संदर्भों में इसका उपयोग किया जाता है। हालांकि यह पर्याप्त देखने के बाद, आप एक समझ हासिल करते हैं। मेरा कहना यह है कि आपको यहाँ देखे गए सभी उत्तरों को पढ़ने के बाद भी इसके उपयोग को समझने की उम्मीद नहीं करनी चाहिए। इसमें समय लगेगा।
आचार्य

15
@aaaaaa बिल्कुल ... हम्प्टी डम्प्टी अवमानना ​​से मुस्कुराई। ... "जब मैं एक शब्द का उपयोग करता हूं," हम्प्टी डम्प्टी ने बल्कि एक कर्कश स्वर में कहा, "इसका मतलब सिर्फ इतना है कि मैं इसका मतलब क्या चुनूं- न तो अधिक और न ही कम।"
एमोरी

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

जवाबों:


9

एरिक इवांस द्वारा डोमेन ड्रिवेन डिज़ाइन पुस्तक में "डोमेन" शब्द का विशिष्ट अर्थ है। यह सॉफ्टवेयर के बारे में बात है।

इवांस हालांकि आगे बढ़ जाता है। उनके विचार में एक ही सॉफ्टवेयर के साथ उप डोमेन भी हैं। और यह पुस्तक का एक हिस्सा है जो "सामरिक डिजाइन" से संबंधित है।

तीन "डोमेन" हैं: कोर डोमेन, सहायक डोमेन, और सामान्य डोमेन। कभी-कभी वह इन्हें उप-डोमेन के रूप में संदर्भित करेगा।

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

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

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

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

व्यवसाय के दृष्टिकोण से यह तय करना महत्वपूर्ण है कि आपका मुख्य डोमेन क्या है और अपने विकास संसाधनों पर ध्यान केंद्रित करें। इवांस के पास कई वीडियो हैं, खासकर इन्फोक्यू साइट पर, जहां वह इन अवधारणाओं को अधिक विस्तार से बताते हैं।

इसलिए जब हम अक्सर सॉफ़्टवेयर में "डोमेन" के बारे में बात करते हैं, तो डीडीडी के मामले में, यह उतना सरल नहीं है जितना यह लग सकता है।

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


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

@nocomprende नहीं, ये अवधारणाएं किसी विशेष संगठन में किसी विशेष समय में एक विशेष सॉफ्टवेयर के लिए विशिष्ट हैं। तो MSFT विंडोज के लिए मुख्य डोमेन बाजार की स्थितियों, ग्राहकों की अपेक्षाओं, आदि के आधार पर अलग होगा
रिबल्डएडिएडी

1
मुझे लगता है कि यह मुझे पुरानी कहावत की याद दिलाता है: "2 प्रकार के लोग हैं: वे जो लोगों को दो प्रकारों में विभाजित करते हैं, और वे जो नहीं करते हैं।" लेकिन ... दूसरे प्रकार के लोगों के लिए केवल एक ही तरह के लोग होंगे ... - अनंत अप्रत्यक्ष त्रुटि - सिस्टम रुका

@nocomprende क्षमा करें, मैं वास्तव में आपकी पहली टिप्पणी को नहीं समझ पाया था- सॉफ्टवेयर विकास के मुख्य डोमेन पर "सहमत" का हिस्सा एक मजाक था।
रिबल्डएडीडी

109

डोमेन वास्तविक दुनिया का संदर्भ है जिसमें आप सॉफ्टवेयर का उपयोग कर एक समस्या को हल करने का प्रयास कर रहे है। प्रत्येक डोमेन विशेषज्ञता, शब्दावली और उपकरण के साथ आता है जो उस डोमेन का हिस्सा हैं।

एक डोमेन का एक विशिष्ट उदाहरण कुछ ऐसा हो सकता है "उच्च गति वाले घूर्णन कटर का उपयोग करके जटिल भागों के स्वचालित मशीनिंग।" सॉफ्टवेयर और हार्डवेयर सिस्टम जो इसे पूरा करता है उसे सीएनसी मिल कहा जाता है ।

एक डोमेन का एक अन्य उदाहरण एक निगम में लेखा विभाग है।

आगे पढ़ना
मार्टिन फाउलर द्वारा प्रसंगबद्ध बन्धन


4
हाँ। जब आप "डोमेन" पढ़ते हैं, तो आप संभवतः स्थानापन्न कर सकते हैं "(एक निश्चित) विशेषज्ञता या चिंता का क्षेत्र"।
KlaymenDK

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

1
@ user251748 - ठीक है, मुझे लगता है कि यह मनुष्यों के बारे में है, और वे जिन प्रक्रियाओं में शामिल हैं, बस जरूरी नहीं कि लोग तुरंत क्या समझें।
सिपो

38

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


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

@YetAnotherRandomUser - मेरे लिए, यह बहुत स्पष्ट है कि उसका क्या मतलब है। ;)
सिपो

19

एक डोमेन ज्ञान का एक क्षेत्र है। हालांकि यह एक गतिविधि के रूप में हो सकता है जिसमें आपके सॉफ़्टवेयर द्वारा हल की गई समस्याएं मौजूद हैं। ( विकी , डीडीडी समुदाय )

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

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

सीधे शब्दों में कहें: एक डोमेन वह है जहाँ आप व्यवसाय करते हैं । यदि आपका व्यवसाय शिपिंग कार्गो है - शिपिंग कार्गो आपका डोमेन होगा। यदि आपका व्यवसाय कर्मियों को प्रमाणित करने और अधिकृत करने में है तो यह आपका डोमेन होगा।


7

से डोमेन संचालित डिजाइन: सॉफ्टवेयर के हार्ट में जटिलता से निपटना , एरिक इवांस:

प्रत्येक सॉफ़्टवेयर प्रोग्राम अपने उपयोगकर्ता की कुछ गतिविधि या रुचि से संबंधित है। वह विषय जिस पर उपयोगकर्ता प्रोग्राम लागू करता है , सॉफ्टवेयर का डोमेन है।

एयरलाइन बुकिंग कार्यक्रम के डोमेन में वास्तविक लोगों को वास्तविक विमान में शामिल करना शामिल है।

एक लेखा कार्यक्रम का डोमेन पैसा और वित्त है।

स्रोत-कोड नियंत्रण प्रणाली का डोमेन सॉफ्टवेयर विकास ही है।

डोमेन मॉडल, तब "एक कड़ाई से संगठित और चयनात्मक अमूर्तता" है जो एक डोमेन विशेषज्ञ के सिर में ज्ञान है।

पलेर्मो ने प्याज वास्तुकला का वर्णन करते हुए, इस सारांश की पेशकश की

बहुत केंद्र में हम डोमेन मॉडल देखते हैं, जो संगठन के लिए राज्य और व्यवहार संयोजन का प्रतिनिधित्व करता है जो मॉडल सत्य है।

बदले में, Fowler प्रदान करता है

डोमेन का एक ऑब्जेक्ट मॉडल जो व्यवहार और डेटा दोनों को शामिल करता है।

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


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

2

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

मैं डोमेन के अपने दृष्टिकोण को डालने के साथ शुरू करता हूं।

डोमेन

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

उप डोमेन

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

डोमेन मॉडल

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

बंधे हुए संदर्भ

सबसे महत्वपूर्ण बात यह है कि बंधे हुए संदर्भ एक तार्किक सीमा है।

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

आगे क्या होगा?

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


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

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

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

1
कंप्यूटर वास्तविक चीजों के बारे में मॉडलिंग करते हैं। बस एक और क्षेत्र जहां वास्तविक चीजें हो सकती हैं, वास्तविक व्यापार-प्रक्रियाएं लागू की जा सकती हैं, वास्तविक व्यापार-बाधाएं लागू की जा सकती हैं। लेकिन, 50 साल पहले मैंने एक स्टोर में कैशियर को $ 1 का भुगतान किया था, अब खरीदने की पूरी प्रक्रिया इंसान के साथ बातचीत किए बिना हो सकता है। फिर भी मेरे असली पैसे मेरे असली बैंक खाते से निकाल लिए गए। तो यह कोई फर्क नहीं पड़ता कि किसी भी प्रक्रिया, कंप्यूटर या मानव या एसएमएस में क्या शामिल है। : शायद यह आप के लिए कुछ ब्याज की हो सकता है medium.com/@wrong.about/...

पैसा असली नहीं है। व्यावसायिक प्रक्रियाएं वास्तविक नहीं हैं। हम जिस चीज के बारे में बात कर सकते हैं वह एक अवधारणा है, वास्तविक नहीं।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.