title: Is it okay to bypass the repository pattern for complex queries?
body: <p>This is my understanding about DDD at the moment:</p>
  
  <ul>
  <li>The strict repository pattern should only implement get(), delete() and create(), and maybe variants of get() where one can search or to retrieve an entire collection</li>
  <li>It is common for each aggregate root to have one repository</li>
  </ul>
  
  <p>(from research, I know those are not universally accept norms)</p>
  
  <p>The question here is how to implement complex queries which involves many aggregate roots. For example, we have two aggregate roots - product and user. If I am doing a page which list what products a user have bought, then I have a query which stretch across both the user aggregate and the product aggregate.</p>
  
  <p>How should this query be implemented? </p>
  
  <ol>
  <li><p>What I am doing now is actually to have a repository for this query and queries with related functionality (some will disagree and say the repository is not a query layer). </p></li>
  <li><p>Use only the repository for product and user, grab all records and do everything in memory (this sounds wrong)</p></li>
  <li><p>Have the query (LINQ or SQL) to be inside the service, not using the repository associated with the aggregates at all.</p></li>
  </ol>
  
  <p>Are there some other ways?</p>