डीडीडी समुच्चय के क्रमांकन के लिए सर्वोत्तम अभ्यास


23

डीडीडी के अनुसार डोमेन लॉजिक को तकनीकी चिंताओं जैसे क्रमबद्धता, ऑब्जेक्ट-रिलेशनल मैपिंग, आदि से प्रदूषित नहीं किया जाना चाहिए।

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

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

तो यहाँ पालन करने के लिए सबसे अच्छा समझौता क्या है? सार्वजनिक एक्सेसर्स के साथ रहते हैं, लेकिन कोडिंग और कोडिंग के लिए उनका उपयोग करने से बचें? या मुझे कुछ स्पष्ट याद आया?

मैं स्पष्ट रूप से DDD डोमेन ऑब्जेक्ट्स की स्थिति को क्रमबद्ध करने में रुचि रखता हूं (संस्थाओं और मूल्य वस्तुओं से मिलकर कुल)। यह सामान्य या ट्रांसक्रिपशन स्क्रिप्ट परिदृश्यों में क्रमांकन के बारे में नहीं है जहां स्टेटलेस सेवाएं सरल डेटा कंटेनर ऑब्जेक्ट्स पर काम करती हैं।

जवाबों:


12

वस्तुओं का प्रकार

हमारी चर्चा के उद्देश्यों के लिए, हमारी वस्तुओं को तीन अलग-अलग प्रकारों में विभाजित करें:

व्यापार डोमेन तर्क

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

डोमेन लॉजिक ऑब्जेक्ट को आमतौर पर एक्सेसर्स (गेटर्स और सेटर) की आवश्यकता नहीं होती है। इसके बजाय, आप एक निर्माता के माध्यम से निर्भरता सौंपकर ऑब्जेक्ट बनाते हैं, और फिर विधियों के माध्यम से ऑब्जेक्ट को हेरफेर करते हैं (बताओ, मत पूछो)।

डेटा ट्रांसफर ऑब्जेक्ट्स

डेटा ट्रांसफर ऑब्जेक्ट्स शुद्ध स्थिति हैं; उनके पास कोई व्यावसायिक तर्क नहीं है। उनके पास हमेशा एक्सेसर्स होंगे। हो सकता है या नहीं, वे इस बात पर निर्भर करते हैं कि आप उन्हें अपरिवर्तनीय तरीके से लिख रहे हैं या नहीं । आप या तो अपने फ़ील्ड को कंस्ट्रक्टर में सेट करेंगे और उनका मान ऑब्जेक्ट के जीवनकाल के लिए नहीं बदलेगा, या आपके एक्सेसर्स को पढ़ा / लिखा जाएगा। व्यवहार में, ये वस्तुएं आमतौर पर परिवर्तनशील होती हैं, ताकि एक उपयोगकर्ता उन्हें संपादित कर सके।

मॉडल ऑब्जेक्ट देखें

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

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

क्रमांकन, निर्भरता और युग्मन

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

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

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


मैं डिकॉउलिंग पर आपके विचार से सहमत हूं। सीरिज़र डोमेन ऑब्जेक्ट पर निर्भर करता है और यह ठीक है। लेकिन दूसरा रास्ता नहीं। हालांकि, डोमेन ऑब्जेक्ट्स पर सार्वजनिक एक्सेसर्स पर आपके विचार से मैं असहमत हूं। व्यवहार में वे अक्सर उनके पास होते हैं, हाँ। लेकिन IMO यह एक स्वच्छ ऑब्जेक्ट-ओरिएंटेड डिज़ाइन में डोमेन लॉजिक को लागू करने के लिए बेहतर होगा: बताओ, मत पूछो । लेकिन फिर भी आपको मैपिंग उद्देश्यों (ORM, क्रमांकन, GUI ...) के लिए एक्सेसर्स की आवश्यकता होती है। और अगर संभव हो तो मैं इससे बचना चाहूंगा।
ईगलबेक

यदि आपके पास एक्सेसर्स नहीं हैं, तो आप अपने खेतों तक पहुँचने की योजना कैसे बनाते हैं?
रॉबर्ट हार्वे

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

