我目前面临着关于分层和存储库的一些疑问 .
我在考虑在持久性模块中创建我的存储库 . 这些存储库将从域层模块中创建的存储库继承（或实现/扩展），保持“持久性不可知” .
问题在于，从我所能看到的，关于其存储库的域层的必要性是非常谦虚的 . 一般来说，他们倾向于CRUDish .
它通常在应用程序层级，在解决特定的业务用例时，查询往往更复杂和更人为（因此，存储库的爆炸方法的数量） .
所以这提出了如何处理这个问题：
1）我应该简单地保留域存储库接口，然后在存储库实现中添加额外的方法（这样，知道存储库实现的应用程序层可以使用它们）吗？ 2）我应该在域级别存储库实现中添加这些方法吗？我想不是 . 3）我是否应该创建另一组存储库才能在应用程序层级使用？这可能意味着转向更多CQRSesque应用程序 .
谢谢
3 回答
鉴于存储库不是关于查询而是关于使用完整聚合的大部分时间，您可能会详细说明为什么您可能需要创建仅在您的应用程序/集成层中使用的单独的存储库集？
也许您需要具有针对数据检索进行优化的特定于读取的实现：
好吧，你可能想要实现有意义的读取特定位 . 我通常将数据访问权限分配给命名空间，有时甚至是在单独的程序集中 . 然后，我使用
I{Aggregate}Query实现，以尽可能简单的类型返回相关的数据位 . 然而，甚至可以映射到甚至具有关系的更复杂的读取模型，但它仍然只是读取模型并且不关心任何命令处理 . 为此，域甚至从未意识到这些类 .我不会去扩展存储库 .
我认为您应该对您的业务/需求的现实做出反应 .
也就是说，如果您的用例显然不是“持久性不可知”，那么就不要坚持这个特定的限制 . 并非一切都可以简化为CRUD . 事实上，我认为大多数值得实现的东西都不能简化为CRUD持久性 . 大多数数据库系统都是关系型的，或者现在有很多特性，而忽略它们似乎很古怪 . 使用它们 .
如果您不想将SQL与其他代码混合使用，那么仍然有许多其他“模式”可以让您这样做，而无需您抽象访问您实际上不需要抽象的内容 .
另一方面，您构建了对特定持久性系统的依赖关系 . 那是问题吗？大部分时间它实际上不是，但你必须自己决定 .
总而言之，我会选择选项4：模拟问题 . 如果我需要一个复杂的SQL来构建一个用例，并且我不需要数据库独立性（我很少这样做），那么只需将它写在使用它的地方，故事结束 .
您可以使用其他工具（如稍后重构）来纠正设计问题 .
Application层不必了解Infrastructure .
通常情况下，只需在Domain中声明的Repository接口提供就可以了 . 具体实现在运行时注入 .
在Domain层中声明存储库接口不仅仅是在域服务中使用它们，还在其他地方使用它们 .
你可以这样做，但你会失去一些可重用性 .
它也与CQRS无关 - CQRS是查询和命令之间整个应用程序的垂直划分，不给予水平层不同的获取数据的方式 .