领域驱动设计中对持久化的呼唤在哪里

Question

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

我的 Order 模型有两个选项：

1. 在域程序集中有一个Order类和一个IOrderRepository接口。Order类有一个IOrderRepository在构造函数中传递的私有实例。Order 类有一个公共Insert方法，该IOrderRepository.Insert方法调用该方法。存储库的实际实现是在OrderRepository基础设施层的类中。服务层将包含一个OrderService类，该类使用适当的存储库实例化我的模型，然后调用Order.Insert(). 坏处：我们必须将存储库的一个接口（或多个实例）注入模型类，持久化逻辑在模型内部。好：有时候有些事情开始前或后插入方法被调用完成，这可以很好地融入Insert的方法Order 类，例如引发领域事件或其他什么。
2. 在Model程序集中只有Order类。服务层创建 newOrder和 newOrderRepository并执行orderRepository.Insert(order).

你能不能用简单的话解释一下哪个概念更好（像我五岁那样解释）。

Answer 1

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

让我们从编码的角度考虑这个设计。您必须为每个 提供存储库实例Order，然后调用order.Insert()此订单将其自身传递给您已注入订单的存储库。听起来很复杂。将使用更简单repository.Save(order)。有时可以在类上使用 CRUD 方法（请参阅Active Record模式）。但是当您没有复杂的域模型时，这种方法很好。

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