जिस भाषा में आप प्रोग्रामिंग कर रहे हैं उस बाहरी डेटा का अनुवाद

Question

मुझे यकीन नहीं है कि निम्नलिखित के साथ क्या करना है:

हम अपने स्वयं के उपकरण के भीतर एक बाहरी उपकरण से डेटा लेते हैं। यह डेटा डच में लिखा गया है। हम अपना जावा कोड अंग्रेजी में लिख रहे हैं। क्या हमें इस डच का अंग्रेजी में अनुवाद करना चाहिए या इसे डच रखना चाहिए? उदाहरण के लिए, हमारे पास 2 विभाग हैं: बूव (अंग्रेजी में निर्माण) और ओंदरहौड (अंग्रेजी में रखरखाव)।

क्या तब इसे बनाना तर्कसंगत होगा:

public enum Department { BOUW, ONDERHOUD }

या:

public enum Department { CONSTRUCTION, MAINTENANCE }

या और भी:

public enum Afdeling { BOUW, ONDERHOUD }

(afdeling डच में विभाग है)

Comments

गैर-अंग्रेजी नामकरण सम्मेलनों

— gnat

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

— जेले

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

— kayleeFrye_onDeck

क्या आपके बाकी कार्यक्रम (मानक पुस्तकालयों के अलावा) अंग्रेजी या डच पहचानकर्ताओं का उपयोग करते हैं?

— user253751

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

— जेले

Answer 1

इस परिदृश्य में, मैं enum मानों को डच में छोड़ दूंगा :

public enum Department { BOUW, ONDERHOUD }

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

if (Department.BOUW == input.toUpper())

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

फिर भी, आप कोड को टिप्पणी कर सकते हैं यदि यह दूसरों को डेटा के संदर्भ को समझने में मदद करता है:

public enum Department { 
    BOUW, /* build */
    ONDERHOUD /* maintenance */
}

Comments

@ निश्चित रूप से, यदि आप कभी भी अंतरराष्ट्रीय स्तर पर विस्तार करते हैं, तो आप वैसे भी अनुवाद तर्क से खुश हो सकते हैं। YAGNI पर YMMV।

— विलीहम टोटलैंड

आप अपने enums की तुलना वैसे भी सीधे तार से न करें। क्या होगा यदि आपको एक स्ट्रिंग की तुलना एनम मान के साथ कई शब्दों से करनी है?

— जोर्जेन फॉग

मैं कभी भी .toUpper () और == का उपयोग करके तार की तुलना नहीं करूंगा, खासकर जब उपयोगकर्ता-इनपुट और स्थानीयकृत तार के साथ काम कर रहा हो। इस का स्कूल-पुस्तक उदाहरण तुर्की "i" वर्ण है।

— एड्रियनो रेपेट्टी

@ABoschman लाइन टिप्पणियों का अंत सार्वभौमिक रूप से उस पंक्ति का संदर्भ देता है जिस पर वे हैं। मैंने सैकड़ों बार सूची मदों के सरल विवरणों के लिए यह टिप्पणी प्रकार देखा है ...

— StarWeaver

हमारी दुकान में, हम यहां सुझाए गए कार्यों के विपरीत करते हैं: enum / const नाम अंग्रेजी में हैं (या अंग्रेजी के लिए क्या गुजरता है), और टिप्पणियां "स्थानीयकृत" हैं। कौन सा अच्छा है। अन्यथा हम इन सभी आधारों को नामों के साथ पसंद करेंगे PAAMAYIM_NEKUDOTAYIM।

— sq33G

Answer 2

अंग्रेजी एक कारण के लिए एक भाषा / सबसे सामान्य सामान्य भाषा है। भले ही इसका कारण वैचारिक रूप से उतना ही कमजोर हो जितना "हर कोई करता है", यह अभी भी एक महत्वपूर्ण कारण है।

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

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

नोट: यह सलाह केवल प्रोग्राम कोड पर लागू होती है । उपयोगकर्ता डेटा निश्चित रूप से अनुवादित नहीं होना चाहिए, लेकिन "जैसा है" संसाधित है। यहां तक ​​कि अगर आपके पास एक ग्राहक "गोल्डस्टीन" है, तो स्पष्ट रूप से आपको उनका नाम "गोल्डन स्टोन" के रूप में नहीं रखना चाहिए।

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

Comments

+1, उस मामले में अंग्रेजी का उपयोग करने से आपको कोड पठनीयता और पुन: प्रयोज्यता मिलती है, जिसका इस उत्तर में खुलासा किया गया है। इसे बनाते समय डच ने उन्हें किसी तरह से तोड़ दिया।

