Breaking Up Code?
In a simple approach the code of the legacy application can be split into several microservices. This can be problematic when the legacy application does not have a good domain architecture, which is often the case. The code can be easily split into microservices when the microservices are geared to the existing modules of the l egacy application. However, when those have a bad domain-based split, this bad division will be passed on to the microservice-based architecture. Additionally, the consequences of a bad domain-based design are even more profound in a microservice-based architecture: The design also influences the communication between teams. Besides, the initial design is hard to change later on in a microservice-based architecture.
Supplementing Legacy Applications
However, it is also possible to get by without a division of the legacy application. An essential advantage of microservices is that the modules are distributed systems. Because of that, the module boundaries are at the same time the boundaries of processes that communicate via the network. This has advantages for the distribution of a legacy application: It is not at all necessary to know the internal structures of the legacy application or, based on that, to perform a split into microservices. Instead microservices can supplement or modify the legacy application at the interface. For this it is very helpful when the system to be replaced is already built in an SOA (section 6.2). If there are individual services, they can be supplemented by microservices.