服务契约与域对象

Question

假设我的应用程序有两个接口：

• Web 前端
• 提供数据的后端

它们都与 Web 服务通信，而该 Web 服务又处理业务逻辑并与单独的数据层通信，它保留了对象。

因此，如果 Web 服务的每个客户端都使用该 Web 服务的 DataContracts，我需要域对象做什么？

领域驱动设计在这里适合什么，它给我的架构带来了哪些优势？

或者是我已经拥有的很好，并且我根本不需要域对象？

我是否误解了领域驱动设计的含义和目的？

Answer 1

数据契约只不过是客户端和服务器之间交换的消息。

您的 WCF 服务是接受消息并处理它们的层，以便您的业务逻辑可以处理它们。

您的域对象将是您的业务逻辑，它接受处理后的消息，执行必要的操作，然后应用需要应用的任何事件。

如果您遵循更多命令-查询分离原则（CQS），那么您的命令（插入/updates/deletes) 将被发送到 WCF 服务并且不会返回任何内容。您的客户端将请求从您的 WCF 服务中独立于您的命令进行读取（这意味着 InsertOrder 命令不会返回订单 - 您必须为此发出单独的请求）。

总而言之，您的数据协定就是往返于 WCF 服务的消息。您的域位于该服务的后面，处理需要发生的所有业务逻辑，以使您的读取尽可能准确。

我更多地从 CQRS（命令查询责任分离）的角度来回答这个问题，但我希望这能解释我的出发点。

回答你的另一个问题：
- 您需要域对象吗 -->我会说是的，你应该

Answer 2

我需要域对象做什么？

您的应用程序中可能不需要域对象。通常，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 携带的数据用于对您的域实体进行操作。