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

Question

只是从DDD开始。 我了解所有域实体及其逻辑应与存储库接口一起保留在域层中。 在我的应用程序中，我将一些数据存储在数据库中，这些数据用于在运行时构造用户界面（表示层）的各个部分。 在应用程序层或域层中，应将此类类型的poco类和存储库接口保留在何处。 我无法确定，因为这些对象将没有任何与域相关的业务逻辑，但是它们需要从数据库中合并，并且我使用的是EF，因此对于数据访问，我将需要实体和存储库，因此对我来说显而易见的选择是将它们与域层中的所有其他实体和存储库接口，但违反了DDD规则

Answer 1

在应用程序层。 保持域完整无缺且相互隔离。

Answer 2

考虑这一点的一种好方法-如果出于性能原因必须用存储过程替换EF，则不必修改域代码。 因此，所有需要隐藏的东西都必须隐藏在接口后面并使其可替换。

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

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

Answer 3

我认为您已经回答了自己的问题：

在我的应用程序中，我将一些数据存储在数据库中，该数据用于在运行时构造用户界面（ 表示层 ）的各个部分。

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

但是，不同的表示层实现可能需要不同的数据。 因此，将演示数据访问直接放置在演示层中。 这可以使用EF来实现，而EF并非DDD方案所独有。