domain-driven-design - 只读数据库视图如何适应存储库模式？

Question

示例：您的数据库有一个名为“CustomerOrdersOnHold”的 SQL 视图。此视图返回特定客户和订单数据字段的过滤组合。您需要在应用程序中从此视图中获取数据。对这种视图的访问如何适应存储库模式？你会创建一个“CustomerOrdersOnHoldRepository”吗？像这样的只读视图是否被视为聚合根？

Answer 1

我更喜欢分离读取存储库，最好甚至将其名称更改为 Finder 或 Reader，该存储库是用于域使用而不是用于查询只读数据，您可以参考这篇文章，它解释了 Finder 分离表单存储库的用法.

我还建议将读取模型与写入模型架构CQRS分开

即使在数据存储和事件源的使用方面，这种架构也允许您将读取模型与写入模型分开。

对于中间解决方案，您可以利用一些 CQRS 概念，而无需通过仅将存储库与查找器分离来分离数据库的复杂性，阅读这篇文章

对于此类解决方案的示例（使用相同的数据库，但将查找器与存储库分开）检查此示例

Answer 2

我认为拥有像“CustomerOrdersOnHoldRepository”这样的单独存储库很好。存储库的接口将反映对象是只读的这一事实（通过不定义 Save/Add/MakePersistent 方法）。

从如何编写存储库：

...但是我非常喜欢另一种策略：多个存储库。在我们的排序示例中，我们没有理由拥有两个存储库：AllOrders 和 SurchargedOrders。AllOrders 表示包含系统中每个订单的列表，SurchargedOrders 表示其中的一个子集。

我不会将返回的对象称为聚合根。聚合用于一致性、数据交换和生命周期。您的对象没有这些。似乎它们也不能归类为值对象（“特征或属性”）。它们只是独立的类。

Answer 3

您的只读数据将被视为 DDD 世界中的值对象。

我通常将值对象的访问方法放在现有存储库中，直到创建一个单独的存储库有意义。它类似于可能返回要在地址表单上使用的静态状态列表的方法：

IAddressRepository
{
  Address GetAddress(string addressID);

  List<string> GetStates(string country);
}