title: Microservice granularity: Per domain model or not?
body: <p>When building a microservice oriented application, i wonder what could be the appropriate microservice granularity.</p>
  
  <p>Let's image an application consisting of:</p>
  
  <ul>
  <li><p>A set of various resources types where each resource map a given business model. <em>(ex: In a todo app resources could be User, TodoList and TodoItem...)</em></p></li>
  <li><p>Each of those resources are saved within a NoSQL database that could be replicated.</p></li>
  <li><p>Each of those resources are exposed through a REST Api</p></li>
  <li><p>The application manage an internal chat room.</p></li>
  <li><p>An Api gateway for gathering chat room and REST api interaction.</p></li>
  <li><p>The application front end: an SPA application connected to the API Gateway</p></li>
  </ul>
  
  <hr>
  
  <p>The first (and naive) approach when thinking about how microservices could match the need of this application would be:</p>
  
  <ol>
  <li><strong>One monolith service for managing EVERY resources and business logic</strong>:
  <em>By managing i mean providing the REST API for all of those resources and handling the persistance of those resources within the database.</em></li>
  <li>One service for each Database replica.</li>
  <li>One service providing the internal chat room using websocket or whatever.</li>
  <li>One service for Authentification.</li>
  <li>One service for the api gateway.</li>
  <li>One service serving the static assets for the SPA front end.</li>
  </ol>
  
  <hr>
  
  <p><strong>An other approach could be to split service 1 into as many service as business models exist in the system.</strong> (let's call those services <em>resource services</em>)</p>
  
  <p>I wonder what are the benefit of this second approach.
  In fact i see a lot of downsides with this approach:</p>
  
  <ul>
  <li>Need to setup an inter service communication process.</li>
  <li>When requesting a service representing resource X that have a relation with resource Y, a lot more work are needed (i.e: interservice request)</li>
  <li>More devops work.</li>
  <li>More difficulty to share common code between <em>resource services</em>.</li>
  <li>Where to put business logic ?</li>
  </ul>
  
  <hr>
  
  <p>When starting a fresh project this second approach seams to me a bit of an over engineered work.</p>
  
  <p>I feel like starting with the first approach and THEN split the monolith resource service into several specific services depending on the observed needs will minimize the complexity and risks.</p>
  
  <p>What's your opinions regarding that ?
  Is there any best practices ?</p>
  
  <p>Thanks a lot !</p>