สร้างแบบจำลองความสัมพันธ์กับ DDD (หรือมีเหตุผล)?

นี่คือข้อกำหนดที่ง่ายขึ้น:

ผู้ใช้สร้างQuestionที่มีหลายAnswers Questionต้องมีอย่างน้อยหนึ่งAnswerรายการ

การชี้แจง: คิดQuestionและAnswerในการทดสอบ : มีคำถามหนึ่งข้อ แต่มีหลายคำตอบซึ่งมีเพียงไม่กี่ข้อที่ถูกต้อง ผู้ใช้คือนักแสดงที่กำลังเตรียมการทดสอบนี้ดังนั้นเขาจึงสร้างคำถามและคำตอบ

ฉันพยายามจำลองตัวอย่างง่ายๆนี้เพื่อ 1) จับคู่โมเดลชีวิตจริง 2) แสดงรหัสด้วยดังนั้นเพื่อลดการใช้ผิดและข้อผิดพลาดที่อาจเป็นไปได้และให้คำแนะนำแก่นักพัฒนาเกี่ยวกับวิธีใช้โมเดล

คำถามที่เป็นนิติบุคคลในขณะที่คำตอบคือวัตถุที่คุ้มค่า คำถามถือคำตอบ จนถึงตอนนี้ฉันมีวิธีแก้ปัญหาที่เป็นไปได้เหล่านี้

[A]ภายในโรงงานQuestion

แทนที่จะสร้างAnswerด้วยตนเองเราสามารถโทร:

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

ที่จะสร้างคำตอบและเพิ่มลงในคำถาม จากนั้นเราสามารถจัดการคำตอบได้โดยตั้งค่าคุณสมบัติ ด้วยวิธีนี้เฉพาะคำถามเท่านั้นที่สามารถสร้างคำตอบได้ นอกจากนี้เราป้องกันไม่ให้มีคำตอบโดยไม่มีคำถาม แต่เราไม่ได้มีการควบคุมมากกว่าการสร้างคำตอบเป็นที่ hardcoded Questionใน

นอกจากนี้ยังมีปัญหาหนึ่งกับ 'ภาษา' ของรหัสด้านบน ผู้ใช้คือคนที่สร้างคำตอบไม่ใช่คำถาม โดยส่วนตัวแล้วฉันไม่ชอบที่เราจะสร้างวัตถุที่มีคุณค่าและขึ้นอยู่กับนักพัฒนาเพื่อเติมให้เต็มด้วยค่า - เขาจะแน่ใจได้อย่างไรว่าจะต้องเพิ่มอะไรบ้าง

[B]คำถามจากโรงงานใช้ # 2

บางคนบอกว่าเราควรมีวิธีนี้ในQuestion:

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

เช่นเดียวกับวิธีแก้ไขปัญหาข้างต้นวิธีนี้ใช้ข้อมูลที่จำเป็นสำหรับคำตอบและสร้างรายการที่จะถูกเพิ่มลงในคำถามด้วย

ปัญหาที่นี่คือเราทำซ้ำตัวสร้างของAnswerไม่มีเหตุผลที่ดี คำถามจะสร้างคำตอบจริงๆหรือไม่?

[C] ตัวสร้างอ้างอิง

เรามีอิสระที่จะสร้างวัตถุทั้งสองด้วยตัวเราเอง เรายังแสดงถึงความถูกต้องในตัวสร้าง:

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

สิ่งนี้ให้คำแนะนำแก่นักพัฒนาเนื่องจากไม่สามารถสร้างคำตอบได้หากไม่มีคำถาม อย่างไรก็ตามเราไม่เห็น 'ภาษา' ที่ระบุว่าคำตอบนั้น 'เพิ่ม' ไว้ในคำถาม ในทางกลับกันเราจำเป็นต้องเห็นมันจริงๆเหรอ?

[D] การพึ่งพา Constructor ใช้เวลา # 2

เราสามารถทำสิ่งที่ตรงกันข้าม:

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

นี่เป็นสถานการณ์ที่ตรงกันข้ามกับข้างต้น คำตอบสามารถอยู่ได้โดยไม่มีคำถาม (ซึ่งไม่เข้าท่า) แต่คำถามไม่สามารถอยู่ได้โดยไม่มีคำตอบ (ซึ่งทำให้เข้าใจ) นอกจากนี้ 'ภาษา' ที่นี่มีความชัดเจนมากขึ้นในคำถามนั้นจะมีคำตอบ

[E]วิธีทั่วไป

นี่คือสิ่งที่ฉันเรียกว่าวิธีทั่วไปสิ่งแรกที่ ppl มักจะทำคือ:

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

ซึ่งเป็นเวอร์ชัน 'หลวม' ของสองคำตอบข้างต้นเนื่องจากทั้งคำตอบและคำถามอาจมีอยู่โดยไม่มีกันและกัน ไม่มีคำใบ้พิเศษที่คุณต้องผูกเข้าด้วยกัน

[F]รวม

