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

Question

В Domain Driven Design службы домена должны содержать операции, которые, естественно, не принадлежат внутри объекта.

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

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

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

Должен ли я: OrganizationService::copyOrganization(o)?

Или должен ли он: OrganizationCopyService::copyOrganization(o)?

В целом: - это «услуга» абстрактная концепция, содержащая несколько операций или услуга конкретной операции?

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

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

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

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

Answer 1

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

Answer 2

Это немного мнение основано Я хотел бы добавить его в качестве комментария, но пробежал пробел ,

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

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

Тем не менее, интересно то, что в определении ДДДА фабричного шаблона

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

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

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

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

Некоторые люди используют strange rules of thumb, но я считаю, что вы можете просто пойти с High Cohesion principle и вместе ставить методы с ответственными обязанностями. Поскольку это вопрос DDD, я полагаю, что это касается служб домена (т. Е. Не инфраструктурных служб). Я полагаю, что услуги должны быть разделены в соответствии с их обязанностями в домене.

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