Контракты на обслуживание и доменные объекты

Question

Скажем, у меня есть два интерфейса для моего приложения:

• Веб-интерфейс
• Серверная часть, которая предоставляет данные

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

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

Где здесь подходит управляемый доменом и какие преимущества он дает моей архитектуре?

Или это тот случай, когда то, что у меня уже есть, хорошо, и мне вообще не нужны доменные объекты?

Я неправильно понимаю значение и цель доменного дизайна?

Answer 1

Для чего мне нужны доменные объекты?

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

public MyEntityDto GetMyEntity(string id) {

  var entity = this.myEntityRepository.Get(id);
  if (entity == null)
    return null;
  return new MyEntityDto(entity);

};

В этом случае MyEntityDto является объектом DTO для MyEntity, он служит для предоставления определенных свойств MyEntity, которые служба желает предоставить своим клиентам.

Значение DDD вступает в игру, когда ваш домен более сложный и имеет соответствующее поведение:

class MyEntity {
 public void ChangeState(MyEntityState state) {
    if (!IsValidState(state))
      throw new Exception("Not a valid state.");
    // further domain logic here...
 }
}

[DataContract]
class ChangeStateCommand {
  [DataMember]
  public string MyEntityId { get; set; }
  [DataMember]
  public string State { get; set; }
}

public void Process(ChangeStateCommand command) {
  var entity = this.myEntityRepository.Get(command.MyEntityId);
  if (entity == null)
   throw new SomeException().

  entity.ChangeState(command.State);
  this.myEntityRepository.Commit();
}

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

Answer 2

Контракты на данные - это не что иное, как сообщения, которыми ваш клиент и сервер обмениваются между собой.

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

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

Если вы следуете более принципу разделения команд и запросов (CQS), то ваши команды (вставки / обновления / удаления) будут запущены для службы WCF и ничего не возвращают. Ваш клиент будет запрашивать чтение из вашей службы WCF отдельно от ваших команд (это означает, что команда InsertOrder не возвращает Order - вы должны выполнить отдельный запрос для этого).

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

Я отвечаю на это с большей точки зрения CQRS (разделение ответственности командного запроса), но я надеюсь, что это объясняет, откуда я.

Чтобы ответить на ваш другой вопрос: - вам нужны доменные объекты -> я бы сказал, да, вы должны