II. Proper migration
After the initial steps concerning analysis of the existing system and the pilot migration, we can move on to the migration of subsequent elements of the system. The diagram below presents the migration workflow. Such activities (marked on the diagram in the Iteration block) repeat periodically until all the planned system parts are migrated.
1) Division of the system into coherent and logical parts within separate sub-domains.
This is a key stage, often decisive for the success or failure of the system migration to the microservice architecture. Through a good division into independent areas of business logic, the so-called bounded contexts, we strive to minimize the complexity of communication interfaces between system components. The context gives meanings in the conceptual model, e. g. a product in the context of sales has a name, price or availability. However, the same product in the context of a complaint has completely different key attributes such as serial number, version, a person ordering the repair, etc. Domain Driven Design techniques can also prove useful in this division.
2) Planning and implementation of migration in subsequent iterations
As migration is by nature an iterative process, our choice of project method should be consistent with these requirements. An agile methodology such as Scrum will allow us to deliver regular migration deliverables, i.e. subsequent microservices. Within an iteration, we plan the scope of the Sprint by defining the elements that will be taken from the Product Backlog. Such planning obviously requires an analysis of the existing code, database schemes and infrastructure that touch the migrated part of the system in any way. In subsequent steps, we refactor the existing solution in order to make a given system element independent, e. g. as a separate module of a monolithic system. This also applies to the database scheme used by the migrated part of the system. If these steps are completed successfully, the migration to the external microservice itself will be significantly facilitated. After the migration have been completed, acceptance tests of the separated system functions and integration tests are of course necessary due to the introduction of a new microservice as an element cooperating with the existing monolith. We also should not forget about the removal of the existing code from the monolith, whose role was taken over by the new microservice. The final step of the migration will be the transit of the legacy system on the production environment and implementing the new system.