title: CQRS + ES - Where to query Data needed for business logic?
body: <p>I'm using CQRS + ES and I have a modeling problem that can't find a solution for. <br/>
  You can skip the below and answer the generic question in the title: <strong>Where would you query data needed for business logic?</strong><br/>
  Sorry of it turned out to be a complex question, my mind is twisted at the moment!!!<br/>
  <strong>Here's the problem:</strong><br/>
  I have users that are members of teams. It's a many to many relationship. Each user has an availability status per team.<br/>
  Teams receive tickets, each with a certain load factor, that should be assigned to one of the team's members depending on their availability and total load. <br/>
  <strong>First Issue,</strong> I need to query the list of users that are available in a team and select the one with the least load since he's the eligible for assignment.<em>(to note that this is one of the cases, it might be a different query to run)</em><br/>
  <strong>Second Issue,</strong> load factor of a ticket might change so i have to take that into consideration when calculating the total load per user . Noting that although ticket can belong to 1 team, the assignment should be based on the user total load and not his load per that team.<br/>
  Currently a TicketReceivedEvent is received by this bounded context and i should trigger a workflow to assign that ticket to a user.<br/>
  <strong>Possible Solutions:</strong><br/></p>
  
  <ol>
  <li>The easiest way would be to queue events and sequentially send a command AssignTicketToUser and have a service query the read model for the user id, get the user and user.assignTicket(Ticket). Once TicketAssignedEvent is received, send the next assignment command. But it seems to be a red flag to query the read model from within the command handler! and a hassle to queue all these tickets!</li>
  <li>Have a process manager per user with his availability/team and tickets assigned to that user. In that case we replace the query to the read side by a "process manager lookup" query and the command handler would call Ticket.AssignTo(User). The con is that i think too much business logic leaked outside the domain model specifically that we're pulling all the info/model from the User aggregate to make it available for querying</li>
  </ol>
  
  <p>I'm inclined to go with the first solution, it seems easier to maintain, modify/extend and locate in code but maybe there's something i'm missing.</p>