Identifying bounded contexts

One of the most challenging tasks in designing a microservices-based architecture is to get the bounded context right for each microservice. It is an iterative process that requires a thorough understanding of business capabilities and business domain. Business capabilities must not be confused with business functions or processes. Business capabilities target the what part of a business and have an outcome, whereas a business process targets the how part. For example, alerting is a business capability, whereas sending an email is a business process. A business capability may incorporate one or more business processes.

Bounded contexts must target business capabilities and not business processes. To identify the right bounded contexts, it is recommended to start with a monolithic application with a single unified model and analyze it iteratively over time for high coupling areas. Often, high coupling areas are good target points to split the domain model into sub-domain models that can interact using fixed contracts and help reduce tight coupling. However, such sub-domains must be further validated against business capabilities to make sure that they target only one business capability.

Microservices must be organized around a business capability within a bounded context and own their presentation, business domain, and persistence layer. They must take responsibility for the end-to-end development stack including functions, data model, persistence, user interface, and the contract to access the service using APIs, often over HTTP(S).