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

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 (разделение ответственности между запросами и командами)в перспективе, но я надеюсь, что это объясняет, откуда я иду.

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