1

Я новичок в DDD, и я не знаю, что делать с обычным поведением домена, которое должно быть сделано в ViewModel.DDD: (Domain And ViewModel) => Общее поведение

сказать, что у меня есть Order.Ship(), который должен быть выполнен во время ввода данных. Кажется, эта операция должна быть выполнена моим ViewModel (при вводе данных).

Я обертывание DTO по более ViewModel И каждый DTO получил от ApiController, я должен поместить Ship() внутри Order Entity или ViewModel?

Каково использование Domain Behaviors здесь, пока я просто перехожу в состояние ViewModel?

Я в истинном драйве?

+1

Чтобы вычислить зарплату, скорее всего, бизнес-логику, и ее нужно делать в домене, а не в представлении.Если вы вычислите его в своей модели ViewModel, вы используете интеллектуальный интерфейс, который вы, вероятно, захотите избежать. –

+0

@ Alexander Langer: только что отредактировал – Mohsen

ответ

2

Я новичок в DDD, и я не знаю, что делать с общим поведением домена, которое должно быть сделано в ViewModel.

Нет, поведение домена должно оставаться в домене и не должно просачиваться в другие слои. Особенно для пользовательского интерфейса.

сказать, что у меня есть Order.Ship(), который должен выполняться во время ввода данных. Кажется, эта операция должна выполняться моей ViewModel (при вводе данных).

ViewModel просто DTO и не должны иметь другой логики, чем просто форматирование данных для представления, проверки его и т.д. Так нет, никакой логики домена не должен вызываться внутри ViewModel. Вместо этого вы должны использовать не какой-то уровень служб приложений (это необязательно, но часто добавляет более четкое разделение обязанностей), который находится между пользовательским интерфейсом и доменным уровнем. Этот прикладной уровень может использовать функции Cross-cut, такие как Logging, Tranasactions и т. Д. Обычно этот прикладной уровень создается из бизнес-приложений, таких как «Порядок доставки», в котором вы можете затем вызывать бизнес-логику Order.Ship(). Если у вас нет этого прикладного уровня, так это роль ApiControllers позаботиться об этой ответственности.

Я обматываю DTO с помощью ViewModel. И каждый DTO получил от ApiController, должен ли я помещать Ship() внутри объекта Order или ViewModel?

Если метод Ship() является логикой домена, он должен находиться в сущности домена или службе домена.

Что такое использование доменных правил здесь, пока я просто перемещаю состояние в ViewModel?

Я думаю, что вы имеете в виду перемещение состояния к ViewModel по запрашивая от состояния домена. Даже если я не думаю, что это хорошая идея запросить модель домена, которая в основном предназначена для «команд», а не для запросов. Однако, если вы это сделаете, ответственность за «переход от состояния домена к ViewModels (DTO) лежит на ApiController (или службе приложения, если у вас есть)).

+0

Спасибо, Есть ли более простой способ свести к минимуму вызовы 'APIController' в этом подходе? (Потому что я могу сделать это без вызовов клиент/сервер) – Mohsen

+0

Что вы имеете в виду? ApiController находится перед границей пользователя/машины (взаимодействие). Поэтому, если вы хотите свести к минимуму звонки, вам нужно использовать кеширование, что является хорошим способом реализации сервисов Restful. –

+0

Я имею в виду, что некоторые операции могут выполняться на стороне клиента, не вызывая «серверные службы» (мое клиентское приложение - «WPF») и влияет на состояние его «ViewModel» или «DTO», а затем передает его на «службу на стороне сервера» ', а затем' server side service 'применяет изменения к 'Entity'. – Mohsen

Смежные вопросы