My opinion is that you have your answer already in your question: Find your bounded contexts. I also had to refactor a software monolith and it was very helpful to focus on the data model first. With this data model, you know the entities in your system. In a second step, you should consider the functionality of your monolith. Do it not in a fine granular way. Try to abstract from the implementation and to identify logical components. If you find such components, then your are able to describe their functionality and to describe the parts of the model it needs. Subsequently, you can separate your data model to the components and you get your bounded contexts. Furthermore, your components are nice approximations of microservices.
So, in short:
I hope, it helps
Martin already provided excellent feedback considering the DDD perspective.
In addition to that, I would just like to highlight that it might be worth examining the monolith itself (source code, analysis or design documents). Althgough DDD provides a clear guidance and can assist with finding microservices. However, this design might not be easily achieved by refactoring the monolith but requires new development for the services (including time and resources).
In case of time and resource restrictions, you might want to consider separating loosely copupled modules from the monolith in order to gain quick wins together with your development team.
Dear @Thomas Martin Prinz and Dear @Jürgen Jung
Thanks a million, it helped me straight, I think study the DDD would be help either
- Badges
- Science topic
- Similar topics
- Agriculture