डीडीडी (या भावना के साथ) के साथ मॉडल संबंध?

Question

यहाँ एक सरल आवश्यकता है:

उपयोगकर्ता Questionकई Answerएस के साथ बनाता है । Questionकम से कम एक होना चाहिए Answer।

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

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

प्रश्न एक इकाई है , जबकि उत्तर मूल्य वस्तु है । प्रश्न उत्तर रखता है। अब तक, मेरे पास ये संभव उपाय हैं।

[ए] कारखाने के अंदरQuestion

Answerमैन्युअल बनाने के बजाय , हम कॉल कर सकते हैं:

Answer answer = question.createAnswer()
answer.setText("");
...

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

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

[ख] प्रश्न के अंदर का कारखाना, # २ लें

कुछ का कहना है कि हमारे पास इस तरह की विधि होनी चाहिए Question:

question.addAnswer(String answer, boolean correct, int level....);

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

यहाँ समस्या यह है कि हम बिना किसी अच्छे कारण के निर्माणकर्ता की नकल करते हैं Answer। इसके अलावा, क्या प्रश्न वास्तव में एक उत्तर बनाता है?

[सी] कंस्ट्रक्टर निर्भरता

आइए अपने स्वयं के द्वारा दोनों वस्तुओं को बनाने के लिए स्वतंत्र रहें। आइए, निर्माता पर निर्भरता के अधिकार को भी व्यक्त करें:

Question q = new Question(...);
Answer a = new Answer(q, ...);   // answer can't exist without a question

यह डेवलपर को संकेत देता है, क्योंकि बिना प्रश्न के उत्तर नहीं बनाया जा सकता है। हालाँकि, हम उस 'भाषा' को नहीं देखते हैं जो कहती है कि प्रश्न का उत्तर 'जोड़ा' गया है। दूसरी ओर, क्या हमें वास्तव में इसे देखने की आवश्यकता है?

[डी] कंस्ट्रक्टर निर्भरता, # 2 लें

हम इसके विपरीत कर सकते हैं:

Answer a1 = new Answer("",...);
Answer a2 = new Answer("",...);
Question q = new Question("", a1, a2);

यह ऊपर की विपरीत स्थिति है। यहाँ प्रश्न के बिना उत्तर मौजूद हो सकते हैं (जिसका कोई मतलब नहीं है), लेकिन प्रश्न बिना उत्तर के मौजूद नहीं हो सकता (जो समझ में आता है)। साथ ही, यहाँ 'भाषा' उस प्रश्न पर अधिक स्पष्ट है जिसके उत्तर होंगे।

[ई] आम रास्ता

इसे मैं सामान्य तरीका कहता हूं, पहली बात जो पीपीएल आमतौर पर करता है:

Question q = new Question("",...);
Answer a = new Answer("",...);
q.addAnswer(a);

जो दो उत्तरों के ऊपर 'ढीला' संस्करण है, क्योंकि उत्तर और प्रश्न दोनों एक दूसरे के बिना मौजूद हो सकते हैं। कोई विशेष संकेत आपको लगता है कि है है उन्हें एक साथ बाध्य करने के लिए।

[एफ] संयुक्त

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

सवाल

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

इस पर कोई ज्ञान?

संपादित करें

अन्य गुणों की उपेक्षा करें Questionऔर Answer, वे प्रश्न के लिए प्रासंगिक नहीं हैं। मैंने पाठ के ऊपर संपादन किया और अधिकांश कंस्ट्रक्टर (जहां आवश्यक हो) को बदल दिया: अब वे आवश्यक संपत्ति मूल्यों में से किसी को भी स्वीकार करते हैं। यह सिर्फ एक प्रश्न स्ट्रिंग, या विभिन्न भाषाओं, स्थितियों आदि में स्ट्रिंग का नक्शा हो सकता है - जो भी गुण पारित किए जाते हैं, वे इसके लिए ध्यान केंद्रित नहीं कर रहे हैं;) तो बस यह मान लें कि हम आवश्यक मापदंडों से ऊपर हैं, जब तक कि अलग-अलग नहीं कहा जाता है। Thanx!