หรือฉันควรรวม C, D, E - เพื่อครอบคลุมทุกวิธีที่ความสัมพันธ์สามารถสร้างขึ้นได้ดังนั้นเพื่อช่วยให้นักพัฒนาซอฟต์แวร์ใช้สิ่งที่ดีที่สุดสำหรับพวกเขา

คำถาม

ฉันรู้ว่าผู้คนอาจเลือกหนึ่งในคำตอบข้างต้นตาม 'ลางสังหรณ์' แต่ฉันสงสัยว่าตัวแปรใด ๆ ข้างต้นดีกว่าตัวอื่นด้วยเหตุผลที่ดี นอกจากนี้โปรดอย่าคิดว่าภายในคำถามข้างต้นฉันต้องการที่จะบีบการปฏิบัติที่ดีที่สุดที่สามารถนำไปใช้ในกรณีส่วนใหญ่ - และถ้าคุณเห็นด้วยกรณีการใช้งานส่วนใหญ่ของการสร้างบางหน่วยงานมีความคล้ายคลึงกัน นอกจากนี้ให้เป็นผู้ไม่เชื่อเรื่องพระเจ้าเทคโนโลยีที่นี่เช่น ฉันไม่ต้องการที่จะคิดว่าออมจะถูกใช้หรือไม่ แค่ต้องการโหมดการแสดงออกที่ดี

ภูมิปัญญาเกี่ยวกับเรื่องนี้?

แก้ไข

โปรดละเว้นคุณสมบัติอื่น ๆ ของQuestionและสิ่งAnswerเหล่านี้ไม่เกี่ยวข้องกับคำถาม ฉันแก้ไขข้อความข้างต้นและเปลี่ยนแปลงตัวสร้างส่วนใหญ่ (เมื่อจำเป็น): ตอนนี้พวกเขายอมรับค่าคุณสมบัติที่จำเป็นใด ๆ ที่จำเป็น นั่นอาจเป็นเพียงสตริงคำถามหรือแผนที่ของสตริงในภาษาที่แตกต่างกันสถานะ ฯลฯ - คุณสมบัติใดก็ตามที่ถูกส่งผ่านพวกเขาไม่ได้มุ่งเน้นเรื่องนี้;) ดังนั้นให้สมมติว่าเราอยู่เหนือการผ่านพารามิเตอร์ที่จำเป็น Thanx!

Updated คำชี้แจงที่นำมาพิจารณา

ดูเหมือนว่านี่เป็นโดเมนตัวเลือกที่หลากหลายซึ่งโดยปกติจะมีข้อกำหนดดังต่อไปนี้

1. คำถามต้องมีอย่างน้อยสองตัวเลือกเพื่อให้คุณเลือกได้
2. ต้องมีตัวเลือกที่ถูกต้องอย่างน้อยหนึ่งตัว
3. ไม่ควรมีตัวเลือกหากไม่มีคำถาม

ตามข้างต้น

[A]ไม่สามารถรับประกันค่าคงที่จากจุดที่ 1 คุณอาจท้ายด้วยคำถามโดยไม่มีทางเลือก

[B]มีข้อเสียเหมือนกับ[A]

[C]มีข้อเสียเหมือนกับ[A]และ[B]

[D]เป็นวิธีการที่ใช้ได้ แต่ดีกว่าที่จะส่งผ่านตัวเลือกเป็นรายการแทนที่จะส่งเป็นรายบุคคล

[E]มีข้อเสียเหมือนกับ[A] , [B]และ[C]

ดังนั้นฉันจะไปหา[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วัตถุค่าเป็นส่วนหนึ่งของการรวมเดียวกันคุณจะไม่สามารถเก็บ a Choiceโดยไม่ได้รับมอบหมายให้เป็นเอฟQuestion(แม้ว่าคุณจะไม่ผ่านการอ้างอิงโดยตรงไปQuestionยังChoiceตัวสร้าง) เนื่องจากที่เก็บทำงานกับรากเท่านั้นและเมื่อคุณสร้างขึ้นQuestionคุณจะมีตัวเลือกทั้งหมดที่กำหนดไว้ในตัวสร้าง

หวังว่านี่จะช่วยได้

UPDATE

หากมันรบกวนคุณจริง ๆ ว่าตัวเลือกนั้นถูกสร้างขึ้นมาก่อนคำถามของพวกเขามีเล่ห์เหลี่ยมบางอย่างที่คุณอาจพบว่ามีประโยชน์

1) จัดเรียงรหัสใหม่เพื่อให้ดูเหมือนว่าถูกสร้างขึ้นหลังคำถามหรืออย่างน้อยก็ในเวลาเดียวกัน

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

2) ซ่อน Constructor และใช้วิธี Factory Static

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]อาจขัดแย้งกับจุดที่ 4 เพราะง่ายต่อการใช้ผิดและลืมตั้งค่าข้อความ

[B]เป็นวิธีที่ถูกต้อง แต่ต้องการพารามิเตอร์ที่เป็นตัวเลือก

