To migrate to microservice, we are going to use Domain Driven Design, modified to DDD Incremental Design. Basically, this method means SAs joining Domain experts in defining Bounded Context, or in simpler words, taking out a functional element of the old system and creating a logical border around it.
Definitions about domains and bounded context may be confusing, but generally they can be understood as:
- From the old task analysis system, take out one particular business function (like order, payment…)
- Create a border around that business logic and data, so that other modules have to go through interface while accessing.
Big Ball of Mud
Legacy systems in monolithic structure are like a gigantic ball of mud, anti-pattern. Here, business logics are coded in sequences, like A function will call for B function, B function will call for C functions via various level function calls. There is also no clear boundary between data and function, and this is a challenge in migrating to microservice.
In order to define Bounded Contexts in the system, we need to have Domain Experts – people who understand deeply the system’s businesses, as well as module correspondence process and dependency.
A Domain Expert have to be able to describe how many modules are there in the system and the relationship between those modules. Below is a simple example:
In modules with plenty connections with others (like Order), migrating to microservices will be much tougher compare independent modules (like Product).
Bounded Context will be derived from the aforementioned modules.
Building models and interfaces
After defining Bounded Contexts, the next step is to create an interface. Most of the time, interfaces will be designed into Rest API, or Queue and event streams.
Exterior modules will be regulated to approach bounded contexts via interfaces. Therefore, when deriving microservices from modules, the remaining mono system will be altered to be able to called via interfaces instead of via function calls. The process will be done gradually in steps until the entire migration system is finished. Here, the old and new systems will co-exist until full migration. Such model is called the Strangler pattern model, with microservices (stranglers) surrounding the host (monolithic), slowly strangling it to grow, until the host dies.
Therefore, the 2nd challenge is to enable co-existence of the mono and microservice systems without affection the business, or letting users know of the changes – quite the difficult task, seeing that the migration process may last for years.
For example: Order Service is derived from an independent service from the original monolithic. After defining the bounded context, Order from monolithic will become Order microservice, while its code is calling the legacy order via a modified function call, able to switch to order API.
The final step is to break down DB monolithic into a separate db owned by service.
Here, the challenge is to migrate data from mono db to microservice db, seeing that data is possession of the organization, not the application, with millions of records and interconnecting relationships.
Do Trong Nguyen – FPT Software
Source: giaosucan’s blog