Answer 1

अपडेट किया गया। स्पष्टीकरण को ध्यान में रखा।

ऐसा लगता है कि यह एक बहु विकल्प डोमेन है, जिसमें आमतौर पर निम्नलिखित आवश्यकताएं होती हैं

1. एक प्रश्न में कम से कम दो विकल्प होने चाहिए ताकि आप इनमें से चुन सकें
2. कम से कम एक सही विकल्प होना चाहिए
3. प्रश्न के बिना कोई विकल्प नहीं होना चाहिए

ऊपर के आधार पर

[ए] बिंदु 1 से अपरिवर्तित सुनिश्चित नहीं कर सकता है, आप बिना किसी विकल्प के एक प्रश्न के साथ समाप्त हो सकते हैं

[बी] के रूप में एक ही नुकसान है [ए]

[सी] के रूप में एक ही नुकसान है [ए] और [बी]

[डी] एक वैध दृष्टिकोण है, लेकिन व्यक्तिगत रूप से पारित करने के बजाय एक सूची के रूप में विकल्पों को पारित करना बेहतर है

[ई] के रूप में एक ही नुकसान है [ए] , [बी] और [सी]

इसलिए, मैं [D] के लिए जाना चाहूंगा क्योंकि यह अंक 1, 2 और 3 से डोमेन नियमों को सुनिश्चित करने की अनुमति देता है। यहां तक ​​कि अगर आप कहते हैं कि किसी प्रश्न के बिना किसी विकल्प के लंबे समय तक बने रहने की संभावना नहीं है, तो कोड के माध्यम से डोमेन आवश्यकताओं को व्यक्त करना हमेशा एक अच्छा विचार है।

मैं भी नाम बदलने होगा Answerकरने के लिए Choiceके रूप में यह इस क्षेत्र में मेरे लिए अधिक समझ में आता है।

public class Choice implements ValueObject {

    private Question q;
    private final String txt;
    private final boolean isCorrect;
    private boolean isSelected = false;

    public Choice(String txt, boolean isCorrect) {
        // validate and assign
    }

    public void assignToQuestion(Question q) {
        this.q = q;
    }

    public void select() {
        isSelected = true;
    }

    public void unselect() {
        isSelected = false;
    }

    public boolean isSelected() {
        return isSelected;
    }
}

public class Question implements Entity {

    private final String txt;
    private final List<Choice> choices;

    public Question(String txt, List<Choice> choices) {
        // ensure requirements are met
        // 1. make sure there are more than 2 choices
        // 2. make sure at least 1 of the choices is correct
        // 3. assign each choice to this question
    }
}

Choice ch1 = new Choice("The sky", false);
Choice ch2 = new Choice("Ceiling", true);
List<Choice> choices = Arrays.asList(ch1, ch2);
Question q = new Question("What's up?", choices);

एक नोट। यदि आप Questionइकाई को एक समग्र रूट बनाते हैं और Choiceमान एक ही समुच्चय का एक हिस्सा है, तो कोई भी मौका नहीं है जो Choiceइसे सौंपे बिना एक स्टोर कर सकता है Question(भले ही आप Questionएक तर्क के रूप में एक सीधा संदर्भ पास न करें Choiceनिर्माणकर्ता), क्योंकि रिपॉजिटरी केवल जड़ों के साथ काम करती है और एक बार जब आप अपना निर्माण Questionकर लेते हैं तो आपके पास अपने सभी विकल्प कंस्ट्रक्टर को सौंपे जाते हैं।

उम्मीद है की यह मदद करेगा।

अपडेट करें

यदि यह वास्तव में आपको परेशान करता है कि उनके प्रश्न के आगे विकल्प कैसे बनाए जाते हैं, तो कुछ तरकीबें हैं जो आपको उपयोगी लग सकती हैं

1) कोड को फिर से व्यवस्थित करें ताकि ऐसा लगे कि वे प्रश्न के बाद या कम से कम एक ही समय में बनाए गए हैं

Question q = new Question(
    "What's up?",
    Arrays.asList(
        new Choice("The sky", false),
        new Choice("Ceiling", true)
    )
);

