DDD：存储库合约

Question

我在很多地方读到，DDD 中的一个重要要求是为存储库制定有界契约：

findByName(string name)
findByEmail(string email)
etc.

并且不提供通用查询接口：

findBySpecification(Specification spec)

我确实理解为什么这很重要：能够模拟存储库进行测试，或者更改底层持久性框架。

虽然在整个应用程序中执行此规则并不难，但在为用户提供“高级搜索”表单时，我不知道如何执行它。

假设我有一个表单，允许按关键字、按日期、按作者等搜索博客文章。

这些条件可以自由组合，显然，我无法为每个用例提供一种方法：

findByKeyword(string keyword)
findByDateRange(Date from, Date to)
findByKeywordAndDateRange(string keyword, Date from, Date to)
findByDateRangeAndAuthor(Date from, Date to, User author)
etc.

我是否遗漏了某些内容，或者它是规则的例外情况之一？

Answer 1

将 规范 作为参数传递给存储库没有任何问题。这实际上是解决存储库接口上方法爆炸的一个非常好的方法。看看这个答案。对于“高级搜索”场景，“过滤器”可能比“规范”更合适。我认为这段代码不会违反任何 DDD 准则：

Filter filter = new FilterBuilder()
    .WithinDateRange(dateRange)
    .IncludingKeywords("politics", "news")
    .ByAuthor("John Smith")
    .Build();

blogs.FindByFilter(filter);

请注意，创建过滤器的代码可以位于域之外。因为它不会违反任何域规则。如果存在诸如“匿名作者发布的博客应得到版主批准”之类的规则怎么办？虽然可以用Filter来表达，但这样做会将业务逻辑具体化。将此规则放入域代码中并拥有专用的存储库方法会更有意义，例如：

blogs.RequireModeratorAttention();

Answer 2

虽然这条规则在整个国家中执行起来并不难
应用程序，我不知道如何强制执行它
为用户提供“高级搜索”表单。

实际上，如果您只需要一个搜索表单，则无需支付所有这些抽象的成本。存储库（至少在 DDD 的上下文中）旨在从业务逻辑（应用程序层）中抽象出持久性框架的细微差别。

如果您有一个更改用户地址的命令，那么最好有一个带有 FindUserById 方法的存储库，而不是在应用程序层中拥有一些神奇的 Hibernate 代码。有两个原因

• 您可能想用持久层来测试应用程序层
  (repositories)mocked
• 应用层是你关心的
  因为它是业务逻辑

您不需要所有这些来获取 UI 的一些数据。我建议使用专门的“Finder”类，这些类甚至可能位于 UI 层中。它们可以在抽象“规范”上运行，也可以在裸露的 Hibernate（或您最喜欢的 ORM）上运行（甚至更好）。我在此处写了一篇关于此方法的博客文章。

Answer 3

存储库模式有两个主要优点：

1. 它将应用程序与持久层和惯用法分离。
2. 它将数据访问集中并限制在明确定义和理解的域段（存储库中的数据访问方法具有明确定义的结果并且可合理测试）。

如果您使用持久层提供的规范模式的实例（例如 NHibernate Criteria），您就否定了好处之一。完全使用规范模式（即使是您自己推出的规范模式）会削弱第二点的好处。

话虽如此，在某些情况下（例如搜索界面），规范是必要的 - 只需确保并推出您自己的规范即可。