---

---

Overview

The quality of the architecture can be assessed using a set of metrics and rules that are built into the vFunction platform.

Once a measurement is set as a baseline in vFunction (Observation page), the platform creates TODO items reflecting the quality and cloud readiness of the application. The TODOs are associated with “architectural events”, each corresponding to a different aspect of quality and readiness.

vFunction platform can be configured to periodically collect new data from a new version of the application and update the TODO items – new items (e.g., introducing a new non-exclusive resource) or items that are resolved (e.g., a TODO for a resource that was non-exclusive and now is exclusive will change its status to DONE). This continuous architectural observability (AO) can be achieved by integrating commands to the CI/CD pipeline or one can use a periodic schedule to start and stop learning and analysis cycles to obtain new measurements.

See a summary of the various factors below that help move the application towards a state of, “Cloud Ready.”

---

Exclusivity

A class or resource used only by a single domain is called exclusive to that domain. Non-exclusive class or resource means they are being used by more than a single domain. The exclusivity of a domain is measured by three metrics:

The higher each of the exclusivity metrics is the better, as it means the domain is more independent from the rest of the application. Higher exclusivity means better Engineering Velocity since it is easier to maintain an independent domain, better Resiliency, since it would be easier to create a redundancy mechanism for such domains and the flows triggered by well defined entry points can be made more resilient for unexpected inputs or states. Also, if the domain is extracted as a service, then it would be easy to improve its scalability without affecting other parts of the system.

The overall dynamic class exclusivity and resource exclusivity appear in the analysis summary of the UI.

---

High-Debt Classes

vFunction uses the combined static and dynamic data to identify “god objects” or “god classes” which is an anti-pattern that affects several aspects of quality (see: https://linearb.io/blog/what-is-a-god-class). vFunction uses three metrics to identify these classes: (1) size – no. of class methods, (2) dependents – how many methods use the class and (3) dependencies – how many other classes are used by the class. These complexity scores are normalized to a value between 1 and 10 and the classes that score more than 3 are listed as high debt classes. The higher the score, the more such classes are identified as high-debt, and the worse the quality. High-debt classes with score 4 and above (depending on the application size) should be reviewed and considered for refactoring.

---

Circular Dependencies of Libraries

Circular dependencies between libraries (assemblies or jars) should never be allowed to exist as they pose a serious maintenance issue. vFunction detects such circular dependencies and can show the class dependencies causing it. These dependencies must be fixed to remove the circular dependencies, often by applying the Dependency Inversion Principle (DIP) of clean architecture.

---

Topology

Domain to domain calls introduce complexity to the architecture and if the domains are to be implemented as services, then cross service calls may also introduce latency. Nevertheless, sometimes inter domain calls are the right choice, for example, if we have multiple domains that use another domain (say a reporting domain or an access control domain) as a lower layer.

---

Circular Dependencies of Domains

vFunction identifies and highlights circular dependency chains across domains. This coupling between domains must be avoided: every domain represents a functional capability of the system that should be developed and maintained as independently as possible from the other domains. One can address such circular dependencies either by modifying the domain boundaries and scope in vFunction (for example, merge domains) or by refactoring and removing the dependencies from the classes.

---

Dead-Code

vFunction detects potential classes as dead-code and users can either verify them as dead-code or unmark them as dead-code. Dead-code should be removed from the code base.

---

Size of Common Library

The common library is a collection of classes that are not domain specific and are typically used by multiple domains. These classes are called “common classes”. It is preferred to keep size of the common library to a minimum since it creates an indirect dependency between the domains and changing common classes may affect multiple domains.

---

Compatibility

vFunction TODOs mechanism creates a set of recommendations for migrating to different cloud and more modern platforms using Windup which is a rule-based application migration and assessment tool. Here are a few example issues and recommendation:

---