2) कंस्ट्रक्टरों को छिपाएं और एक स्थिर फैक्टरी विधि का उपयोग करें

public class Question implements Entity {
    ...

    private Question(String txt) { ... }

    public static Question newInstance(String txt, List<Choice> choices) {
        Question q = new Question(txt);
        for (Choice ch : choices) {
            q.assignChoice(ch);
        }
    }

    public void assignChoice(Choice ch) { ... }
    ...
}

3) बिल्डर पैटर्न का उपयोग करें

Question q = new Question.Builder("What's up?")
    .assignChoice(new Choice("The sky", false))
    .assignChoice(new Choice("Ceiling", true))
    .build();

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

रगड़ा हुआ। स्पष्टीकरण के बाद सवाल नीचे सब कुछ अप्रासंगिक है।

सबसे पहले, DDD डोमेन मॉडल के अनुसार वास्तविक दुनिया में समझ बनाना चाहिए। इसलिए, कुछ अंक

1. एक सवाल का कोई जवाब नहीं हो सकता है
2. प्रश्न के बिना उत्तर नहीं होना चाहिए
3. एक उत्तर को वास्तव में एक प्रश्न के अनुरूप होना चाहिए
4. "खाली" उत्तर किसी प्रश्न का उत्तर नहीं देता है

ऊपर के आधार पर

[A] बिंदु ४ का खंडन कर सकता है क्योंकि इसका दुरुपयोग करना आसान है और पाठ को सेट करना भूल जाते हैं।

[बी] एक वैध दृष्टिकोण है लेकिन इसके लिए ऐसे मापदंडों की आवश्यकता होती है जो वैकल्पिक हों

[C] बिंदु ४ पर विरोधाभास हो सकता है क्योंकि यह बिना किसी पाठ के उत्तर की अनुमति देता है

[डी] विरोधाभास बिंदु १ और अंक २ और ३ के विपरीत हो सकते हैं

[ई] विरोधाभास अंक 2, 3 और 4 हो सकता है

दूसरे, हम डोमेन लॉजिक को लागू करने के लिए OOP सुविधाओं का उपयोग कर सकते हैं। अर्थात् हम आवश्यक मापदंडों के लिए कंस्ट्रक्टरों का उपयोग कर सकते हैं और वैकल्पिक लोगों के लिए बसते हैं।

तीसरा, मैं सर्वव्यापी भाषा का उपयोग करूंगा जो कि डोमेन के लिए अधिक स्वाभाविक माना जाता है।

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

तो, उपरोक्त सभी निम्नलिखित डिजाइन को उबालते हैं

class Answer implements ValueObject {

    private final Question q;
    private String txt;
    private boolean isCorrect = false;

    Answer(Question q, String txt) {
        // validate and assign
    }

    public void markAsCorrect() {
        isCorrect = true;
    }

    public boolean isCorrect() {
        return isCorrect;
    }
}

public class Question implements Entity {

    private String txt;
    private final List<Answer> answers = new ArrayList<>();

    public Question(String txt) {
        // validate and assign
    }

    // Ubiquitous Language: answer() instead of addAnswer()
    public void answer(String txt) {
        answers.add(new Answer(this, txt));
    }
}

Question q = new Question("What's up?");
q.answer("The sky");

PS आपके प्रश्न का उत्तर देते हुए मैंने आपके डोमेन के बारे में कुछ धारणाएँ बनाई हैं जो सही नहीं हो सकती हैं, इसलिए बेझिझक उपरोक्त को अपनी बारीकियों के साथ समायोजित करें।

Comments

संक्षेप में: यह बी और सी का मिश्रण है। कृपया आवश्यकताओं के बारे में मेरा स्पष्टीकरण देखें। आपकी बात 1. किसी प्रश्न का निर्माण करते समय केवल 'संक्षिप्त' अवधि के लिए मौजूद हो सकती है; लेकिन डेटाबेस में नहीं। उस अर्थ में, 4. कभी नहीं होना चाहिए। मुझे उम्मीद है कि अब आवश्यकताएं स्पष्ट हैं;)

— लॉन

