domain-driven-design - 与服务层或域对象本身的接口(interface)？ (DDD)

Question

我仍在学习 DDD，我有两个(可能很简单)问题:

如果 Factory创建新对象/图形/aggregate实例，还有"reconstitutes"来自 Repository 的对象/图表，那么:

(1) 您的服务层函数/作业/任务/工作单元是否调用工厂或实体实例或 DomainService 函数上的行为方法？由于这些组件的职责，我对调用堆栈感到困惑。

(2) 实体实例是否具有如上所述的“行为方法”？例如，帖子是否有 p.UpdatePost(string bodyText) 或者这不是域模型的问题，因此应该使用存储库来实现相同的目的？或者服务层功能，在这种情况下是否应该调用存储库，并且实体实例仅具有特定于域而不是持久性的行为方法？但是，为什么“更新帖子”听起来像是一个领域功能，而这是用户的目标呢？

你可以看到我到处都是。请帮忙。

Answer 1

(1) Does your service layer functions/jobs/tasks/unit-of-work call into the Factory or a behavioral method on the Entity instance or a DomainService function? I'm lost as to the call stack based on the responsibility of these components.

通常 - 顶层检索必要的聚合根并调用其上的函数。有时，顶层会检索多个聚合根并将它们传递给域服务，但这种情况并不常见，因为域服务是一个非常强烈的信号，表明存在无法识别的聚合根。在最后 - 顶层确保聚合根被持久化。

(2) Do Entity instances even have "behavioural methods" like above? For example does a Post have p.UpdatePost(string bodyText) or is that not a concern of the domain model and so the same should be achieved with the Repository? Or the service layer function, should it be calling the Repository in this case and the entity instance simply have behavioural methods that are specific to the domain and not persistence? But then, why does it sound like "updating a post" is a domain function when that's the user's goal?

是的，他们确实如此。领域模型应该意识到它的状态变化。乍一看，这更有益。这样做的好处是您可以获得可扩展性点。如果客户一周后走到您面前并说他希望系统在用户更新帖子时检查其他内容 - 而不是搜索 post.bodyText="new value" 的每一行，您将能够直接进入 post.UpdatePost 方法并在那里附加必要的内容。

另一方面 - CRUD 与领域驱动设计并不相互排斥。例如。 - 在我的应用程序中，用户及其角色的管理非常无趣，我什至没有尝试对其进行精细建模。您需要认识到您的应用程序正在描述和使用的业务中重要的部分。

请记住，领域驱动设计仅对复杂的应用程序有意义。简单的博客应用不需要它。

(3) Am I wrong in assuming that a service layer (not Domain Services) should encapsulate how an interface interacts with the Domain Layer?

在我看来 - 应用程序服务更多的是用于编排基础设施。如果不涉及基础设施-则应用程序服务loses value :

Application services basically are just facades. And every facade is bad if complexity it adds overweights problems it solves.

<小时/>

内部域:

//aggregate root is persistence ignorant. 
//it shouldn't reference repository directly
public class Customer{
  public string Name {get; private set;}
  public static Customer Register(string name){
    return new Customer(name);
  }
  protected Customer(string name){
    //here it's aware of state changes.
    //aggregate root changes it's own state
    //instead of having state changed from outside
    //through public properties
    this.Name=name;
  }
}

//domain model contains abstraction of persistence
public interface ICustomerRepository{
  void Save(Customer customer);
}

域外:

public class CustomerRepository:ICustomerRepository{
  //here we actually save state of customer into database/cloud/xml/whatever
  public void Save(Customer customer){
    //note that we do not change state of customer, we just persist it here
    _voodoo.StoreItSomehow(customer);
  }
}

//asp.net mvc controller
public class CustomerController{
  public CustomerController(ICustomerRepository repository){
    if (repository==null)throw new ArgumentNullException();
    _repository=repository;
  }
  public ActionResult Register(string name){
    var customer=Customer.Register(name);
    _repository.Save(customer);
  }
}