Identify and Define the Scope of Microservices
- Take the help of Domain Driven Design to identify the bounded contexts. For this, use traditional approach or event storming.
- In some applications, microservices can be designed for each identified bounded context but not in all enterprise applications. There is no fix pattern available which can guide in identifying the numbers of microservices required for a bounded context. So, there can be one or multiple microservices with in a bounded context.
- If possible, multiple aggregates in a bounded context can be decomposed into multiple microservices when those are not going to hit the performance or not going to result in chatty microservices. Sometimes, it is hard to identify the chattiness at an initial level which is fine as microservices can be composed to increase the performance and in reducing the chattiness.
- Also, identify those microservices which are required to provide technical functionalities or support which are common across bounded contexts, especially for cross cutting concerns and for supporting other technical functionalities like sending email, SMS, reading environment variables, etc. however it depends on the nature of the application and business requirements.
- Two microservices cannot share the same domain model. Domain model should be unique in each microservice.
- Scope of all the identified microservices cannot go beyond the boundary of a bounded context.
- Another important point is with the use of ubiquitous language which should reflect in the name of the identified microservices. Microservice name should be self-explanatory and aligned with the defined ubiquitous language.