Btw, स्पष्टीकरण के साथ, मेरे लिए ऐसा लगता है कि addAnswerया assignAnswerभाषा से बेहतर होगा answer, मुझे आशा है कि आप इस पर सहमत होंगे। वैसे भी, मेरा सवाल है - क्या आप अभी भी बी के लिए जाएंगे और उदाहरण के लिए उत्तर पद्धति में अधिकांश तर्कों की प्रति है? क्या यह दोहराव नहीं होगा?

— लॉपर

अस्पष्ट आवश्यकताओं के लिए क्षमा करें, क्या आप उत्तर को अपडेट करने के लिए इतने दयालु होंगे?

— लॉपर

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

— ज़फ़रखाजा

@lawpert Answerएक वैल्यू ऑब्जेक्ट है, यह अपने एग्रीगेट के कुल रूट के साथ स्टोर होने वाला है। आप मान ऑब्जेक्ट को सीधे संग्रहीत नहीं करते हैं, और न ही आप संस्थाओं को बचाते हैं यदि वे उनके समुच्चय की जड़ें नहीं हैं।

— ज़फ़रखाजा

Answer 2

इस मामले में जहां आवश्यकताओं इतना आसान हैं, जो एक से अधिक संभव समाधान मौजूद है, तो KISS सिद्धांत का पालन किया जाना चाहिए। आपके मामले में, यह विकल्प ई होगा।

कोड बनाने का भी मामला है जो कुछ व्यक्त करता है, कि यह नहीं होना चाहिए। उदाहरण के लिए प्रश्न (ए और बी) के उत्तर का निर्माण करना या प्रश्न (सी और डी) का उत्तर संदर्भ देना कुछ व्यवहार को जोड़ते हैं जो डोमेन के लिए आवश्यक नहीं है और भ्रामक हो सकता है। साथ ही, आपके मामले में, प्रश्न संभवतः उत्तर के साथ कुल होगा और उत्तर एक मूल्य प्रकार होगा।

Comments

क्यों [सी] एक अनावश्यक व्यवहार है? जैसा कि मैं इसे देखता हूं, [C] यह बताता है कि उत्तर प्रश्न के बिना नहीं रह सकता है, और वास्तव में यही है। इसके अलावा, कल्पना करें कि उत्तर के लिए कुछ और झंडों की आवश्यकता है (जैसे उत्तर प्रकार, श्रेणी, आदि) जो अनिवार्य हैं। KISS हम क्या अनिवार्य है की है कि ज्ञान खो जाता है, और डेवलपर चाहिए जा रहे हैं करने के लिए पता है सामने वह क्या है ताकि इसे सही करने के लिए उत्तर करने के लिए जोड़ / सेट करने की जरूरत है। मेरा मानना ​​है कि यह प्रश्न इस बहुत ही सरल उदाहरण के लिए नहीं था, बल्कि OO का उपयोग करके सर्वव्यापी भाषा लिखने के लिए बेहतर अभ्यास खोजने के लिए था।

— इगोर

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

— युफ़ोरिक

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

— व्यंग्यात्मक

बस रिकॉर्ड के लिए, Im ने C & E :) के बीच फाड़ दिया :) अब, यह: "... इसे सहेजने के लिए प्रश्न का उत्तर देना अनिवार्य करने के लिए इसे बचाने के लिए भंडार है।" इसका मतलब है कि 'अनिवार्य' भाग केवल तब आता है जब हम भंडार में आते हैं। तो अनिवार्य कनेक्शन डेवलपर के लिए संकलन समय पर दिखाई नहीं देता है, और व्यावसायिक नियम भंडार में लीक हो जाता है। इसीलिए मैं यहां [C] का परीक्षण कर रहा हूं। शायद यह बात मेरे बारे में अधिक जानकारी दे सकती है कि मुझे क्या लगता है कि सी विकल्प के बारे में है।

— igor

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

— igor

Answer 3

मैं या तो [C] या [E] जाऊंगा।

