A proposal to group microservice candidates from existing applications:

Introduction: Human interpretation of existing applications for the purposes of refactoring relies on knowledge of abstract software models. There is no substitute for reverse engineering it this way because the levels of abstraction can be decided by those who benefit from them. Forward engineering part of the application modernization becomes straightforward when the abstractions detail just what needs to be refactored. On the other hand, most web application software often follow well-known patterns of model-view-controller and their variations. They also benefit from well-defined levels of front-end, middle tier and backend.

In these cases, the refactoring of application into microservices is possible when there are groups drawn from those levels and components. Even if the middle-tier is a large object-relational model and the database is a large instance, it is possible to determine many independent groups from the schema and classes by merely establishing a graph with classes as units and edges as relationships in terms of inheritance and composition. The independent groups will be those islands of sub-graphs that are not connected.  Establishing a graph of the class dependencies is helpful because the frequency of usage can be overlayed over the graph as weights on the edges, which then helps to ease the hot spots by splitting the usages. It will not help with forming new entities or objects but that is a detail that can become apparent once the groupings are well-formed. It is also possible to define new entities by grouping the properties and methods within a set of units but that is a level of detail further than the grouping of classes that encapsulate them and beyond the scope discussed here.

Grouping of units is based on the criteria of connected components in this case. This does not have to be the only criteria. Many other criteria can be included to form groups and these groups can even be ranked by the collective use of criteria. A frequently occurring group across criteria is ranked higher. Criteria can be based on co-occurrence of certain classes. Model, view and controller are classic examples of those classes that co-occur. Even when the mappings are not straight forward such as thick layers or monoliths, the combination of criteria such as independence sets and co-occurrence can help to improve the cohesion and separation of clusters. If there are multiple criteria, then the groups can be assigned a score by each criterion and the largest total can be thresholded to determine the selection.

Sample grouping: https://ideone.com/BUxjZT