Relazioni modello con DDD (o con senso)?

Aggiornamento. Chiarimenti presi in considerazione.

Sembra che questo sia un dominio a scelta multipla, che di solito ha i seguenti requisiti

1. una domanda deve avere almeno due scelte in modo che tu possa scegliere tra
2. deve esserci almeno una scelta corretta
3. non dovrebbe esserci una scelta senza una domanda

In base a quanto sopra

[A] non può garantire l'invariante dal punto 1, potresti finire con una domanda senza scelta

[B] ha lo stesso svantaggio di [A]

[C] ha lo stesso svantaggio di [A] e [B]

[D] è un approccio valido, ma è meglio passare le scelte come elenco piuttosto che passarle singolarmente

[E] ha lo stesso svantaggio di [A] , [B] e [C]

Quindi, opterei per [D] perché consente di garantire che le regole di dominio dei punti 1, 2 e 3 siano seguite. Anche se dici che è molto improbabile che una domanda rimanga senza scelta per un lungo periodo di tempo, è sempre una buona idea comunicare i requisiti del dominio attraverso il codice.

Vorrei anche rinominare Answer in Choice come ha più senso per me in questo dominio.

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);

Una nota. Se rendi l'entità Question una radice aggregata e l'oggetto valore Choice una parte dello stesso aggregato, non ci sono possibilità che uno possa memorizzare Choice senza che sia assegnato a Question (anche se non lo fai t passare un riferimento diretto a Question come argomento al costruttore di Choice ), perché i repository funzionano solo con le radici e una volta creato il Question hai tutte le scelte assegnate ad esso nel costruttore.

Spero che questo aiuti.

UPDATE

Se ti infastidisce davvero come vengono create le scelte prima della loro domanda, ci sono alcuni trucchi che potresti trovare utili

1) Riorganizza il codice in modo che sembri creato dopo la domanda o almeno allo stesso tempo

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

2) Nascondere i costruttori e utilizzare un metodo factory statico

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) Usa lo schema costruttore

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

Tuttavia, tutto dipende dal tuo dominio. La maggior parte delle volte l'ordine di creazione di oggetti non è importante dal punto di vista del dominio del problema. Ciò che è più importante è che non appena ottieni un'istanza della tua classe è logicamente completa e pronta per l'uso.

obsoleto. Tutto ciò che segue è irrilevante per la domanda dopo i chiarimenti.

Prima di tutto, secondo il modello di dominio DDD dovrebbe avere senso nel mondo reale. Quindi, pochi punti

1. una domanda potrebbe non avere risposte
2. non dovrebbe esserci una risposta senza una domanda
3. una risposta dovrebbe corrispondere esattamente a una domanda
4. una risposta "vuota" non risponde a una domanda

In base a quanto sopra

[A] potrebbe contraddire il punto 4 perché è facile abusare e dimenticare di impostare il testo.

[B] è un approccio valido ma richiede parametri facoltativi

[C] potrebbe contraddire il punto 4 perché consente una risposta senza testo

[D] contraddice il punto 1 e potrebbe contraddire i punti 2 e 3

[E] potrebbe contraddire i punti 2, 3 e 4

In secondo luogo, possiamo utilizzare le funzionalità OOP per applicare la logica di dominio. Vale a dire, possiamo usare i costruttori per i parametri richiesti e setter per quelli opzionali.

In terzo luogo, utilizzerei il linguaggio ubiquitario che dovrebbe essere più naturale per il dominio.

E infine, possiamo progettarlo tutto usando modelli DDD come radici aggregate, entità e oggetti valore. Possiamo fare della domanda una radice del suo aggregato e la risposta una parte di esso. Questa è una decisione logica perché una risposta non ha significato al di fuori del contesto di una domanda.

Quindi, tutto quanto sopra si riduce al seguente disegno

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");

P.S. Risposta alla tua domanda Ho fatto alcune supposizioni sul tuo dominio che potrebbero non essere corrette, quindi sentiti libero di adattare quanto sopra alle tue specifiche.

Nel caso in cui i requisiti siano così semplici, che esistano più soluzioni possibili, allora il principio KISS dovrebbe essere seguito. Nel tuo caso, sarebbe l'opzione E.

C'è anche il caso di creare codice che esprima qualcosa, che non dovrebbe. Ad esempio legare la creazione di Risposte alla domanda (A e B) o dare una risposta a Domanda (C e D) aggiunge un comportamento non necessario al dominio e potrebbe essere fonte di confusione. Inoltre, nel tuo caso, la domanda sarebbe molto probabilmente aggregata con la risposta e la risposta sarebbe un tipo di valore.

Vorrei andare su [C] o [E].

In primo luogo, perché non A e B? Non voglio che la mia domanda sia responsabile della creazione di alcun valore correlato. Immagina se Question abbia molti altri oggetti valore - potresti mettere il metodo create per ognuno? O se ci sono alcuni complessi aggregati, lo stesso caso.

Perché non [D]? Perché è opposto a ciò che abbiamo in natura. Per prima cosa creiamo una domanda. Puoi immaginare una pagina web in cui tu crei tutto questo - l'utente dovrebbe prima creare una domanda, giusto? Pertanto, non D.

[E] è KISS, come ha detto @Euphoric. Ma comincio anche a piacermi [C] di recente. Questo non è così confuso come sembra. Inoltre, immagina se la domanda dipende da più cose - quindi lo sviluppatore deve sapere cosa deve mettere all'interno della domanda per essere inizializzato correttamente. Sebbene tu abbia ragione, non esiste una lingua "visiva" che spieghi che la risposta è effettivamente aggiunta alla domanda.

Letture aggiuntive

Domande come questa mi chiedono se i nostri linguaggi informatici siano troppo generici per la modellazione. (Capisco che hanno per essere generico per rispondere a tutti i requisiti di programmazione). Recentemente sto cercando di trovare un modo migliore per esprimere la lingua del business utilizzando interfacce fluenti. Qualcosa di simile (in linguaggio sudo):

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

vale a dire. cercando di allontanarsi da qualsiasi grande * Servizi e * Classi di repository in blocchi di business logic più piccoli. Solo un'idea.

Credo che tu abbia perso un punto qui, la tua radice Aggregato dovrebbe essere la tua Entità Test.

E se è davvero il caso, credo che un TestFactory sarebbe il più adatto a rispondere al tuo problema.

Dovresti delegare la creazione di domande e risposte alla fabbrica e quindi potresti sostanzialmente utilizzare qualsiasi soluzione che pensavi senza corrompere il tuo modello perché ti stai nascondendo al client nel modo in cui instanzia le tue sub entità.

Questo è, purché TestFactory sia l'unica interfaccia che usi per istanziare il tuo Test.