पहला, A और B क्यों नहीं? मैं नहीं चाहता कि कोई भी संबंधित मूल्य बनाने के लिए मेरा प्रश्न जिम्मेदार हो। कल्पना कीजिए कि यदि प्रश्न में कई अन्य मूल्य वस्तुएं हैं - तो क्या आप createहर एक के लिए विधि रखेंगे ? या अगर कुछ जटिल समुच्चय हैं, वही मामला।

क्यों नहीं [D] क्योंकि यह हमारे स्वभाव के विपरीत है। हम पहले एक प्रश्न बनाते हैं। आप एक वेब पेज की कल्पना कर सकते हैं जहां आप यह सब बनाते हैं - उपयोगकर्ता पहले एक सवाल पैदा करेगा, है ना? इसलिए, डी नहीं।

[ई] की तरह @Euphoric कहा, KISS है। लेकिन मुझे हाल ही में [C] पसंद आने लगे हैं। यह इतना भ्रामक नहीं है जितना लगता है। इसके अलावा, कल्पना करें कि यदि प्रश्न अधिक चीजों पर निर्भर करता है - तो डेवलपर को यह जानना होगा कि उसे ठीक से आरंभ करने के लिए प्रश्न के अंदर क्या डालने की आवश्यकता है। यद्यपि आप सही हैं - कोई 'दृश्य' भाषा नहीं है जो यह समझाती है कि वास्तव में उत्तर को प्रश्न में जोड़ा गया है।

अतिरिक्त पढ़ने

इस तरह के सवाल मुझे आश्चर्यचकित करते हैं कि क्या हमारी कंप्यूटर भाषाएँ मॉडलिंग के लिए बहुत सामान्य हैं। (मैं समझता हूँ कि वे है सभी प्रोग्रामिंग आवश्यकताओं पर जवाब देने के लिए सामान्य हो)। हाल ही में मैं धाराप्रवाह इंटरफेस का उपयोग करके व्यापारिक भाषा को व्यक्त करने का एक बेहतर तरीका खोजने की कोशिश कर रहा हूं। कुछ इस तरह (sudo भाषा में):

use(question).addAnswer(answer).storeToRepo();

यानी किसी भी बड़े * सेवा और * रिपॉजिटरी वर्गों से दूर व्यापार तर्क के छोटे हिस्से में जाने की कोशिश कर रहा है। एक विचार है।

Comments

आप डोमेन विशिष्ट भाषाओं के बारे में ऐडऑन में बात कर रहे हैं?

— लॉपर

अब जब आपने उल्लेख किया, तो ऐसा लगता है :) खरीदें मुझे इसके साथ कोई महत्वपूर्ण अनुभव नहीं है।

— इगोर

मुझे लगता है कि अब तक एक आम सहमति है कि IO एक ऑर्थोगोनल रिस्पॉन्सिबिलिटी है और इस तरह संस्थाओं (storeToRepo) द्वारा संभाला नहीं जाना चाहिए

— Esben

मैं मानता हूं @ एसेन स्कोव पेडरसेन कि इकाई को खुद रेपो को अंदर नहीं बुलाना चाहिए (जैसा आपने कहा, ठीक है); लेकिन AFAIU के रूप में यहाँ हम आदेशों के पीछे किसी प्रकार का बिल्डर पैटर्न रखते हैं; इसलिए IO यहां इकाई में नहीं किया जाता है। कम से कम यह है कि Ive इसे कैसे समझे;)

— लूप

@lawpert जो सही है। मैं यह देखने में विफल हूं कि यह कैसे काम करने वाला है लेकिन दिलचस्प होगा।

— एसेन स्कोव पेडर्सन

Answer 4

मेरा मानना ​​है कि आप यहाँ एक बिंदु से चूक गए हैं, आपका एग्रीगेट रूट आपकी टेस्ट इकाई होनी चाहिए।

और अगर यह वास्तव में मामला है, तो मेरा मानना ​​है कि आपकी समस्या का जवाब देने के लिए एक TestFactory सबसे उपयुक्त होगा।

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

यह तब तक है, जब तक कि TestFactory एकमात्र इंटरफ़ेस है जिसका उपयोग आप अपने परीक्षण को तुरंत करने के लिए करते हैं।