# Assessing Evolution of Microservices Using Static Analysis
## 4 Evaluation Case Study
### Case Study Discussion
#### 4.5.1 Question-Based Reasoning  
Analyzing metric values raises questions about the system's properties during its evolution. While team members familiar with the system might know the answers, practitioners often need to examine the individual source code of each microservice for investigation. Visualization helps practitioners in exploring and reasoning about these metrics at various levels of detail. Therefore, an intermediate representation is provided in a universal JSON format, ready to be integrated into visualization tools such as those described in [19; 32]. The following case study reasoning questions (CQ) have emerged to demonstrate how to follow the indicators provided by metrics to investigate the reasons through the system's source code. 1. What factors contributed to the high number of connections in the v0.0.1 service view compared to the other two versions? 2. What explains the disparity between the number of relationships and entities? 3. Why are there no relationships and transient entities in v0.0.1? 4. What is the reason for the substantial number of merged entity candidates (\(\#MDE_{s}\)), particularly in v0.2.0? In response to CQ1, the reduced number of connections in v0.0.1 can be attributed to the presence of multiple composite microservices that require communication with other services to fulfill their functionalities. This can be exemplified by considering two services, _ts-preserve-service_ and _ts-station-service_. The former, _ts-preserve-service_, lacks persistence storage but relies on 12 other microservices to accomplish its functions. Conversely, the latter, _ts-station-service_, has no dependent services but boasts 21 dependencies. Furthermore, addressing CQ2, the logical relationships between entities rather than direct connections can explain the metrics indication. For instance, the Listing 1 demonstrates that the _FoodStore_ entity within _ts-food-service_ utilizes the _stationId_ field to store the ID value of a _Station_ entity, even though no established relationship formally links the two entities. Additionally, the structure of certain microservices, such as _ts-station-service_, featuring persistent storage, while others, like _ts-preserve-service_, lack this feature, can add more justification to this question. ```
1@Data
2 publicclassFoodStore{
3 privateUUIDid;
4//logicalrelationship
5 privateStringstationId;
6}
```  
Listing 1: Logical relationship (_ts-food-service: FoodStore entity_). Answering CQ3 involves two aspects. First, the absence of transient data entities in v0.0.1, unlike the other two versions, is attributed to the fact that v0.0.1 does not employ Lombok annotations to annotate their transient data classes. Consequently, the prototype could not guarantee other hypotheses for identifying transient entity types. Furthermore, upon investigation, it was revealed that v0.0.1 uses some of the persistent data entities for the purpose of transferring data between microservices. While this may appear as a limitation in the prototype's implementation, after investigation, it highlights an evolutionary perspective on the diverse techniques and strategies employed by v0.0.1 for handling transient data entities, distinct from the approaches taken in the other two versions. The second aspect of this question pertains to the different types of persistent data entities. In v0.0.1,in addition to the absence of transient data entities, no relationships were extracted. This is because v0.0.1 utilizes a non-relational database, MongoDB, for persistence storage. As summarized in Table 5, the system transitioned from non-relational to relational databases in the latest version. Addressing CQ4, this study provides insights into the process of merging entities across multiple bounded contexts. As highlighted in Table 6, v0.2.0 contains a total of 209 entities (\(\#PDE_{s}+\#TDE_{s}\)) within its bounded context. However, this number of entities is significantly reduced to 70 entities within the context map after merging 139 candidate entities.