CODEWITHSUNDEEP
performanceentity-frameworkdomain-driven-design
Ariel Moraes
Ariel Moraes

Reputation: 648

DDD and Entity Framework, Filters

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?

Upvotes: 4

Views: 1574

Answers (3)

jlvaquero
jlvaquero

Reputation: 8785

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.

Upvotes: 1

Eug&#232;ne
Eug&#232;ne

Reputation: 676

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.

Upvotes: 4

Arvin Yorro
Arvin Yorro

Reputation: 12157

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;
}

Upvotes: 2

Related Questions