title: DDD, CQRS/ES & MicroServices Should Decisions be taken on Microservice's views or aggregates?
body: <p>So I'll explain the problem through the use of an example as it makes everything more concrete and hopefully will reduce ambiguity.</p>
  <p>The Architecture is pretty simple</p>
  <p><strong>1 MicroService &lt;=&gt; 1 Aggregate &lt;=&gt; Transactional Boundry</strong></p>
  <p>Each microservice will be using CQRS/ES design pattern which implies</p>
  <ul>
  <li>Each microservice will have its own Aggregate mapping the domain of a real-world problem</li>
  <li>The state of the aggregate will be rebuilt from an event store</li>
  <li>Each event will signify a state change within the aggregate and will be transmitted to any service interested in the change via a message broker</li>
  <li>Each microservice will be transactional within its own domain</li>
  <li>Each microservice will be eventually consistent with other domains</li>
  <li>Each microservice will build there own view models, from events being emitted by other microservices</li>
  </ul>
  <p>So the example lets say we have a banking system</p>
  <ul>
  <li><code>current-account</code> microservice is responsible for mapping the Customer Current Account ... Withdrawal, Deposits</li>
  <li><code>rewards</code> microservice will be responsible for inventory and stock take of any rewards being served by the bank</li>
  <li><code>air-miles</code> microservice will be responsible for monitoring all the transaction coming from the <code>current-account</code> and in doing so award the Customer with rewards, from our reward micro-service</li>
  </ul>
  <p>So the problem is this Should the <code>air-miles</code> microservice take decisions based on its own view model which is being updated from events coming from the <code>current-account</code>, and similarly, on picking which reward it should give out to the Customer?</p>
  <p>Drawbacks of taking decisions on local view models;</p>
  <ul>
  <li>Replicating domain logic on how to maintain these views</li>
  <li>Bugs within the view might propagate the wrong rewards to be given out</li>
  <li>State changes (aka events emitted) on corrupted view models could have consequences in other services which are taking their own decisions on these events</li>
  </ul>
  <p>Advantages of taking a decision on local view models;</p>
  <ul>
  <li><p>The system doesn't need to constantly query the microservice owning the domain</p>
  </li>
  <li><p>The system should be faster and less resource intense</p>
  <p>Or should it use the events coming from the service to trigger queries to the Aggregate owning the Domain, in doing so we accept the fact that view models might get corrupt but the final decision should always be consulted with the aggregate owning the domain?</p>
  </li>
  </ul>
  <p>Please, not that the above problem is simply my understanding of the architecture, and the aim of this post is to get different views on how one might use this architecture effectively in a microservice environment to keep each service decoupled yet avoid cascading corruption scenario without to much chatter between the service.</p>