— मिखाइल चुर्बनोव

@ जेले नाम कोड के लिए एक अर्थ महत्व रखता है? यदि हाँ, तो इसका अनुवाद करें - आपको वैसे भी अवधारणा का अनुवाद चाहिए। यदि नहीं, तो आपके पास enumइसके लिए क्यों है ? यह केवल एक संकेत हो सकता है कि आप कोड में डेटा को मॉडल करने की कोशिश कर रहे हैं, जो एक बुरा विचार हो सकता है।

— लुअन

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

— 22

मैंने अपने प्रोजेक्ट लीडर से यह भी सुना कि किसी अन्य प्रोजेक्ट पर, डेवलपर्स हम डच से अंग्रेज़ी में कुछ डोमेन ऑब्जेक्ट्स का अनुवाद कर रहे हैं, और यह बाद में प्रोजेक्ट में अस्पष्ट हो गया कि इन कस्टम अनुवादों के कारण इन वस्तुओं का क्या मतलब है।

— जेले

@Rhymoid और Jelle द्वारा टिप्पणियों को फिर से पढ़ें। डोमेन शब्दावली का अपना अनुवाद कभी न करें! यदि आप डच-नामित संस्थाओं के लिए अंग्रेजी शब्दों का उपयोग करने का निर्णय लेते हैं, तो आधिकारिक अनुवाद का उपयोग करना सुनिश्चित करें, अपना नहीं।

— गुरन

Answer 3

जहां संभव हो अनुवाद से बचें, क्योंकि हर अनुवाद अतिरिक्त प्रयास है और बग का परिचय दे सकता है।

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

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

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

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

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

यदि आप किसी भी तरह से अनुवाद करना चाहते हैं, तो कृपया एक शब्दावली में अनुवाद का मानकीकरण करें, उस शब्दावलियों का अनुपालन अपनी परिभाषा के अनुसार करें, और अपनी समीक्षाओं में इसकी जाँच करें। हम जितने लापरवाह रहे हैं उतने लापरवाह न बनें।

Comments

व्यवसाय विशेषज्ञ अंग्रेजी बोलेंगे। कार्यबल में शिक्षित डच के बीच अंग्रेजी दक्षता 100% है।

— एमएसएल

अंग्रेजी बोलना एक बात है। अंग्रेजी में डच डोमेन शब्दावली के गुणवत्ता अनुवाद करने में सक्षम होने के कारण काफी अन्य है।

— गुरुनान

@ दलाल: किस स्तर पर प्रवीण? जिस परियोजना के बारे में मैंने बात की थी, उस पर हर कोई अंग्रेजी बोलने में सक्षम था, लेकिन वे जर्मन की तरह कुशल नहीं थे। उदाहरण के लिए, एक ऐसी विधि थी getAdminRollजिसने व्यवस्थापक भूमिका की जाँच की ... (जर्मन शब्द "रोले" है, और उन्होंने गलत पत्र को छोड़ दिया :-)

— मेरिटॉन - हड़ताल पर

@ गुरन: वास्तव में, यह आमतौर पर अन्य तरीके से होता है: आपके डोमेन विशेषज्ञ अंग्रेजी व्याकरण को प्राप्त कर सकते हैं और छोटी-छोटी बातों के साथ चुनौती दे सकते हैं, लेकिन उन्हें अंग्रेजी में अपनी डोमेन शब्दावली पता होगी। प्रोग्रामर बड़ी समस्या हो सकते हैं: उनका डोमेन सॉफ्टवेयर है, जिसका अर्थ है कि वे उस शब्दावली को जानते हैं , लेकिन जरूरी नहीं कि व्यापार शब्दावली।

— MSalters

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

— MSalters 2

Answer 4

सही समाधान विभागों को हार्ड-कोड नहीं करना है:

ArrayList<String> departments = (... load them from a configuration file ...)

या, यदि आपको पूरी तरह से एक विभाग के प्रकार की आवश्यकता है:

class Department { String name; Department(String name) { this.name = name; } ... }
HashMap<String, Department> = (... generate from configuration file ...)

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

Comments

यह। क्या होता है जब एक प्रस्थान अलग हो जाता है या संयुक्त या एक नया रूप होता है? यह कोड स्वचालित रूप से कम या ज्यादा अनुकूलित होगा; इसे एक एनम में बदलने का मतलब है कि आपको एक नए निर्माण की आवश्यकता है या यह विस्फोट हो जाएगा।

