title: How do Repositories fit with CQRS?
body: <p>According to Fowler (<a href="http://martinfowler.com/eaaCatalog/repository.html">here</a>), a repository "mediates between the domain and data mapping layers, acting like an in-memory domain object collection."  So, for example, in my Courier Service application, when a new run is submitted, my application service creates a new Run aggregate root object, populates it with values from the request then adds it to the RunRepository before calling the Unit of Work to save the changes to the database.  When a user wants to view the list of current runs, I query the same repository and return a denormalized DTO representing the information.</p>
  
  <p>However, when looking at CQRS, the query would not hit the same repository.  Instead, it would perhaps go directly against the data store and always be denormalized.  And my command side would evolve to a NewRunCommand and Handler that would create and populate a NewRun domain object then persist the information to the data store.</p>
  
  <p><em>So the first question is where do repositories fit into the CQRS model if we aren't maintaining an in-memory collection (cache, if you will) of domain objects?</em></p>
  
  <p>Consider the case where the information submitted to my application service contains nothing but a series of ID values that the service must resolve in order to build the domain object.  For example, the request contains the ID # of the courier assigned to the run.  The service must lookup the actual Courier object based on the ID value and assign the object to the NewRun using the AssignCourier method (which validates the courier and performs other business logic).</p>
  
  <p><em>The other question is, given the separation for queries and potential absence of repositories, how does the application service perform the lookup to find the Courier domain object?</em></p>
  
  <p><strong>UPDATE</strong></p>
  
  <p>Based on some additional reading and thought after Dennis' comment, I'll rephrase my questions.</p>
  
  <p>It appears to me that CQRS encourages repositories that are merely facades over the data access and data storage mechanisms.  They give the "appearance" of a collection (like Fowler describes) but are not managing the entities in-memory (as Dennis pointed out).  This means that every operation on the repository is pass-through, yes?</p>
  
  <p><em>How does a Unit of Work fit into this approach?  Typically a UoW is used to commit changes made to a repository (right?) but if the repository isn't maintaining the entities in-memory, then what role does a UoW have?</em></p>
  
  <p><em>With regards to a 'write' operation, would the command handler have a reference to the same repository, a different repository or perhaps a UoW instead of a repository?</em></p>