C# 域驱动设计中对持久性的调用在哪里

我知道网上和stackoverflow上都有很多类似的信息，但我仍然不确定在我的项目中应该把持久化的逻辑放在哪里。我还没有使用任何ORM、IoC和UnitOfWork概念（对于ddd领域的初学者来说，有太多的新东西）

我的订单模型有两个选项：

在域程序集中有一个

Order

类和一个

iordrepository

接口

Order

类具有在构造函数中传递的

IORDrepository

的私有实例。Order类有一个公共的

Insert

方法，该方法调用

iordrepository.Insert

方法。存储库的实际实现在基础架构层的

OrderRepository

类中。服务层将包含一个

OrderService

类，该类使用适当的存储库实例化我的模型，然后调用

Order.Insert（）

。坏：我们必须将存储库的一个接口（或多个实例）注入模型类，持久性逻辑在模型内部。好处：有时在调用insert方法之前或之后必须做一些事情，这可以很好地适应

Order

类的

insert

方法，例如引发域事件或其他什么

在

模型

组件中，只有

订单

类。服务层创建新的

Order

和新的

OrderRepository

并执行

OrderRepository.Insert（Order）

---

请您用简单的话解释一下哪个概念更好（像我五岁一样解释）。

您的域类应该只关注域的业务逻辑，并且它们应该是持久性的（即持久性应该与业务逻辑分离）。添加与持久性相关的操作违反了单一责任原则。此外，对存储库的依赖使域类变得复杂，而不是简单的POCO实体

让我们从编码的角度来考虑这个设计。您必须为每个

订单

提供存储库实例，然后调用

Order.Insert（）

，以便该订单将自身传递给您已注入订单的存储库。听起来很复杂。更简单的方法是使用

存储库。保存（订单）

。有时在类上使用CRUD方法是可以的（请参见模式）。但当您没有复杂的域模型时，这种方法是很好的

---

我认为域持久化的最佳位置是应用程序服务（也许您将此层称为服务层）。它们从存储库中加载实体，执行操作（可以是对实体的简单操作，也可以是对域服务的调用），然后保存域的状态。

然后有单独的单元测试，一个用于Order类（仅业务逻辑），另一个用于OrderService类（使用模拟存储库）？@sventevit，针对您域的业务规则的一组测试。应用程序逻辑的其他测试集如果您在模型类中需要一些复杂的逻辑，需要调用其他存储库或基础结构调用，该怎么办？@sventevit您不应该在域类上有这样的逻辑：）持久化或与基础结构层通信是应用程序服务的责任