As businesses embrace concepts for rapid, scalable, and maintainable software systems, microservices adoption is gaining traction. Meanwhile, the current work on software architecture metrics focuses mainly on measuring modularity metrics in object-oriented programming, particularly in the Java environment. To address this gap, we propose a method for measuring fundamental quality attributes coupling and cohesion to evaluate architectural modularity specifically in the context of JavaScript-based microservices. In addition, we conduct a case study with coupling and cohesion measurement methods for evaluating architectural modularity in JavaScript-based microservices. We finally discuss future directions of refining these metrics in the dynamic context of microservices design.
CEUR ceur-ws.org
The introduction of microservices architecture into the industrial technological landscape of
software development has altered the way applications are developed and deployed. Microservices
provide outstanding flexibility and scalability, allowing businesses to construct sophisticated
systems built of loosely connected, independently deployable services [
However, previous research on software architecture metrics primarily focused on
objectoriented programming (OOP) languages such as Java. For example, Panichella et al. (2021)
investigated structural coupling in 17 Java-based open-source projects that used docker in their
implementation [
To narrow down the gap between the practices (e.g., implementation by Javascript) and the
metrics (e.g., metrics for Java), we propose a method for measuring coupling and cohesion
to evaluate architectural modularity, specifically in the context of JavaScript-based
microservices. Modularity is regarded as a property that influences software robustness [
The rest of this paper is organized as follows: Section 2 introduces the background of architectural styles and technology used. Section 3 describes the implementation of architecture and the metric used to evaluate it. Section 4 reports the results. Finally, Section 5 concludes the ifndings and discusses future work.
In this section, we brief the architectural styles and technologies employed in this research.
Microservices are an architectural concept that divides complicated software systems into
smaller, self-contained parts that can be deployed independently without impacting the rest of
the system, allowing for more flexibility and agility. Furthermore, because of the small size of
the units and the independence of the services, they can be deployed frequently and quickly to
gather input and make adjustments to create a better system [
The main characteristics of the Microservices Architecture (MSA) are:
1. Decomposition: A complicated system can be divided into more manageable
components, which facilitates development, maintenance, and scalability build based on business
capabilities [
These characteristics make microservices architecture appropriate for software systems with complexity, dynamic requirements, and rapid scalability.
Microservices provide advantages but often create obstacles. As the system expands, it
becomes increasingly important to strike a balance between coupling and cohesiveness. Because
microservices are supposed to be loosely coupled, the complexities of maintaining low coupling
while retaining strong cohesion become increasingly apparent [
Microservices architecture also poses a cost management problem owing to higher
infrastructure, operational, and development expenses. It is dificult to allocate expenses to services and
teams. Limiting expenditures while preserving system performance is a delicate balance [
Because of its adaptability and widespread acceptance, JavaScript has become a popular choice for deploying microservices in modern software development. JavaScript is an essential programming language for modern software applications due to its flexibility in implementing object-oriented or functional programming paradigms, a rich ecosystem of libraries, frameworks, and tools, and widespread use in software development, including microservices and serverless applications.
Object-Oriented Programming (OOP) and Functional Programming (FP) are two separate paradigms in JavaScript. OOP is all about constructing objects that contain data and functionality, and it frequently involves inheritance via prototypes. This method provides structure but can result in complicated inheritance hierarchies. In contrast, functional programming stresses pure functions and immutable data, increasing predictability and modularity. Because of the adaptability of JavaScript, developers may combine various paradigms, selecting the optimal technique for their project’s goals and coding tastes.
Versatility of JavaScript as an object-oriented or functional programming language makes
it perfect for implementing microservices. Developers can tailor their approach to meet the
demands of their services, ranging from standard object-oriented structures to data-driven
paradigms. This flexibility, however, can lead to compatibility concerns and complicated
communication across services, demanding well-defined interfaces and communication protocols
in order to preserve architecture integrity and cohesiveness. Therefore, measuring the
coupling and cohesion is really important to asses the adaptation of microservices and get insight
about maintenance efort, and warn the developer whether changes in service will harm the
other services. Furthermore, JavaScript processes incoming requests asynchronously, with a
single-thread processing model. For parallelized performance, many processes are required.
Microservices frequently employ many Docker containers for scaling up or scaling out, putting
additional strain on computers [
We employed a microservices architecture in our trial setup, with JavaScript as the major programming language. Docker containers were used to encapsulate each microservice, providing consistent and isolated settings. Kubernetes, a container orchestration technology, played a critical role in managing, growing, and orchestrating these microservices.
In our studies, we used a ticketing system1 as a case study to demonstrate the fundamentals of microservices architecture. Figure 1 illustrates the architectural design, illustrating a clear and comprehensive picture of the structure and component interactions of the ticketing system. The system has five distinct services, and each service has its own set of functionality, as shown in Table 1
JavaScript was used to develop the systems. We utilize express.js as the backend framework. The system is built as a Docker container and is orchestrated using Kubernetes.
In this study, we manually analyze the code for each function or class to assess the additional library use as well as the inter- and intra-service dependencies that will be counted as eferent coupling. The sample of intra-service and inter-service dependencies from the ticketing system is shown in Figure 2. As shown in Figure 2, the listener class or function from the services is dependent on the publisher class or function from other services considering inter-service dependency. The listener will be triggered to carry out their function if the publisher has an execution function. The listener class will be impacted by modifications to the publisher’s code or design. This coupling should be noticed by the developer. Consequently, even though inter-services are not directly imported from the same class or function, they are nevertheless computed as eferent couplings.
We evaluated the microservices architecture using the modularity measure of the software
architecture. This metric was a critical indicator of the system design. By evaluating the
modularity of our microservices, we received significant insights into the architecture capability
to improve maintainability, reusability, and scalability. This metric also ensured that the system
components were properly separate and were capable of operating independently [
Software architecture metrics are critical elements of assessing and measuring the design
quality and performance of a software system. These metrics give objective assessments of
architectural characteristics like modularity, complexity, and connection. Developers and
architects may make knowledgeable judgments, uncover possible dificulties, and optimize
the design to fulfill particular goals and needs by examining these data. In essence, software
architectural metrics are critical for guaranteeing software system dependability, maintainability,
and scalability. Our primary focus in this study is on the modularity measure in the context of
software architecture. We carefully studied how efectively the system’s components could be
divided into self-contained modules and evaluated the degree of independence these modules
demonstrated. Modularity describes a logical grouping of similar code, such as classes in an
object-oriented language or functions in a structured or functional language. Most programming
languages have techniques for modularity [
This study will specifically assess modularity by assessing the amount of coupling and cohesion within the software architecture. Measuring coupling allows us to examine the interdependence of distinct modules, whereas measuring cohesion determines the strength of logical linkages inside specific modules.
Cohesion defines the degree to which a module’s elements are contained inside it, demonstrating
their relative connection. A coherent module should be packed together since splitting it up
would necessitate coupling it through calls across modules [
We assess cohesion using the LCOM metric. The Chidamber and Kemerer Lack of Cohesion
in Methods (LCOM) metric assesses the structural cohesiveness of a module, which is typically
a component [
| | − ||, | | > || {0 otherwise (1)
P is the number of methods that do not access shared variables while Q is the number of shared variables.
Coupling in software design refers to the degree of interdependence or connection between distinct components or modules inside a system. It measures how tightly these components rely on one another. Strong coupling indicates considerable dependency, while weak coupling shows greater independence. Coupling can be measured by calculating abstractness, instability, and distance from the main sequence.
Abstractness is defined as the ratio of abstract artifacts (classes, interfaces) to concrete objects
(implementation). It compares abstraction to implementation. No abstractions resulting in a
single function, while too many abstractions make it dificult for developers to comprehend
how things work together [
= ∑ ∑
The instability metric assesses the volatility of a code base. High instability suggests a higher
likelihood of breaking pieces of code as a result of intense coupling, such as when a functionality
is distributed to numerous classes [
= +
The distance metric expects an ideal balance of abstractness and instability, allowing developers to measure the distance from the main sequence metric for classes that are close to this idealized line illustrated in Figure 3
In an ideal scenario, a well-structured module or service should indeed exist in the ”green
area” , which represents a state of optimal balance of abstractness and instability [
As for cohesion metric, Figure 4 illustrates the result of cohesion evaluation by LCOM. Figure 4 shows a remarkable pattern in which all services earn an LCOM score of 1. This assessment demonstrates that the services portrayed have a consistent and unified design. Services with an LCOM score of 1 are frequently easier to understand, manage, and alter since they have a concentrated and self-contained structure.
The framework utilized in this ticketing system emphasizes the Single Responsibility Principle (SRP) while creating routing APIs to guarantee that each route handler function inside the system is focused on a single, well-defined responsibility. This not only improves cohesiveness but also simplifies maintenance and encourages reusability.
We discovered that the eferent coupling exceeded the aferent coupling in our coupling measure evaluation illustrated in Figure 5 (a), suggesting that there were more dependencies outside the system components than within. The integration of external libraries into the codebase, which naturally produced stronger eferent coupling by generating dependency on other resources, was the fundamental cause of this diference. Despite the external dependencies, the overall system instability remained substantial, emphasizing the importance of careful control of these external dependencies.
However, in our coupling metric assessment, we received a 0 score in abstractness, according to Express.js default design philosophy of simplifying web routing. This score indicates that Express.js reduces the need for complicated abstraction layers, as its fundamental design handles HTTP routing complexity eficiently. Rather than adding levels of abstraction, Express.js encourages developers to create routes and associated handlers directly.
The overall performance of the ticketing system in coupling is remarkable, with a balanced ratio between abstractness and instability shown in Figure 5 (a). Among all services, Orders and Auth services are visually closest to the green area.
Our studies employed the ticketing system as a real-world case study to evaluate the modularity metric inside a JavaScript-based microservices architecture. We examined the subtle balance of coupling and cohesion, evaluating the interdependencies among system components while ensuring that each module remained self-contained and focused on specific tasks. This study reinforces the relevance of modularity and coherent design in microservices, demonstrating their potential to improve maintainability and flexibility in software systems.
In future studies, we plan to deepen our understanding of software architecture metrics and investigate other assessment methodologies to improve decision-making abilities for maintaining software architecture. We want to broaden our knowledge base by looking at other metrics that might give more information about software architecture. Furthermore, we intend to conduct research that will lead to the creation of practical and user-friendly tools for assessing these metrics.