Модель домена службы приложений DDD для просмотра сопоставления моделей

Question

Мое понимание сервисов приложений заключается в том, что они связывают между доменом и пользовательским интерфейсом. Другими словами, они служат контроллеру для выполнения операций над доменом.

У меня есть следующий макет проекта в моем приложении:

• домена Ядра
• Инфраструктура
• Service Interfaces
• Web UI
  • ViewModels
  • Просмотров
  • Контроллеры
  • Услуги (Application Services)

Мои Service Interfaces лежит вне проекта Web UI. Затем в проекте Web UI я реализую интерфейсы служб под Services.

Однако эта структура немного ошибочна и создает круговую зависимость, когда мы применяем это на практике. Я попытался следовать архитектуре в этой ссылке. https://www.develop.com/onionarchitecture

Для данной услуги я хочу передать модель представления, выполнить операции над доменом на основе модели представления, а затем вернуть обновленную модель представления. Является ли этот подход неправильным?

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

Или

ли служба приложений иметь дело только с C# и типов данных моделей предметной области в качестве параметра и возвращает те же тип данных? Другими словами, не получается или не задана какая-либо информация в модели представления. На самом деле не известно, что существует модель представления.

Мне просто нужно уточнить, что является лучшим подходом от строгого подхода DDD.

Answer 1

Отвечая на ваши вопросы: Да, вы правы. Для приложения MVC вы можете создать слой, который принимает и возвращает ViewModels и работает с доменом внутри

Хороший пример структуры решения сделан Dino Esposito here. Я применил свой проект к этой структуре, и стало ясно. Мое мнение таково, что onion architecture сложнее для небольших или средних проектов.