Decomposing a System into Microservices

Here are some helpful guidelines to be followed when creating Microservices.

Please refer to Sam Newman’s book on Microservices for a detailed discussion on this topic.

1. Model services as a business service.
   Very often when moving to microservices, we look at current implementation and migrate its components to microservices. Instead, create a service from “outside in” perspective. Think from consumers standpoint first. Ask consumers how they want to use your service and design your service contract that way. Business Team can serve as good choice for helping identify business domain and services.
   Business service should hide implementation detail. Business services do not change often.
2. There should be cohesion of business functionality. Do not over-fragment. “code that changes together, stays together”. Cost of change should be low and impact less number of services. You should not have to update too many services to roll out a feature.
3. Microservice should not share a database. Otherwise, they are not independently deployable and there wont be a clear contract. A microservice should own its data, and provide access to its data either by API or by Event-ing. What we mean by “owning” data is that the microservice should have all the controls on that data. It should have business logic to be able to create, update, delete the data. Logic to manipulate the data should not be spread across multiple services.
4. UI is a poor helper for defining what belongs in a service. Just because 5 attributes are displayed in a page together, the data for that need not *belong* to one service. Business logic that operates on data together should decide which service owns the data and whether that data resides together.
5. Microservices are not the goal. Migrating to microservices architecture should help you achieve one or more of the capabilities below that you currently can’t achieve with current architecture.

• Team autonomy
• Reduce time to market by being able to update and deploy independently
• Scale services independently
• Robustness since a service going down won’t bring the whole system down
• Embrace new technology since the different services don’t have to be written using same tech stack.