Architecture 业务对象方法中的存储库对象

我过去认为域对象的方法中不应该包含存储库调用。然而，我面临着以下问题
我知道域对象必须始终处于集成状态。 例如，如果您有一条规则，即没有订单行订单就不能存在，则需要在订单构造函数中添加订单行，并使LineOrder集合为只读

在我的情况下，如果订单移动到批准状态，我需要检查客户是否有足够的钱来订购，以及应用程序是否可以为该客户转账，然后关联转账到订单。因此，my order.Approve方法需要调用相应的存储库方法来检查是否可以批准订单并获取所需的导航属性（订单-转移关联）

若我并没有在approve方法中进行检查和分配，也并没有在OrderService类中创建approve方法（因为approve可能被视为流程），那个么若有人在其他代码部分调用它，我的approve方法可能会导致对象进入未集成状态

因此，我的问题是： 1.如果在域对象方法中使用存储库是不对的，那么如何解决上述对象的完整性问题

---

2.如果批准不是流程，那么客户订单样本中的流程是什么？：）

也许您应该考虑一个实体可以有多个验证上下文

你的问题的答案如下： 1） 您不应该在域模型中使用存储库。

---

2） Approve看起来更像是一个与服务相关的问题，与您的订单无关。

范例

 foreach(var transfer in myOrder.Customer.Transfers)

通过访问myOrder.Customer，客户对象从数据库加载

通过访问

myOrder.Customer.Transfers

将从数据库加载Transfers集合

这样就不需要访问存储库

---

下面是一个如何消除业务方法中对存储库的需求的示例：。

hmm，多重验证上下文是什么意思？每个订单状态都必须有单独的验证代码？我的意思是一个实体类在不同的上下文中可以有不同的验证规则（基于执行的操作）。请阅读这篇文章：谢谢你的回答，是的，你的答案接近我得到的最终解决方案，我认为服务将有批准方法，这将获得所需的传输并将其作为参数传递给order.approve，在这种情况下，order将使用其内部状态在approve方法中进行一些计算，order.approve将有自己的验证规则。在这种情况下，我不会在订单代码中引用存储库，订单将具有完整性。谢谢。你知道，还有一个DDD雅虎集团：。在那里你可以找到比我更有经验的人；你可以通过阅读（一些）问题和（一些）答案学到很多，它们可以提供更完整的指导。对不起，听起来像是广告，但这是真的。