我通常会尝试将所有相关实体保存在同一个存储库中。以下是两者之间有关系的实体（标有缩进）：
因此，进入用户存储库是有意义的。但是，用户通常与许多不同的实体相关联，在下面的示例中您会怎么做？
用户
命令
订单与产品和用户都有关系，但您不会将所有 4 个实体的功能都放在同一个存储库中。当您与用户实体打交道并收集订单信息时，您会做什么？您可能需要有关产品的额外信息，并且 ORM 通常会提供延迟加载的能力。但是，如果您的产品实体与用户实体位于单独的存储库中，那么这肯定会导致存储库之间发生冲突吗？
在 Eric Evan 的领域驱动设计 ( http://domaindrivendesign.org/index.htm ) 中，您应该首先考虑您的聚合。然后，您围绕这些构建存储库。
有许多技术可用于处理彼此相关的聚合。我最常使用的是只允许聚合通过只读接口相互关联。Aggregates 背后的关键思想之一是，如果不通过根，就无法更改底层对象的状态。因此，如果产品和用户是模型中的根聚合，那么如果我通过用户->订单->产品得到它，我将无法更新产品。我必须从产品存储库中获取产品才能对其进行编辑。（从 UI 的角度来看，您可以使它看起来像用户->订单->产品，但是当您点击产品编辑屏幕时，您会从产品存储库中获取实体）。
当您通过从用户->订单->产品查看产品（在代码中）时，您应该查看的产品界面没有任何方法可以更改产品的底层状态（只有没有集合等。 )
根据您使用它们的方式来组织您的聚合和存储库。我可以看到 User 和 Prodcut 是他们自己的聚合并拥有自己的存储库。根据您的描述，我不确定 Order 是否应该属于 User 或者也应该是独立的。
当聚合相关时，无论哪种方式都使用只读接口。当您必须从一个聚合跨越到另一个聚合时，请从其自己的存储库中获取它。
如果您的存储库正在缓存，那么当您（通过用户）加载订单时，只需从数据库中加载产品 ID。然后使用产品 ID 从产品存储库加载详细信息。您可以通过在加载订单时在产品上加载任何其他不变量来进行一些优化。
存储库是指类？
根据对象（存储库）的使用，您可以创建一个将数据库上的数据组合在一起的视图，并使用您的 ORM 创建一个类（存储库）来表示该视图。当您想要显示每个表中只有几列的重量较轻的对象时，这种设计会起作用。
如果 SQL Server 是您的数据库，并且存储库是指数据库，那么我只需将信息粘贴在任何有意义的数据库中，并在依赖数据库中查看通过三点符号从另一个数据库中选择的视图。
我仍然对“存储库”的含义感到困惑。我会将您谈到的所有内容都制作为单独的类（因此是单独的文件），并且它们都将驻留在同一个项目中。