Я использую asp.net mvc со структурой сущности и начинаю изучать DDD. Я работаю над проектом, который содержит опросы. Вот моя модель домена:

public class Survey
{
    public int? SurveyID { get; set; }
    public string Name { get; set; }
    public decimal MinAcceptanceScore { get; set; }
    public int UserFailsCount { get; set; }

    public IEnumerable<SurveyQuestion> Questions { get; set; }
    public IEnumerable<Prize> Prizes { get; set; }
    public IEnumerable<SurveyAttempt> UserAttempts { get; set; }
}

Мне нужны разные части опросов для разных видов, поэтому я создал разные ViewModels:

    public class ShortSurveyViewModel
    {
        public int? SurveyID { get; set; }
        public string Name { get; set; }
        public int UserFailsCount { get; set; }
        public IEnumerable<SurveyAttempt> UserAttempts { get; set; }
    }

    public class ShortSurveyWithPrizesViewModel
    {
        public int? SurveyID { get; set; }
        public string Name { get; set; }
        public int UserFailsCount { get; set; }
        public IEnumerable<SurveyAttempt> UserAttempts { get; set; }
        public IEnumerable<Prize> Prizes { get; set; }
    }

    public class SurveyEditViewModel
    {
        public int? SurveyID { get; set; }
        public string Name { get; set; }
        public decimal MinAcceptanceScore { get; set; }
        public int UserFailsCount { get; set; }

        public IEnumerable<SurveyQuestion> Questions { get; set; }
        public IEnumerable<Prize> Prizes { get; set; }
    }

Как лучше построить мою архитектуру, если я хочу, чтобы мой репозиторий получал информацию, необходимую для подходящей модели представления?

Различные решения, которые я вижу:

Репозиторий может вернуть IQueryable в SurveyService, а сервис может вернуть подходящую модель представления, но я сомневаюсь, что это правильно, потому что я считаю, что модели представления должны создаваться в пользовательском интерфейсе, а не на уровне служб.

Создайте три соответствующих класса в моем доменном слое. Но теперь домен будет зависеть от представления, и с каждым новым представлением должен быть создан новый класс домена.

Получить полный объект домена и сопоставить только свойства, которые необходимы для конкретного вида. Это не хорошо, потому что в моем примере Вопросы нужны только в одном представлении, и это может быть большой сбор.