Отправить объект домена в качестве параметра или отправить идентификатор объекта в качестве параметра в службах приложений

Question

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

например:

public void Apply(Job job, User user)

против

public void Apply(int jobId, int userId)

Answer 1

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

Передавая всю сущность, вы можете сразу извлечь выгоду из поведения сущности, не создавая ее сначала.

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

public void Apply(int jobId, int userId)
{
    // Validate the IDs.

    // Construct the entities.
    var job = ...;
    var user = ...;

    // Call the 'proper' overload.
    Apply(job, user);
}

public void Apply(Job job, User user)
{
    // Actual business logic belongs here.
}

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

С точки зрения кодирования, сущности также лучше, чем целые числа. Целое число может иметь любое целочисленное значение, поэтому вам придется проверять его везде, где вы его используете. Ваши фабрики несут ответственность за создание действительных сущностей, и ваша логика (домена) должна поддерживать ваши сущности в действительном состоянии. Таким образом, использование сущности абсолютно безопасно и не требует большой проверки.

Answer 2

Это зависит от , где ваша Служба приложений находится:

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

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

Если вы попытаетесь отправить объекты по проводам, вы, вероятно, столкнетесь с проблемами , описанными здесь .

Надеюсь, это поможет.

Answer 3

Я использую ViewModel для передачи "плоских объектов" в / из службы приложений.Также я использую шаблон сообщения документа для связи со службой приложения.В сервисе приложений используются методы расширения для бизнес-сущностей, например:

public BusinessEntityViewModel ConvertToViewModel(this BusinessEntity businessEntity)
{
      BusinessEntityViewModel bevm = new BusinessEntityViewModel{ Id = businessEntity.Id, ...}
      return bevm;
}

Answer 4

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

Answer 5

В моем понимании, разница заключается только в том, что Домен делает с Пользователем и Заданием для выполнения операции «Применить». Если ID вполне достаточно, тогда можно оставить только ID.