Have you ever looked for the type of oil a car requires or calculated the expected miles per gallon of gas? There is a specific oil needed based on the type of car we have, but gas mileage can vary wildly based on the options your car has, the type of gas used, and so on. This is a part of the reason that the oil requirements are printed in our owner's manual (because it is specific to our car) but the miles per gallon calculation is not.

This kind of separation requires us to separate the information that we want from how we get it. The data we are returning may come from different sources, but how we get it can be abstracted. If we own both a truck and a sports car, we would do the same thing to find the type of oil (pull out the owner's manual and find the page with the oil requirements). This level of separation which we see in the everyday world is the same separation that we should strive for in our applications.

When we write software, there is a similar separation in queries and projections. Some queries are used by all of our entities, but in other cases, the query is so specific that it is tightly coupled to the type it queries on. We are confronted by a decision point here. We could put all of our queries in one place, but that would violate our single responsibility principle and separation of concern. The other option is to define query libraries that hold the queries in specific areas grouped by their level of abstraction.