Microservice decomposition into reusable microservice from a set of monolithic applications

Question

So for my Masterthesis i have to decompose a set of monolithic industrial applications into microservices. The aim is to decompose the monoliths in to services that are as much reusable as possible. I have not found any research that tackles this Problem. Can someone guide me in the right direction on how to solve this problem ? Or maybe some possible ideas / related work ?

EDIT: to further clarify my question: The goal of the thesis is to improve the maintainability and flexibility of the applications. What i mean with flexibility is the ability to better react to changing requirements of the environment the software is running in. F.e. to have the possibility to run the application in the cloud or use a new technology in one of the services. Scalability is not an issue right now. Currently the applications are heavily bound to a proprietary image processing library. I will migrate 2 of the ~100 applications into a Service-oriented Architecture and i would like to know how i need to decompose the application so most of the services are also applicable to the other remaining applications. There are also alot of duplicate codes between these applications.

Regarding to DDD i'm not sure if its applicable to my application because the context is pretty "simple" (automatic optical inspection of PCB's). Also the application has from my understanding only one business capability: inspect PCBS. Maybe someone can tell me when DDD is applicable and when not. I don't have mutch understanding of it.

Thank you.

Answer 1

Microservices is one particular form of splitting a larger application into smaller modules. It is not the only way to modularize an application, but it has fairly strict rules about limiting inter-dependencies between modules. Since inter dependencies quickly becomes cumbersome to manage, developers are encouraged to limit them, and therefore also to keep modules as separate as possible. In my opinion the benefits of microservices is greatest when you have multiple teams, since it allows the teams to develop and release functionality independent of the other teams.

The way to split any large system into modules is to find some parts that have high cohesion and loose coupling. i.e. parts that are fairly self contained. But this is usually easier said than done, and often require a fairly large degree of experience in a particular domain to know what particular parts fulfill this requirement.

Another useful methodology might be domain driven design that somewhat simplified says that the architecture should be similar to your business domains.

If the main problem is that the code is poorly structured, the recommended techniques is refactoring. This is a super common problem and there are lots of articles and books written on how to effectively work with legacy code.

Also note that the goal of lose coupling may run counter to the goal of code reuse. In some cases it might make sense to duplicate or re-implement code in different modules, since reusing the same piece of code would introduce a dependency between the modules that can make future changes more difficult.