-1

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.

7
  • If microservices are supposed to do one small specific thing, don’t you think making them generic (reusable) is an anti-pattern?
    – Rik D
    Commented Jan 24, 2022 at 12:00
  • Maybe you could explain what you mean with reusable.
    – Rik D
    Commented Jan 24, 2022 at 12:01
  • What i mean with that is that i have alot of similar applications and the goal is to somehow analyze the codebase of these applications and then create microservices that can be used reused in alot of them and also when developing new ones. I'm not sure if microservice is the right term for this use case. Maybe it's more of a Service-oriented architecture.
    – marius
    Commented Jan 24, 2022 at 12:07
  • Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking.
    – Community Bot
    Commented Jan 24, 2022 at 12:40
  • 2
    Micro-services are mostly aimed at independent scalability of parts of an application. Is that also what your focus is on, or is your focus more on code reuse? Code reuse can be more easily achieved by putting the code that is shared between several applications into a common library.
    – Bart van Ingen Schenau
    Commented Jan 24, 2022 at 12:50

1 Answer 1

Reset to default
0

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.

3
  • Thank you for your answer. I have updated my question to further clarify my question. Which path would you take if the domain is not very complex (only technical complex) and you dont have alot of knowledge about the implementation. Is it a viable option to group the functionalities by affiliation in my case f.e. Camera-Service, PLC-Service, Imageprocessing-Service etc. And how can i scientifically underpin this approach.
    – marius
    Commented Jan 28, 2022 at 10:35
  • @marius the problem with "flexibility" is that is difficult to anticipate what the new requirement may be. So the best solution is usually to ensure the application is well structured and documented (i.e. high cohesion & lose coupling), since this will make any change easier. This is true regardless if you are using microservices, monolith, or any other architecture. There is unfortunately no algorithmic way to do this.
    – JonasH
    Commented Jan 28, 2022 at 13:20
  • Dividing application into modules for cameras, PLC, etc might be appropriate. It might also be that things like a position check has very little to do with the thermal check. So you need to have some knowledge of the domain, and this is the point of DDD.
    – JonasH
    Commented Jan 28, 2022 at 13:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.