— jpmc26

यह एक समाधान होगा यदि विभाग हमारे आवेदन में इतनी बड़ी भूमिका नहीं निभाते हैं। हमारे पास if (project.getDepartment().equals(Department.XYZ))बयानों की एक बहुत कुछ है ।

— जेले

@ जॅल के बारे में project.isForDepartment("XYZ"), जो बदले में डैनियल हैशमप (जो परियोजना में इंजेक्शन है, या कुछ और का उपयोग करता है)

— SáT

@ SáT, कि बस टाइपो के लिए पूछ रहा है, ईमानदारी से ...

— Jelle

@ जैल हां, लेकिन इसे रनटाइम पकड़ा जा सकता है। टेस्ट उन्हें संकलन समय में भी पकड़ सकते थे। (हालांकि मैं समझता हूं कि आप कहां से आ रहे हैं, और मैं इस तरह से सहमत हूं।)

— SáT

Answer 5

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

/** The possible departments of a project, given in the Dutch language. */
public enum Department { BOUW, ONDERHOUD }

Comments

खुशी है कि आपको एक संतोषजनक दृष्टिकोण मिला। , स्वीकृत उत्तर आपके चुने हुए दृष्टिकोण से भिन्न प्रतीत होता है, हालाँकि। कृपया अपने चुने हुए दृष्टिकोण के साथ मेल खाने वाले दूसरों में से किसी एक के लिए स्वीकृत उत्तर को बदलने पर विचार करें।

— बिशप

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

— जेले

Answer 6

यदि आप उपयोगकर्ता या कुछ दिखाने के लिए एक स्ट्रिंग प्रतिनिधित्व करने के बारे में चिंतित हैं, तो बस अपने एनम के अंदर एक विवरण सरणी को परिभाषित करें और एक विधि को उजागर करें।
जैसे: Department.BUILD.getDescription();"BOUW" का उत्पादन करेगा

public enum Department { 
    BUILD,
    MAINTENANCE;

    private String[] descriptions = new String[] {
        "BOUW",
        "ONDERHOUD"
    };

    public String getDescription() {
        return descriptions[ordinal()];
    }
}

मुझे पता है कि आपने अन्यथा को चुना है, लेकिन सिर्फ दुर्घटना के कारण Google भंवर यहां लोगों को फेंकता है।

EDIT: जैसा कि Pokechu22 द्वारा नोट किया गया है आप इस तरह से एनम कंस्ट्रक्टर्स और निजी संपत्तियों का उपयोग कर सकते हैं:

public enum Department {
    BUILD("BOUW"),
    MAINTENANCE("ONDERHOUD");

    private final String description;

    private Department(String description) {
        this.description = description;
    }

    public String getDescription() {
        return description;
    }
}

जो उस प्रभाव को भी प्राप्त करेगा।

Comments

आप एक सरणी की जरूरत नहीं है। जावा में, enums में (निजी) कंस्ट्रक्टर और फ़ील्ड हो सकते हैं।

— पोखचू 22

@ Pokechu22, लेकिन क्या मूल्य या निर्माण में उपलब्ध है यह विवरण के साथ मिलान करने में सक्षम हो सकता है? मेरा मतलब है, आपको अभी भी सही वर्णन करने के लिए डे कंस्ट्रक्टर के अंदर एक सरणी की आवश्यकता होगी?

— स्पार्क

नहींं, आप इसे इस तरह से कर सकते हैं:public enum Department { BUILD("BOUW"), MAINTENANCE("ONDERHOUD"); private final String description; private Department(String description) { this.description = description; } public String getDescription() { return description; } }

— प्रोक्यू 2222

@ Pokechu22 जवाब में जोड़ा गया। मैंने यह भी देखा कि सरणी बढ़ने पर, मेरा कार्यान्वयन हर बार 2 लाइनों द्वारा टूट और बढ़ सकता है, जबकि आपका 1 लाइन बढ़ेगा और संदर्भ नहीं तोड़ेंगे।

— स्पार्क

Answer 7

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

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

इस प्रकार, यह बात नहीं होनी चाहिए कि आप एनम के सदस्यों को क्या नाम देते हैं। कि वे आपके द्वारा पढ़े गए आंकड़ों में प्रयुक्त तार के साथ मेल खाते हैं।

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

पार्सर डेटा स्वरूप और आपके डोमेन मॉडल के बीच अनुवाद करता है। आपके कोड पर डेटा प्रारूप का प्रभाव अंतिम होना चाहिए।