Чистая архитектура. DTO с использованием CQRS на ASP .NET Core

Я для себя определил, какие модели должны создаваться для одной апишки, и пользовался этим, пока это не зашло слишком далеко. В целом, архитектура мне нравится, потому что из-за ее единообразности ее очень легко контролировать и понимать, откуда что идет. Но, мне кажется, где-то можно подглядеть реализацию получше с тем же эффектом. Проблемы, которые меня преследуют, - названия классов и объем кода. Второе даже не проблема, когда ты стараешься писать чистый код.

На простом примере схема такова. Есть контроллер, скажем, отвечающий за регистрацию.

1. Первое, что необходимо определить, - класс Request, где будут данные, получаемые от клиента: RegisterRequest. async Task<ActionResult> RegisterAsync(RegisterRequest request)

2. Клиенту нужно что-то возвращать (не всегда, поэтому это опционально +1 класс) - view, вьюшка с нужными свойствами для нашего ответа на запрос: RegisterView

3. Так как используется CQRS подход, создаем Команду и ее Обработчик class RegisterCommand : IRequest<RegisterView> class RegisterCommandHandler : IRequestHandler<RegisterCommand, RegisterView>

Соответственно, если следовать этому подходу, то в худшем случае на одну апишку приходится 4 класса, тажке маппинг во View их хэндлера. Меня в принципе это устраивает, то удобство работы, которое оно дает несоизмеримо.

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

Есть контроллер, скажем, отвечающий за создание опроса, где опрос это сложный объект содержащий в себе лист вопросов (объектов), а в вопросе лист вариантов ответов (тоже объектов).

Реквест от юзера

1. CreateSurveyRequest

2. Команда для обработки, где мы маппим реквест для обработки хэндлером. class CreateSurveyCommand : IRequest<CreateSurveyView> class CreateSurveyCommandHandler : IRequestHandler<CreateSurveyCommand, CreateSurveyView>

3. Обрабатываем, маппим во view и отдаем результат. Было бы нереально круто, если бы не вложенность.

Что такое CreateSurveyView? Это объект, в первую очередь класс в котором должен быть лист вопросов (других классов) и так до тройной вложенности.

Под разные задачи на клиент нужно возвращать разную инфу об объекте, поэтому в идеале нужно создать эти три вьюшки и с ними работать. А как их назвать? Answers уже есть - Entity, ну как вариант, чтобы избежать дублирования CreateSurveyView, CreateSurveyQuestionView, CreateSurveyAnswerView, уже что-то не так с этим подходом, а когда мы начнем объявлять листы станет понятно, что выглядит трудночитаемо и восприятие уже не такое быстрое как было раньше.

Тогда в классе CreateSurveyView объявить его классы Answer, Question и работать так CreateSurveyView.Answer, вроде бы да, но когда ты начинаешь работать с этим, маппить это, то уже не так весело. Лично я использую автомаппер Mapster с кодогенерацией через интерфейсы, и когда встает вопрос о названии метода для маппинга начинается та ещё веселуха.

Итого весь сыр бор создают вьюшки. Я не против создания большого количества классов, но их нейминг и работа с ними ведет меня в тупик. Как сделать по красоте, чтобы всё было суперудобно? Я пока не знаю)