методы в объектах DDD против сервисов

Question

Наша команда довольно плохо знакома с DDD и пытается реализовать некоторые концепции в нашем текущем проекте. Один вопрос, который возник, состоит в том, помещать ли методы в объекты сущностей или объекты-службы.

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

Нам интересно, какова официальная точка зрения DDD на это, а также то, что сработало для людей в реальной жизни.

Answer 1

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

Одна из школ считает, что доменные объекты должны быть POCO / POJO, что означает, что они не должны содержать абстрактные сервисы в качестве членов.Однако это не означает, что у них не может быть методов, которые взаимодействуют с такими сервисами.

Чем больше (релевантного) поведения вы можете дать каждому объекту домена, тем лучше.*

Answer 2

Согласно Домен-управляемый дизайн Быстро , существует три основных типа объектов.

• Сущность
• Объекты значения
• Услуга

Бизнес-логика приложения реализована во всех этих трех объектах, но мы предостерегаем от разумного разделения логики.

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

С другой стороны,

Служба не должна заменять операцию, которая обычно принадлежит объектам домена. Мы не должны создавать Сервис для каждой необходимой операции. Но когда такая операция выделяется как важная концепция в домене, для нее должна быть создана служба. Существует три характеристики услуги:

1. Операция, выполняемая Сервисом, относится к концепции домена, которая, естественно, не принадлежит сущности или объекту значения.
2. Выполненная операция относится к другим объектам в домене.
3. Операция без сохранения состояния.

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

Наконец, не добавляйте методы к объектам домена только для того, чтобы избежать анемичной модели домена.

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