1
यह मूल रूप से अनसुलझी समस्या है - आप डीटीओ को उजागर करने के लिए एक ही समय में एनकैप्सुलेशन, डिकॉप्लिंग और क्रमांकन \ एन्कोडिंग नहीं कर सकते हैं, एक समझौता प्राप्त करने का एक तरीका है। हालाँकि, बहुत कम घुसपैठ वाले तरीके हैं: yegor256.com/2016/07/06/data-transfer-object.html
Basilevs

1
यह एनकैप्सुलेशन को गिराता है, कोई भी व्यक्ति ऑब्जेक्ट के इंटर्नल्स को पढ़ने के लिए मित्र वर्ग को लागू या उपयोग कर सकता है,।
बसिलेव्स

-1

क्रमबद्धता का अंतर्निहित उद्देश्य यह सुनिश्चित करना है कि एक प्रणाली द्वारा उत्पादित डेटा एक या अधिक संगत प्रणालियों द्वारा उपभोग किया जा सके।

क्रमबद्धता के लिए सबसे आसान और सबसे मजबूत दृष्टिकोण डेटा को एक प्रकार के अज्ञेय प्रारूप में अनुवाद करना है जो संरचना को सरल और आसान उपभोग के प्रारूप में बनाए रखता है। उदाहरण के लिए सबसे सर्वव्यापी क्रमांकन प्रारूप (यानी JSON, XML) एक अच्छी तरह से परिभाषित पाठ-आधारित प्रारूप का उपयोग करते हैं। पाठ का उत्पादन, प्रसारण और उपभोग करने के लिए सरल है।

इन प्रारूपों में से एक का उपयोग करने के 2 कारण आदर्श नहीं हो सकते हैं।

  1. दक्षता

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

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

  2. शुद्धता

    इस धारा से डेटा को क्रमबद्ध / डिसेरिएलाइज़ करने के लिए आवश्यक कास्टिंग, डेटा प्रकार से अज्ञेय प्रकार के परिणाम के लिए सटीक है।

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

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


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

@EagleBeak ओह, मुझे नहीं पता था कि आपकी चिंता विशेष रूप से निजी सदस्यों को संभालने के बारे में थी। आपके मामले में आप बाइनरी में अनुक्रमित कर सकते हैं (यह मानते हुए कि प्राप्त सिस्टम उसी नियम / संरचना का पालन करता है जो डोमेन ऑब्जेक्ट्स के तहत बनाया गया था) या कुछ तर्क लिखें जो केवल क्रमांकन से पहले सार्वजनिक डेटा को निकालते हैं।
इवान प्लाइस

मुझे लगता है कि 'सामान्य' धारणा यह है कि डेटा को एक सामान्य उद्देश्य प्रारूप (पूर्व xml, json) में क्रमबद्ध किया जा रहा है और यह विशेषाधिकार ACL या किसी अन्य समकक्ष के माध्यम से एपीआई के माध्यम से नियंत्रित होता है। सामान्य उद्देश्य क्रमांकन / डिसेरिएलाइज़ेशन व्यापार तर्क से डेटा को डिकूप करने की तर्ज पर एक सिस्टम से दूसरे सिस्टम पर जा रहा है।
इवान प्लाइस

मैं सार्वजनिक अभिगमकर्ताओं के बारे में सहमत हूं, जिन्हें आमतौर पर क्रमबद्ध किया जाना है। लेकिन मैं अभी भी इस बारे में अधिक जानना चाहूंगा कि यह डीडीडी से कैसे संबंधित है और डोमेन लॉजिक के एनकैप्सुलेशन पर इसका मजबूत फोकस है। क्या सभी DDD व्यवसायी केवल क्रमांकन के लिए सार्वजनिक एक्सेसर्स के माध्यम से डोमेन मॉडल की स्थिति को उजागर करते हैं (और कभी भी उनके उदाहरणों में इसका उल्लेख नहीं करते हैं)? मुझे शक है। कृपया मुझे गलत मत समझो मैं आपके इनपुट की बहुत सराहना करता हूं। यह सिर्फ इतना है कि मुझे एक अलग पहलू में दिलचस्पी है। (अब तक मुझे नहीं लगता कि मेरा सवाल बहुत अस्पष्ट है, लेकिन रॉबर्ट हार्वे का जवाब और आपका मुझे उस बारे में सोचना है ..)
ईगल बीक
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.