Updated. Clarifications taken into account.

Looks like this is a multiple choice domain, which usually has the following requirements

1. a question must have at least two choices so that you could choose among
2. there must be at least one correct choice
3. there should not be a choice without a question

Based on the above

[A] can’t ensure the invariant from point 1, you may end up with a question without any choice

[B] has the same disadvantage as [A]

[C] has the same disadvantage as [A] and [B]

[D] is a valid approach, but it’s better to pass the choices as a list rather than passing them individually

[E] has the same disadvantage as [A], [B] and [C]

Hence, I would go for [D] because it allows to ensure domain rules from points 1, 2 and 3 are followed. Even if you say that it’s very unlikely for a question to remain without any choice for a long period of time, it’s always a good idea to convey domain requirements through the code.

I would also rename the Answer to Choice as it makes more sense to me in this domain.

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

A note. If you make the Question entity an aggregate root and the Choice value object a part of the same aggregate, there’s no chances one can store a Choice without it being assigned to a Question (even though you don’t pass a direct reference to the Question as an argument to the Choice‘s constructor), because the repositories work with roots only and once you build your Question you have all your choices assigned to it in the constructor.

Hope this helps.

UPDATE

If it really bothers you how the choices are created ahead of their question, there are few tricks you might find useful

1) Rearrange the code so that it looks like they are created after the question or at least at the same time

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

2) Hide constructors and use a static factory method

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) Use the builder pattern

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

However, everything depends on your domain. Most of the times the order of objects creation is not important from the problem domain perspective. What is more important is that as soon as you get an instance of your class it is logically complete and ready to use.

Outdated. Everything below is irrelevant to the question after clarifications.

First of all, according to DDD domain model should make sense in the real world. Hence, few points

1. a question may have no answers
2. there should not be an answer without a question
3. an answer should correspond to exactly one question
4. an “empty” answer doesn’t answer a question

Based on the above

[A] may contradict point 4 because it’s easy to misuse and forget to set the text.

[B] is a valid approach but requires parameters that are optional

[C] may contradict point 4 because it allows an answer with no text

[D] contradicts point 1 and may contradict points 2 and 3

[E] may contradict points 2, 3 and 4

Secondly, we can make use of OOP features to enforce domain logic. Namely we can use constructors for the required parameters and setters for the optional ones.

Thirdly, I would use the ubiquitous language which is supposed to be more natural for the domain.

And finally, we can design it all using DDD patterns like aggregate roots, entities and value objects. We can make the Question a root of its aggregate and the Answer a part of it. This is a logical decision because an answer has no meaning outside of a question’s context.

So, all the above boil down to the following design

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. Answering to your question I made few assumptions about your domain which might not be correct, so feel free to adjust the above with your specifics.

In case where requirements are so simple, that multiple possible solutions exist, then KISS principle should be followed. In your case, that would be option E.

There is also case of creating code that expresses something, that it should not. For example tying creation of Answers to Question (A and B) or giving Answer reference to Question (C and D) add some behavior that is not necessary to the domain and might be confusing. Also, in your case, Question would most probably be aggregate with Answer and Answer would be a value type.

I would go either [C] or [E].

First, why not A and B? I don’t want my Question be responsible for creating any related value. Imagine if Question has many other value objects – would you put create method for every one? Or if there are some complex aggregates, the same case.

Why not [D]? Because it is opposite to what we have in nature. We first do create a Question. You can imagine a web page where you create all this – user would first create a question, right? Therefore, not D.

[E] is KISS, like @Euphoric said. But I also start to like [C] recently. This is not so confusing as it seems. Moreover, imagine if Question depends on more things – then developer must to know what he needs to put inside the Question to have it properly initialized. Although you are right – there is no ‘visual’ language explaining that answer is actually added to the question.

Additional reading

Questions like this makes me wonder if our computer languages are too generic for modeling. (I understand they have to be generic to answer on all programming requirements). Recently I am trying to find a better way to express the business language using fluent interfaces. Something like this (in sudo language):

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

i.e. trying to move away from any big *Services and *Repository classes to smaller chunks of business logic. Just an idea.

I believe you missed a point here, your Aggregate root should be your Test Entity.

And if it’s really the case I believe a TestFactory would be best suited to answer your problem.

You would delegate the Question and Answer building to the Factory and therefore you could basically use any solution you thought of without corrupting your model because you are hiding to the client the way you instantiate your sub entities.

This is, as long as the TestFactory is the only interface you use to instantiate your Test.