Доменные службы DDD: что должен содержать класс обслуживания?

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

у меня была привычка создайте одну службу на объект и группировать некоторые методы внутри него (Organization сущность и OrganizationService службы).

но чем больше я думаю об этом: OrganizationService ничего не значит, "организация" составляет не услуги, это вещь.

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

должен ли я сделать:OrganizationService::copyOrganization(o)?

или я должен делать: OrganizationCopyService::copyOrganization(o)?

в целом: является ли "услуга" абстрактной концепцией, содержащей несколько операций, или услуга является конкретной операцией?

редактировать: больше примеров, приведенных в первом, было не так хорошо:

  • StrategyService::apply()/cancel() или StrategyApplicationService::apply()/cancel()? ("Приложение" здесь не связано с прикладным уровнем;)
  • CarService::wash() или CarWashingService::wash()?

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

*Примечание: это не вопрос о мнении! Это точный, ответный вопрос о методологии проектирования, управляемой областью. Я всегда надоедают близкие голоса, когда спрашивают "должен ли я", но там is способ DDD делать вещи.*

6
ddd-service domain-driven-design

2 ответов

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

4

это немного мнение, основанное на том, что я хотел добавить его в качестве комментария, но закончилось пространство.

Я верить что в этом случае имеет смысл сгруппировать методы в одну отдельную организацию-службу с различным методом построения. 

   interface OrganizationFactory{
       Organization createOrganization();
       Organization createOrganizationCopy(Organization organization);
   }

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

тем не менее, интересно то, что в ddd определение Заводского шаблона

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

слово "объект" в общем смысле даже не должно быть отдельным класс но также может быть заводским методом (я имею в виду как метод класса, так и шаблон метод фабрики) - позже Эванс приводит пример Заводского метода Brokerage Account это создает экземпляры Trade Order.

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

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

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

обновление 2 в любом случае CarService могу сделать CarService::wash()/ CarService::repaint() / CarService::diagnoseAirConditioningProblems() но будет странно, что CarWashingService сделает CarWashingService::diagnoseAirConditioningProblems() это похоже на генеративную грамматику Хомского - некоторые утверждения (предложения) в языке имеют смысл, некоторые нет. Но если ваше предложение содержит слишком много предметов (более 5-7), его также будет трудно понять, даже если оно действительно на языке.

1