与服务层或域对象本身的接口？ （DDD） [英] Interface with service layer or domain objects themselves? (DDD)

问题描述

我仍在学习DDD，并且有两个（可能很简单）问题：

I'm still learning about DDD and I have these two (probably simple) questions:

如果工厂创建新对象/图/ 聚合实例，还可以重构 存储库，然后：

If a Factory creates new object/graph/aggregate instances, but also "reconstitutes" objects/graphs from the Repository, then:

（1）您的服务层功能/职位/任务/工作单位是否调用了Factory或Entity实例上的行为方法或DomainService函数？基于这些组件的职责，我对调用堆栈一无所知。

(1) Does your service layer functions/jobs/tasks/unit-of-work call into the Factory or a behavioural 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）实体实例甚至具有上述的行为方法吗？例如，帖子具有 p.UpdatePost（string bodyText）还是不是域模型的问题，因此使用存储库也可以实现吗？还是服务层功能，在这种情况下是否应该调用存储库，并且实体实例仅具有特定于该域的行为方法而不是持久性？但是，那么，当这是用户的目标时，为什么听起来像更新帖子是域功能？

(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?

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

You can see I'm all over the place. Please help.

推荐答案

（1）您的服务层是否在功能/工作/任务/单元-工厂中的工作调用或Entity实例或DomainService函数上的行为方法？基于这些组件的职责，我对调用堆栈一无所知。

(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.

通常-顶层检索必要的汇总根并调用一个功能就可以了。有时，顶层会检索多个聚合根并将其传递给域服务，但并不是经常这样做，因为域服务是一个很强的信号，表明存在无法识别的聚合根。最后-顶层确保持久保留聚合根。

Usually - top level retrieves necessary aggregate root and calls a function on it. Sometimes top level retrieves multiple aggregate roots and pass them to domain service, but not often because domain service is a quite strong sign that there is unrecognized aggregate root. At the end - top level ensures aggregate root is persisted.

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

(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 方法并在其中附加必要的内容。

Yes, they do. Domain model should be aware of it's state changes. And that's much more beneficial as it seems at first. Great thing about this is that You gain extensibility point. If client will walk week later to You and say that he wants system to check additional things when user updates post - instead of searching every line of post.bodyText="new value", You will be able to go straight to post.UpdatePost method and attach necessary things there.

手-CRUD与域驱动设计不是互斥的。例如。 -在我的应用程序中，对用户及其角色的管理不够有趣，以至于我什至没有尝试对其进行精细建模。您需要认识到业务中重要的部分。应用程序正在描述和使用。

On the other hand - CRUD is not mutually exclusive with domain driven design. E.g. - in my application, management of users and their roles is uninteresting enough that I'm not even trying to model it granularly. You need to recognize parts what matters in business Your application is describing and working with.

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

Keep in mind that domain driven design makes sense for complex applications only. Simple blog application doesn't need it.

（3）我以为应该封装服务层（而不是域服务）是错误的吗？接口如何与域层交互？

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

如我所见，应用程序服务更多是用于编排基础结构。如果不涉及基础结构，则应用程序服务损失价值：

As I see it - application services are more for orchestrating infrastructure. If there is no infrastructure involved - then application service loses value:

应用程序服务基本上只是外观。如果复杂度增加了它解决的超重问题，那么每个立面都是不好的。

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

---

内部域名：

---

Inside domain:

//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);
  }
}

这篇关于与服务层或域对象本身的接口？ （DDD）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！