मेरी राय में, यह बिल्कुल नहीं है कि यह कैसे मतलब है। और यह DRY का उल्लंघन है।
विचार यह है कि बीच में इकाई / डोमेन ऑब्जेक्ट को डोमेन को अच्छे और यथासंभव सुविधाजनक बनाने के लिए मॉडल किया गया है। यह सब कुछ के केंद्र में है और सब कुछ इस पर निर्भर कर सकता है क्योंकि डोमेन स्वयं अधिकांश समय नहीं बदलता है।
यदि बाहर की ओर आपका डेटाबेस उन वस्तुओं को सीधे स्टोर कर सकता है, तो उन्हें अलग-अलग परतों की खातिर किसी अन्य प्रारूप में मैप करना न केवल व्यर्थ है, बल्कि मॉडल के डुप्लिकेट बनाना है और यह इरादा नहीं है।
शुरू करने के लिए, साफ वास्तुकला को एक अलग विशिष्ट वातावरण / परिदृश्य को ध्यान में रखते हुए बनाया गया था। बीमेथ बाहरी परतों के साथ व्यावसायिक सर्वर अनुप्रयोग जिनके लिए विशेष प्रकार की विशेष वस्तुओं की आवश्यकता होती है। उदाहरण के लिए डेटाबेस जो SQLRowवस्तुओं का उत्पादन करते हैं और SQLTransactionsआइटम को अपडेट करने के बदले में आवश्यकता होती है। यदि आप केंद्र में उन का उपयोग करने के लिए थे, तो आप निर्भरता दिशा का उल्लंघन करने वाले थे क्योंकि आपका कोर डेटाबेस पर निर्भर करेगा।
हल्के ओआरएम के साथ जो ऑब्जेक्ट को लोड और स्टोर करते हैं, ऐसा नहीं है। वे अपने आंतरिक SQLRowऔर आपके डोमेन के बीच मैपिंग करते हैं। यहां तक कि अगर आपको @Entitiyअपने डोमेन ऑब्जेक्ट में ORM का एनोटेशन डालने की आवश्यकता है , तो मैं तर्क दूंगा कि यह बाहरी परत का "उल्लेख" स्थापित नहीं करता है। क्योंकि एनोटेशन केवल मेटाडेटा हैं, कोई भी कोड जो विशेष रूप से उनकी तलाश नहीं कर रहा है उन्हें देखेगा। और इससे भी महत्वपूर्ण बात, यदि आप उन्हें हटाते हैं या उन्हें अलग डेटाबेस के एनोटेशन के साथ बदलने की आवश्यकता नहीं है।
इसके विपरीत, यदि आप अपना डोमेन बदलते हैं और आपने उन सभी मैपर्स को बनाया है, तो आपको बहुत कुछ बदलना होगा।
संशोधन: ऊपर एक छोटा सा निरीक्षण है और गलत भी हो सकता है। क्योंकि स्वच्छ वास्तुकला में एक हिस्सा है जो आपको प्रति परत एक प्रतिनिधित्व बनाना चाहता है। लेकिन उस आवेदन के संदर्भ में देखा जाना चाहिए।
निम्नलिखित यहाँ https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean- RGBecture.html
महत्वपूर्ण बात यह है कि सीमाओं के पार पृथक, सरल, डेटा संरचनाएं हैं। हम Entities या डेटाबेस पंक्तियों को धोखा और पारित नहीं करना चाहते हैं। हम नहीं चाहते हैं कि डेटा संरचनाओं में किसी भी प्रकार की निर्भरता हो जो निर्भरता नियम का उल्लंघन करती हो।
बाहरी परतों की ओर केंद्र से गुजरने वाली संस्थाएं निर्भरता नियम का उल्लंघन नहीं करती हैं, फिर भी उनका उल्लेख किया जाता है। लेकिन यह कल्पना किए गए आवेदन के संदर्भ में एक कारण है। आस-पास की इकाइयाँ बाहर की ओर अनुप्रयोग तर्क को स्थानांतरित करेंगी। बाहरी परतों को यह जानने की आवश्यकता होगी कि आंतरिक वस्तुओं की व्याख्या कैसे करें, उन्हें प्रभावी रूप से यह करना होगा कि "उपयोग के मामले" परत जैसी आंतरिक परतों को क्या करना है।
इसके अलावा, यह परतों को भी कम कर देता है, ताकि कोर में बदलाव के लिए बाहरी परतों में बदलाव की आवश्यकता न हो (देखें स्टीवक्लेनडर की टिप्पणी)। उस संदर्भ में, यह देखना आसान है कि वस्तुओं को विशेष रूप से उस उद्देश्य का प्रतिनिधित्व करना चाहिए जिसका वे उपयोग करते हैं। इसके अलावा, परतों को उन वस्तुओं के संदर्भ में एक दूसरे से बात करनी चाहिए जो विशेष रूप से इस संचार के उद्देश्य से बनाई गई हैं। इसका मतलब यह भी हो सकता है कि परतों के बीच परिवहन के लिए प्रत्येक में 3 प्रतिनिधित्व, 1 हैं।
और वहाँ https://blog.8thlight.com/uncle-bob/2011/11/22/Clean-Architecture.html पते हैं:
अन्य लोगों ने चिंतित किया है कि मेरी सलाह का शुद्ध परिणाम बहुत सारे डुप्लिकेट किए गए कोड होंगे, और सिस्टम की परतों के पार एक डेटा संरचना से दूसरे में डेटा की बहुत सारी नकल। निश्चित रूप से मुझे यह नहीं चाहिए; और मैंने जो कुछ भी सुझाया है वह अनिवार्य रूप से डेटा संरचनाओं की पुनरावृत्ति और क्षेत्र की नकल का एक कारण होगा।
उस IMO का तात्पर्य है कि वस्तुओं की 1: 1 कॉपी करना वास्तुकला में एक गंध है क्योंकि आप वास्तव में उचित परतों और / या अमूर्त का उपयोग नहीं कर रहे हैं।
बाद में उन्होंने बताया कि कैसे वे सभी "नकल" की कल्पना करते हैं
आप दोनों के बीच सरल डेटा संरचनाओं को पारित करके यूआई को व्यावसायिक नियमों से अलग करते हैं। आप अपने नियंत्रकों को व्यावसायिक नियमों के बारे में कुछ भी बताने नहीं देते हैं। इसके बजाय, नियंत्रक एक साधारण वेनिला डेटा संरचना में HttpRequest ऑब्जेक्ट को अनपैक करते हैं, और फिर उस डेटा संरचना को एक इंटरेक्टर ऑब्जेक्ट में पास करते हैं जो व्यावसायिक वस्तुओं को लागू करके उपयोग के मामले को लागू करता है। इंटरेक्टर तब प्रतिक्रिया डेटा को एक अन्य वेनिला डेटा संरचना में इकट्ठा करता है और इसे यूआई में वापस भेजता है। व्यापारिक वस्तुओं के बारे में विचार नहीं जानते हैं। वे केवल उस डेटा संरचना को देखते हैं और प्रतिक्रिया प्रस्तुत करते हैं।
इस एप्लिकेशन में, अभ्यावेदन के बीच एक बड़ा अंतर है। जो डेटा प्रवाहित होता है वह केवल इकाइयाँ नहीं है। और यह वारंट और विभिन्न वर्गों की मांग करता है।
हालाँकि, फोटो दर्शक की तरह एक साधारण एंड्रॉइड एप्लिकेशन पर लागू किया जाता है, जहां Photoइकाई के पास लगभग 0 व्यावसायिक नियम और "उपयोग का मामला" है, जो उनके साथ व्यवहार करता है, लगभग गैर-मौजूद है और वास्तव में कैशिंग और डाउनलोडिंग के बारे में अधिक चिंतित है (यह प्रक्रिया IMO होनी चाहिए। अधिक स्पष्ट रूप से प्रतिनिधित्व किया गया), एक तस्वीर के अलग-अलग प्रतिनिधित्व करने का बिंदु गायब होने लगता है। मुझे यह भी महसूस हो रहा है कि फोटो ही डेटा ट्रांसफर ऑब्जेक्ट है जबकि असली बिजनेस-लॉजिक-कोर-लेयर गायब है।
"दोनों के बीच सरल डेटा संरचनाओं को पारित करके" व्यापार के नियमों से यूआई को अलग करने के बीच एक अंतर है " और जब आप रास्ते में 3 बार एक फोटो का नाम बदलना चाहते हैं" ।
इसके अलावा, जिस बिंदु पर मैं उन डेमो एप्लिकेशन को साफ आर्किटेक्चर का प्रतिनिधित्व करने में विफल रहता हूं, वह यह है कि वे परतों को अलग करने के लिए परतों को अलग करने पर बहुत जोर देते हैं लेकिन प्रभावी रूप से यह छिपाते हैं कि एप्लिकेशन क्या करता है। जो कि https://blog.8thlight.com/uncle-bob/2011/09/30/Screaming-Architecture.html - अर्थात् में कही गई बातों के विपरीत है
एक सॉफ्टवेयर अनुप्रयोग की वास्तुकला अनुप्रयोग के उपयोग के मामलों के बारे में चिल्लाती है
मैं साफ वास्तुकला में परतों को अलग करने पर जोर नहीं देता। यह निर्भरता दिशा के बारे में है और आवेदन के मूल का प्रतिनिधित्व करने पर ध्यान केंद्रित कर रहा है - संस्थाओं और उपयोग के मामले - आदर्श रूप से सादे जावा में बाहर की ओर निर्भरता के बिना। यह उस कोर के प्रति निर्भरता के बारे में इतना नहीं है।
इसलिए यदि आपके आवेदन में वास्तव में एक कोर है जो व्यावसायिक नियमों का प्रतिनिधित्व करता है और मामलों का उपयोग करता है, और / या विभिन्न लोग विभिन्न परतों पर काम करते हैं, तो कृपया उन्हें इच्छित तरीके से अलग करें। अगर आप दूसरी तरफ हैं तो बस एक साधारण ऐप लिखिए। धाराप्रवाह सीमा के साथ 2 परतें पर्याप्त से अधिक हो सकती हैं। और परतों को बाद में भी जोड़ा जा सकता है।
BankAccountलेकिन एप्लिकेशन विशिष्ट नियमों के साथ आप उस खाते के साथ क्या कर सकते हैं।