Domain driven design 什么类型的代码适合服务层？

假设您有实体、服务层和存储库（使用类似NHibernate的ORM）。UI与服务层交互

什么类型的代码适合服务层？

---

存储库协调？

看起来服务层中是否应该存在加载/保存/逐出实体的调用

涉及存储库的业务逻辑？

如果上述情况属实，是否应该在服务层中执行类似于检查用户名是否不同的操作（即调用GetUsersByUsername并检查结果）？在建议DB处理distinct之前，如何验证密码在90天内未被使用

涉及多个实体的业务逻辑？

我不确定这一点，但假设您需要对一组实体应用一个操作，这些实体可能相关，也可能不相关，并且实际上不适用于单个实体。实体应该能够对这些集合进行操作，还是这类事情属于服务层

映射？

无论您使用DTO还是将实体发送到服务层或从服务层发送实体，您都可能最终使用映射（最好使用AutoMapper）。这属于服务层吗

---

我希望确认（或拒绝）上面列出的想法，以及在使用实体/存储库时关于服务层职责的任何其他想法

存储库协调

聚合根应该绘制事务边界。因此，应该很少涉及多个存储库。如果是-通常在创建新的聚合根时发生（而不是修改其状态）

---

涉及存储库的业务逻辑

是的，检查用户名是否不同可能存在于服务层中。因为用户通常是聚合根，聚合根生活在全局上下文中（并没有任何东西“容纳”它们）。我个人将这种逻辑放在存储库中，或者直接通过ORM进行检查

至于检查密码使用情况——这是用户本身的问题，应该放在用户对象下面。大概是这样的：

class User{
  void Login(){
    LoggedOn=DateTime.Now;
    ...
  }
  bool HasLoggedInLast90Days(){
    return (DateTime.Now-LoggedOn).Days<=90;
  }
}

而是使用：

class Order{
  void IsOverdue(){
    return ...;
  }
}

---

映射

我假设映射到dto的实时服务层。我的映射类位于web项目中视图模型类的旁边

class Customer{
  void IsOrderOverdue(Order order){
    return Orders.First(o=>o==order)....==...;
  }
}

class Order{
  void IsOverdue(){
    return ...;
  }
}