Лучший дизайн для доменного сервиса

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

Рабочий процесс приложения, которое будет использовать этот сервис:

  1. Пользователь выбирает некоторые условия (например, дату и другие данные)
  2. Он получает список «предложений» сущностей. Он может выбрать все из них или только некоторые.
  3. Сущности созданы

Каков был бы лучший дизайн для службы домена? Я имею в виду два:

Решение 1

interface IMyDomainService
{
    IEnumerable<EntityProposition> GetEntitiesPropositions(Conditions conditions);
    void CreateEntities(Conditions conditions);
}

В этом случае у меня, вероятно, будет какой-то частный метод в службе, который будет использоваться обоими из них. Класс EntityProposition в основном представляет собой 1:1 того, что будет отображаться в представлении. В этом классе есть некоторые данные, которые не являются частью самого объекта.

Решение 2

interface IMyDomainService
{
    IEnumerable<EntitiyData> GetDataForEntities(Conditions conditions);
    void CreateEntities(IEnumerable<EntityData> entities);
}

То, что было бы закрытым методом в Решении 1, теперь отображается в интерфейсе. Класс EnityData содержит все данные для объекта, необходимые для создания самого объекта и отображения всех данных для просмотра.

Чтобы добавить некоторый контекст: эта служба теперь используется непосредственно контроллером ASP.NET MVC. Мне кажется, что если я выберу решение № 2, мне придется создать какую-то дополнительную службу приложения, чтобы она обернула логику получения данных и создания сущностей.

РЕДАКТИРОВАТЬ 1

Я задам вопрос с другой точки зрения: должен ли мой контроллер выглядеть так:

public ActionResult GetPropositions(Condtidions condtitions)
{
    var entitiyData= service.GetEntityData(conditions);
    return Json(entitiyData.ToViewModel());
}

public void CreateEntities(Conditions conditions)
{
    var entitiyData= service.GetEntityData(conditions);
    service.CreateEntities(entitiyData);
}

or:

public ActionResult GetPropositions(Condtidions condtitions)
{
    var propositions = service.GetPropositons(conditions);
    return Json(propositions.ToViewModel());
}

public void CreateEntities(Conditions conditions)
{
    service.CreateEntities(conditions);
}

Конечно, это упрощенный пример, просто чтобы показать мою точку зрения.

Редактировать 2

В качестве дополнения: сначала я выбрал решение № 2, но позже мои требования изменились, и мне пришлось вернуться к решению № 1. Причина заключалась в том, что после создания предложений пользователь мог выбрать несколько из них, но с тем же объемом (условиями).


c# asp.net-mvc-3 domain-driven-design
person Botis    schedule 18.06.2013    source источник
comment
Я очень надеюсь, что метод ToViewModel является методом расширения. Потому что он не принадлежит домену. Что касается вашего редактирования, GetPropositons больше похоже на язык домена.   -  person jgauffin    schedule 19.06.2013
comment
ToViewModel вообще нет, просто в примере показано, что результат сопоставляется с моделью представления после его извлечения. Спасибо за вашу помощь!   -  person Botis    schedule 19.06.2013

Ответы (1)


arrow_upward
3
arrow_downward

Какой самый распространенный случай? Создавать много сущностей или создавать одну?

Также я бы не стал использовать Entites в именах методов, ведь очевидно, что сервис работает с сущностями.

Для меня это имя звучит так, как будто вы просто обертываете репозиторий сервисами. Это большое нет-нет. Службы в DDD — это расширение сущностей предметной области для инкапсуляции логики, когда вам приходится работать с двумя или более сущностями в одном и том же бизнес-кейсе.

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

interface IMyDomainRepository
{
    IEnumerable<EntitiyData> GetData(Conditions conditions);
    void Create(IEnumerable<EntityData> entities);
}
person jgauffin    schedule 18.06.2013
comment
Что касается вопроса № 1, я бы сказал, что наиболее распространенным было бы создание объектов из всех предложений. Сущность — это просто заполнитель — в моем коде есть имена получше :) Это не просто получить->редактировать->сохранить. Допустим, у меня есть какое-то логическое свойство в данных объекта, и при создании объекта у меня есть логика вроде if (это свойство && somethingelse && x›8) entity.children.add(something) - person Botis; 18.06.2013
comment
эта логика принадлежит самой сущности, а не службе. - person jgauffin; 18.06.2013
comment
+1 Полностью согласен с вашим ответом. Однако кажется, что EntityProposition — это еще одна сущность в доменном/ограниченном контексте, а не просто набор параметров, которые передаются в репозиторий. Похоже, что на самом деле нам нужна фабрика. - person MattDavey; 18.06.2013