[C]อาจขัดแย้งกับจุดที่ 4 เนื่องจากอนุญาตให้ไม่มีคำตอบ

[D]ขัดแย้งกับจุดที่ 1 และอาจขัดแย้งกับจุดที่ 2 และ 3

[E]อาจขัดแย้งกับคะแนน 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");

ป.ล. ตอบคำถามของคุณฉันตั้งสมมติฐานบางอย่างเกี่ยวกับโดเมนของคุณซึ่งอาจไม่ถูกต้องดังนั้นอย่าลังเลที่จะปรับเปลี่ยนข้างต้นด้วยข้อมูลเฉพาะของคุณ

ในกรณีที่ความต้องการนั้นง่ายมากมีวิธีแก้ปัญหาที่เป็นไปได้หลายข้อควรปฏิบัติตามหลักการ KISS ในกรณีของคุณนั่นคือตัวเลือก E

นอกจากนี้ยังมีกรณีของการสร้างรหัสที่แสดงบางสิ่งบางอย่างที่ไม่ควร ตัวอย่างเช่นการสร้างคำตอบสำหรับคำถาม (A และ B) หรือให้คำตอบอ้างอิงถึงคำถาม (C และ D) เพิ่มพฤติกรรมบางอย่างที่ไม่จำเป็นสำหรับโดเมนและอาจทำให้เกิดความสับสน นอกจากนี้ในกรณีของคุณคำถามส่วนใหญ่น่าจะรวมกับคำตอบและคำตอบจะเป็นประเภทค่า

ฉันจะไปทั้ง [C] หรือ [E]

ก่อนทำไมไม่ A และ B? ฉันไม่ต้องการให้คำถามของฉันรับผิดชอบในการสร้างคุณค่าที่เกี่ยวข้องใด ๆ ลองนึกภาพถ้าคำถามมีวัตถุที่มีค่าอื่น ๆ อีกมากมาย - คุณจะใส่createวิธีสำหรับทุกคนหรือไม่? หรือหากมีการรวมที่ซับซ้อนบางกรณีเดียวกัน

ทำไมไม่ [D] เพราะมันตรงกันข้ามกับสิ่งที่เรามีในธรรมชาติ ก่อนอื่นเราจะสร้างคำถาม คุณสามารถจินตนาการถึงหน้าเว็บที่คุณสร้างทั้งหมดนี้ได้ - ผู้ใช้จะสร้างคำถามใช่ไหม? ดังนั้นไม่ใช่ D

[E] คือ KISS อย่างที่ @Euphoric พูด แต่ฉันก็เริ่มชอบ [C] เร็ว ๆ นี้ มันไม่สับสนอย่างที่คิด ยิ่งไปกว่านั้นลองคิดดูว่าคำถามขึ้นอยู่กับอะไรมากกว่านั้นนักพัฒนาจะต้องรู้ว่าเขาต้องใส่อะไรลงไปในคำถามเพื่อเริ่มต้นคำถามได้อย่างถูกต้อง แม้ว่าคุณจะถูกต้อง - ไม่มีภาษา 'ภาพ' ที่อธิบายว่าคำตอบนั้นถูกเพิ่มเข้าไปในคำถาม

อ่านเพิ่มเติม

คำถามเช่นนี้ทำให้ฉันสงสัยว่าภาษาคอมพิวเตอร์ของเรากว้างเกินไปสำหรับการสร้างแบบจำลองหรือไม่ (ฉันเข้าใจว่าพวกเขาจำเป็นต้องเป็นคำตอบทั่วไปสำหรับข้อกำหนดการเขียนโปรแกรมทั้งหมด) เมื่อเร็ว ๆ นี้ฉันกำลังพยายามหาวิธีที่ดีกว่าในการแสดงภาษาธุรกิจโดยใช้ส่วนต่อประสานที่คล่องแคล่ว บางสิ่งเช่นนี้ (ในภาษา sudo):

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

เช่นพยายามย้ายออกจากคลาสใหญ่ ๆ * Services และ * Repository ไปยังกลุ่มของตรรกะทางธุรกิจที่เล็กลง แค่ความคิด

ฉันเชื่อว่าคุณพลาดจุดที่นี่รากรวมของคุณควรเป็นหน่วยทดสอบของคุณ

และถ้าเป็นจริงฉันเชื่อว่า TestFactory จะเหมาะที่สุดในการตอบปัญหาของคุณ

คุณจะมอบหมายการสร้างคำถามและคำตอบให้กับโรงงานและโดยทั่วไปคุณสามารถใช้โซลูชันใด ๆ ที่คุณคิดโดยไม่ทำให้รูปแบบของคุณเสียหายเพราะคุณซ่อนลูกค้าไว้ในแบบที่คุณสร้างอินสแตนซ์ย่อยของคุณ

นี่คือตราบใดที่ TestFactory เป็นอินเทอร์เฟซเดียวที่คุณใช้เพื่อยกตัวอย่างการทดสอบของคุณ