Micro services - Boundaries

When designing Micro services, one of the question that one will face is the size of micro service? how big? how small?

From a purely technical perspective, the smaller the microservice the easier it can be developed quicker (Agile), iterated on quicker (Lean), and deployed more frequently (Continuous Delivery). But on the modelling side, it is important to avoid creating services that are “too small.”

Domain driven design: 
Any sophisticated business domain consists of one or more bounded contexts, each responsible for one part of the domain. A bounded context contains models describing the domain and is also a boundary for the meaning of these models.
A context map shows all bounded contexts and their relation to each other and also describes the contract between them.
The core domain is the part of the domain most closely associated with the strategy of the company.  A support domain is a part of the domain that indirectly supports the core domain without actually belonging to it.  A generic domain is one that is universally well-known, without any need for specialization in the core domain.

Our technical need for the size of a service can sometimes be different (smaller) from what DDD modeling can facilitate. Bounded context analysis is an “excellent start,” but not the sole prescription for how to size microservices.

Options for boundaries of MicroServices
  • Bounded Context – smallest business process or function  
  • Business Capability – Exchange Rates
  • CRUD – User
  • Service - Login
If starting from scratch, then bounded context is the best place.