5

I've read in various places that one important requirement in DDD is to have a bounded contract for the Repository:

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

And not provide a generic query interface:

findBySpecification(Specification spec)

I do understand why this is important: to be able to mock the Repository for tests, or change the underlying persistence framework.

While this rule is not that hard to enforce throughout the application, I can't figure out how to enforce it when it comes to provide the user with an "advanced search" form.

Let's say I have a form which allows to search blog posts by keyword, by date, by author, etc.

These criteria being freely combinable, I obviously can't provide a method for each use case:

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

Am I missing something or is it one of the exceptions to the rule?

BenMorel
  • 34,448
  • 50
  • 182
  • 322

3 Answers3

2

There is nothing wrong with passing Specification as a parameter to a repository. This is actually a very good way of tackling method explosion on the repository interface. Take a look at this answer. 'Filter' maybe more appropriate name than 'Specification' for the 'advanced search' scenario. I think this code will not violate any DDD guidelines:

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

blogs.FindByFilter(filter);

Note that the code that creates the filter can live outside of domain. Because it will not violate any domain rules. What if there is a rule like "Blogs posted by Anonymous author should be approved by moderator"? Although it can be expressed with Filter, doing so will externalize piece of business logic. It will make more sense to put this rule into domain code and have a dedicated repository method like:

blogs.RequireModeratorAttention();
Community
  • 1
  • 1
Dmitry
  • 17,078
  • 2
  • 44
  • 70
1

The Repository pattern has two main benefits:

  1. It decouples your application from your persistence layer and idiom.
  2. It centralizes and constrains data access to well-defined and understood domain segments (the data access methods in the repository have a well defined result and are reasonably testable).

If you use an instance of the specification pattern provided by your persistence layer (e.g. NHibernate Criteria), you negate benefit one. Using the specification pattern at all (even one you roll yourself) waters down the benefit of number two.

That being said, in some situations such as search interfaces, specification is necessary - just make sure and roll your own.

BenMorel
  • 34,448
  • 50
  • 182
  • 322
J Cracknell
  • 3,498
  • 1
  • 19
  • 13
1

While this rule is not that hard to enforce throughout the application, I can't figure out how to enforce it when it comes to provide the user with an "advanced search" form.

Actually, you don't have to pay the cost of all these abstractions if all you need is a search form. Repository (in context of DDD at least) was designed to abstract the nuances of persistence framework from the business logic (application layer).

If you have a command that changes user's address, it's better to have a repository with FindUserById method than to have some magic Hibernate code in the app layer. There are two reasons for this

  • You may want to test the application layer with persistence layer (repositories) mocked
  • Application layer is something you care about because it's business logic

You don't need all of these to just get some data for the UI. I would suggest using specialized 'Finder' classes that may even live in the UI layer. They can operate either on abstract 'specification' or (even better) on bare Hibernate (or your favourite ORM). I've written a blog post about this approach here.

Szymon Pobiega
  • 3,358
  • 17
  • 18