Question

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

网络前端
提供数据的后端

他们都与网络服务交谈，反过来，该网络服务处理业务逻辑并与单独的数据层进行对话，该数据层会持久保存对象。

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

域驱动设计在哪里适用，它为我的架构带来了哪些优势？

或者就是那种我已经很好的情况，我根本不需要域对象？

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

Answer 1

数据合同只不过是客户端和服务器之间相互交换的消息。

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

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

如果您遵循更多Command-Query Separation原则（CQS），那么您的命令（插入/更新/删除）将被触发到WCF服务而不返回任何内容。您的客户端将请求与您的命令分开的WCF服务读取（意味着InsertOrder命令不返回订单 - 您必须为此发出单独的请求）。

在所有这些中，您的数据协定是进出WCF服务的消息。您的域位于该服务的后面，处理所有需要发生的业务逻辑，以使您的读取尽可能准确。

我从更多的CQRS（命令查询责任隔离）角度回答这个问题，但我希望这能解释我来自哪里。

回答你的另一个问题： - 你需要域名对象 - ＆gt;我会说是的，你应该

Answer 2

我需要什么域对象？

您的应用程序中可能不需要域对象。通常，DDD将通过以下方式适合服务层：服务层公开其操作合同和数据合同。数据协定类通常对应于域中的对象，但它们不是域对象，因为它们没有任何行为，它们只是与特定服务相关的数据的表示。以下是服务中数据协定对象和域对象之间的简单示例交互：

public MyEntityDto GetMyEntity(string id) {

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

};

在这种情况下，MyEntityDto是MyEntity的DTO对象，它用于公开服务希望提供给客户端的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携带的数据用于对您的域实体进行操作。

服务合同与域对象

2 个答案: