Context boundaries

A module is just a way of defining a context boundary. If you want to migrate your existing monolithic application to a microservice-based application, you first have to identify a hidden context within your current application. This means we have to define the context and draw explicit context boundaries. This helps us design a robust microservice-based application.

For example, a typical online book shopping portal can have an order and shipping module using the same entity product. The following diagram shows the context boundaries of this application:

As you can see in the preceding diagram, the distributed application is based on different bounded contexts. The preceding design is a modular application design, where every module runs an independent process as a service. This is a decentralized approach to application design.

Once you have defined context boundaries, you can then easily decompose your existing monolithic application into a microservice-based application, where each bounded context has one microservice. In the example shown in the previous diagram, we have divided our monolithic application into four bounded contexts, which means that there are four microservices: Order Service, Book Service, Shipping Service, and Customer Service.

We now have a separate product entity in the Order Service and the Shipping Service, which each have their respective repositories. This concept can be extended by defining explicit context boundaries for the Stock and Inventory modules and creating an independent microservice for each.

Let's have a look at two different decomposition approaches. A monolithic application can be decomposed based on either its business capability or its domain.