डीडीडी डोमेन ऑब्जेक्ट के रूप में एक दृढ़ता ऑब्जेक्ट का उपयोग करने के बजाय मुझे डोमेन ऑब्जेक्ट और एक स्थिरता ऑब्जेक्ट कब बनाना चाहिए?

Question

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

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

मुझे अपने प्रश्न के तीन मुख्य उत्तर दिखाई देते हैं।

1. हमेशा निरंतर वस्तुओं से अलग डोमेन ऑब्जेक्ट्स का उपयोग करें।
2. दृढ़ता ऑब्जेक्ट्स पर डोमेन विधियों (व्यवहार) डालने पर केवल अलग डोमेन ऑब्जेक्ट्स का उपयोग करें व्यावहारिक नहीं है।
3. सभी मामलों में डोमेन ऑब्जेक्ट्स के रूप में दृढ़ता ऑब्जेक्ट्स का उपयोग करें।

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

यहाँ मेरी निदर्शी घिरा संदर्भ है: कहते हैं कि मैं निम्नलिखित व्यापार नियमों के साथ एक कानून संहिताकरण प्रणाली है:

1. प्रत्येक कानून पुस्तकों पर वर्गीकृत किया जाना चाहिए।
2. प्रत्येक कानून में दो भागों, एक कोडिफिकेशन नंबर उपसर्ग और एक कोडिफिकेशन कोसिगिन प्रत्यय के साथ एक पहचानकर्ता है। (उदाहरण: 100-0100, 59 9-2030)।
3. कानून कोडिफिकेशन सिस्टम का उपयोग कर रहे कई कानूनी क्षेत्राधिकार हैं और वे अपने स्वयं के कोसिगिन बनाने में सक्षम होना चाहिए लेकिन कोडिफिकेशन उपसर्ग वैश्विक हैं और सामान्य तुलनात्मकता की सुविधा के लिए सभी अधिकार क्षेत्र में समान होना चाहिए।
4. कोडिफिकेशन संख्या उपसर्गों को व्यापक कोडिफिकेशन श्रेणियों में समूहीकृत किया गया है।

   table: codification 
   fields: chart_code, prefix, coassign, codification_category 
   
   table: codification_chart 
   fields: chart_code, jurisdiction_description 
   
   table: codification_category 
   fields: category, low_category_number, high_category_number, description 
   
   table: global_codification 
   fields: prefix, coassign, codification_category 
   

   : संहिताकरण श्रेणियों संख्या श्रेणी के, इस तरह के रूप 100-199, 200-299, 700-799, आदि

एक सतत मॉडल के रूप में इस घिरे संदर्भ मैं निम्नलिखित है व्यक्त करने के लिए है मुझे पता है, मुझे पहले डोमेन मॉडल से शुरू होना चाहिए। मैं एक सतत मॉडल और एक डोमेन मॉडल

मेरे डोमेन मॉडल में है मैं तीन डोमेन वस्तुओं

public Codification { 
    private String prefix, coassign; 
    codificationCategory codificationCaegory; // an enum type 
    public Codification(...) { // set private vars } 
    // getters for private variables 
} 

public CodificationChart { 
    private List<Codification> chartCodifications = new ArrayList<>(); 
    private String chartCode; 
    // public constructor to initialize private variables 
    // getters for private variables 
    public Codification addCodificationToChart(Codification){...} 
    public void removeCodificationFromChart(Codification){...} 
    public boolean checkCodificationInChart(Codification){...} 
} 

public enum CodificationCategory { 
    CIVIL, CRIMINAL, PROPERTY, CORPORATE, FAMILY, CONSUMER, ETHICS, BANKRUPTCY; 
} 

ORM वस्तुओं है:

JPA Mappings of the tables mentioned earlier with the "Entity" suffix added to their table names. 
They are omitted for brevity. 
Each one contains getters and setters like JPA Pojos do. 
If someone asks for the Persistence objects code I will post it. 

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

अपशिष्ट प्रयास यहां एक अलग डोमेन मॉडल बना रहा है? मैं देख सकता हूं कि मेरे कोडिफिकेशन ऑब्जेक्ट पर मेरे कोडिफिकेशन चार्ट व्यवहार को कैसे रखना संभव है। यह किसी भी तरह से उन व्यवहारों को एक दृढ़ वस्तु पर रखने में गलत लगता है, जो केवल नौकरी है डेटाबेस से रिकॉर्ड पुनर्प्राप्त करना।

मैं निश्चित रूप से सही होने के लिए खड़ा हूं।

Answer 1

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

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

मुझे मिश्रण के साथ रहने और मेरी डोमेन ऑब्जेक्ट्स को एनोटेट करने में खुशी है। जैसा कि मुझे पता है कि यह दृढ़ता को प्रबंधित करना आसान बनाता है ... लेकिन साथ ही, मैं हाइबरनेट/जेपीए के साथ बहुत सहज महसूस करता हूं और इसे 10 वर्षों तक उपयोग कर रहा हूं :)। परिप्रेक्ष्य के लिए Do ORMs enable the creation of rich domain models?