DDD and Entity Framework, Filters

Question

So I am struggling with the approach DDD has to follow when we talk about filtering and queries. From this SO question Is it okay to bypass the repository pattern for complex queries? I can see the filtering by User should be done after getting all the Products. The piece of code from the accepted answer is:

Products products = /* get Products repository implementation */;
IList<Product> res = products.BoughtByUser(User user);

But wait, and if the database has 1 million Products? Isn't the best approach to do this filter directly in the database like so:

productsRepository.Find(p => p.User.Id == userId);

But from my actual knowledge of DDD this would be wrong, because this logic should be inside the Product itself.

Therefore, how to handle this scenario?

Answer 1

I agree with Yorro's answer. According to the comment, products is indeed a repository. The question around performance of the underlying datastructure vs keeping the domain knowledge in the application could be explored further though. Databases are great at filtering and querying data, they are optimized to do so, and for us to ignore that simply to "keep our knowledge in the domain" is naive.

Your example shows Repository Specialization, which is fine albeit verbose. The logic of that search is encapsulated by that call, and as long as the interface for calling that method is in the domain, and the implementation in the data-layer, everything is fine. Indeed the call could be to a stored-procedure that performs a very complex operation. (In this case, yes some of your logic has escaped the domain, but you make it as a conscious decision, and should you introduce another data technology, you would have to implement that functionality again.)

There is another option... We can encapsulate the logic of the search in a Specification (http://en.wikipedia.org/wiki/Specification_pattern) and pass the specification from our domain logic code to our Repository who would interpret the specification and do the query. That makes our domain oblivious of how the underlying data structure works, but it puts it in control of what the search criteria is.

I usually find myself implementing a blend of Repository Specialization, and having a base repository that accepts an ISpecification for more lightweight queries.