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?

score 4 · Accepted Answer · answered Feb 19 '15 at 06:09

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.

And if I had a `Find` method in my `RepositoryBase` that expects a Expression as parameter and from the actual `ProductService` class within the Domain I would call the `Find` method passing on the lambda. Is that a good approach? I mean, the logic is not inside the `Product` (the entity) class itself, but inside the `ProductService` which is part of the Domain too. — Ariel Moraes, Feb 19 '15 at 21:38
Yes, that is fine. Depending on how vast the system is going to be, you could still consider the approach of Specification and encapsulate those search expressions in your specifications. If you read up on ISpecification you will notice that it is the ability to perform And / Or etc. and effectively chaining them that makes them so powerful. Expression is already quite powerful, and using them as your underlying querying mechanism for Specification pattern is great. (look into LinqKit by joseph albahari. he blogged about how he wrote it, and that provides some really valuable insight.) — Eugène, Feb 20 '15 at 03:52

score 2 · Answer 2 · answered Feb 19 '15 at 05:45

Based on your link, the Products class is the repository, just named without the "repository" suffix.

You are correct that the filtering should be in the database, you just don't see it because you are in the domain.

The first and second approach are the same. The difference is that the first is more align with DDD because of the proper usage of the ubiquitous language

// First example
// Take note, the products IS the repository
IList<Product> productsByUser = products.BoughtByUser(User user);

// Second example
IList<Product> productsByUser = productsRepository.Find(p => p.User.Id == userId);

If you dive in the data access layer, you can see the filtering that you are talking about.

public IList<Product> BoughByUser(User user)
{
    IList<Product> products = this.dbContext.Products.Find(p => p.User.Id == user.ID);

    return products;
}

Yes agreed. I would do this: if i need a verification on top of the properties of a single object I would place this method inside the entity. Otherwise if I need to query for multiple objects based on a, i.e query string, I would go with the repository approach. What do you think about that? — Ariel Moraes, Feb 19 '15 at 21:46

score 1 · Answer 3 · answered Feb 19 '15 at 10:29

This is not the direct answer of your question (Yorro's answer is right) but maybe it helps you to better understand DDD. This is a "wrong way, turn back" answer.

Your views doesn't need domain rules; doesn't need aggregates with 1 million of childs or 1 million of entities. So, you don't need to "bypass" the product repository because you should have "View Services" with "View Repositories" wich allows you to query (and paging, etc) denormalize data from persistence for your views.

You should apply domain rules using aggregates/entities when update/insert/delete is needed.

Once the user select one or several products from the 1 million list and push, for example, delete button you should use product repository to retrieve the aggregate/entity of selected products, apply delete rules and invariants and save in persistence.

DDD and Entity Framework, Filters

3 Answers3