title: Why shared libraries between microservices are bad?
body: <p>Sam Newman states in his book <em>Building Microservices</em></p>
  
  <blockquote>
    <p>The evils of too much coupling between services are far worse than the problems caused by code duplication</p>
  </blockquote>
  
  <p>I just don't understand how the shared code between the services is evil. Does the author mean the <em>service boundaries themselves</em> are poorly designed if a need for a shared library emerges, or does he really mean I should duplicate the code in the case of common business logic dependency? I don't see what that solves.</p>
  
  <p>Let's say I have a shared library of entities common to two services. The common domain objects for two services may smell, but another service is the GUI to tweak the state of those entities, another is an interface for other services to poll the state for their purpose. Same domain, different function.</p>
  
  <p>Now, if the shared knowledge changes, I would have to rebuild and deploy both services regardless of the common code being an external dependency or duplicated across the services. Generally, same concerns all the cases for two services depending of the same article of the business logic. In this case, I see only harm of duplication of the code, reducing the cohesion of the system.</p>
  
  <p>Of course, <em>diverging</em> from the shared knowledge may cause headaches in the case of shared library, but even this could be solved with inheritance, composition and clever use of abstractions.</p>
  
  <p>So, what does Sam mean by saying code duplication is better than too much coupling via shared libraries? </p>