DDD中的非业务逻辑数据库访问

Question

刚开始使用DDD。据我所知，所有域实体及其逻辑应与存储库接口一起保存在Domain层中。在我的应用程序中，我将一些数据存储在数据库中，用于在运行时构造用户界面（表示层）的一部分。在应用层或域层中，我应该在哪里保留这些类型的poco类和存储库接口。我无法理解，因为这些对象不会有任何域相关的业务逻辑，但它们需要从数据库中保持水分而我使用EF因此对于数据访问我需要实体和存储库所以对我来说显而易见的选择是保持它们域层中的所有其他实体和存储库接口但会破坏DDD规则

Answer 1

在“应用程序”层中。保持域名完整和孤立。

Answer 2

考虑到这一点的好方法是 - 如果出于性能原因必须用存储过程替换EF，则不必修改域代码。所以阻止它的任何东西都需要隐藏在界面后面并且可以替换。

存储库可以是域逻辑的一部分。然而，不应该是持久性的机制。这可以很容易地封装到DAL服务或其他对象中，当然这些对象被编程到IDALService接口。因此，当您需要切换持久性时（例如，从EF迁移到NoSQL解决方案），您只需编写一个实现IDALService接口的替代版本，您就可以开始了。存储库仍然可以在其中执行逻辑，但现在使用新的方式存储它们（这是一个控制反转的想法）。

至于POCO对象，在DDD中，真正的问题是它们代表什么？它们是实体，需要持久化吗？他们重视对象吗？不要让技术（EF）确定对象模型的结构，而是提供转换为应用程序范围的方法。

Answer 3

我想你已回答了自己的问题：

  

在我的应用程序中，我将一些数据存储在以前的数据库中   在运行时构建用户界面的一部分（表示层）   时间。

应该在表示层中封装对用于提供UI的数据的访问。这与应用程序层的不同之处在于，DDD应用程序层通过编排存储库并委派给适当的实体域服务来实现用例 - 它在您的域层周围形成API。不同的表示实现可以使用相同的应用程序服务。

然而，不同的表示层实现可能需要不同的数据。因此，直接在表示层中放置演示数据访问。这可以通过EF实现，这不是DDD场景专用的。