Source-linked AI summary
From Monolith to Microservices: A Classification of Refactoring Approaches
Jonas Fritzsch, Justus Bogner, Alfred Zimmermann, Stefan Wagner
TL;DR
The paper addresses the lack of clear guidance for refactoring legacy monoliths into Microservices, a process shaped by service-granularity choices. It reviews and classifies ten approaches by decomposition strategy and presents a decision guide; most approaches have conditional applicability, and practical tool support is limited.
Problem
The study addresses the lack of systematic guidance on which architectural refactoring approaches decompose monoliths into Microservices and how their strategies are classified.
Source: §1 · p. 2Method
A literature review identified and classified ten approaches into four groups based on decomposition strategy, then presented them in a decision guide.
Source: §4 · p. 4, §5 · p. 5, §5.1 · p. 6Results
The review found ten approaches across four decomposition-strategy groups, while most are not universally applicable and require different input data.
Source: §6 · p. 11Takeaways & Limitations
The decision guide helps readers identify an approach suited to a particular scenario, while Gysel et al.’s method is described as the most structured and universal.
Source: §5.2 · p. 9, §6 · p. 11The review examined techniques theoretically, relied on only three academic search engines, and did not follow systematic-review guidelines.
Source: §6 · p. 11
Abstract
from arXiv · showhide
While the recently emerged Microservices architectural style is widely discussed in literature, it is difficult to find clear guidance on the process of refactoring legacy applications. The importance of the topic is underpinned by high costs and effort of a refactoring process which has several other implications, e.g. overall processes (DevOps) and team structure. Software architects facing this challenge are in need of selecting an appropriate strategy and refactoring technique. One of the most discussed aspects in this context is finding the right service granularity to fully leverage the advantages of a Microservices architecture. This study first discusses the notion of architectural refactoring and subsequently compares 10 existing refactoring approaches recently proposed in academic literature. The approaches are classified by the underlying decomposition technique and visually presented in the form of a decision guide for quick reference. The review yielded a variety of strategies to break down a monolithic application into independent services. With one exception, most approaches are only applicable under certain conditions. Further concerns are the significant amount of input data some approaches require as well as limited or prototypical tool support.
1 Introduction
Organizations seek to make mature monolithic applications cloud-ready, but accumulated complexity makes them difficult to maintain and scale efficiently. The study asks what architectural refactoring approaches decompose monoliths into Microservices and how their strategies can be classified.
1 Introduction
- Organizations moving enterprise applications to the cloud seek flexible, loosely coupled compositions of specialized services.The cited motivations include availability, redundancy, automatic scaling, infrastructure management, and security compliance.Source: §1 · p. 1
- Monoliths can become difficult to maintain and adapt, while scaling them often requires duplicating the entire application rather than individual modules.The paper notes that this can be inefficient when workloads change quickly.Source: §1 · p. 2
- Microservices require contextually related modules to be encapsulated as services with appropriate granularity, but refactoring a mature monolith can be a long process.Building a new Microservices application from scratch can also be expensive and time-consuming.Source: §1 · p. 2
- The study aims to compare and classify academic refactoring approaches, asking which approaches decompose monoliths into Microservices and how their techniques and strategies differ.Source: §1 · p. 2
2 Architectural Refactoring and Decomposition
Architectural refactoring changes system structure to improve quality attributes while preserving scope and functionality, and may also affect organizational structure. For Microservices, the central challenge is identifying business-oriented service boundaries at suitable granularity.
2 Architectural Refactoring and Decomposition
- Refactoring is described as a behavior-preserving transformation that improves structurally deteriorated code or addresses accumulated technical debt.Source: §2 · p. 2
- Architectural refactoring improves quality attributes without changing a system’s scope or functionality, and may alter organizational structure.It differs from code-level refactoring in its high impact and its connection to cloud, deployment, release-cycle, and organizational changes.Source: §2 · pp. 2–3
- Functional decomposition around business capabilities is presented as a way to reduce dependencies across technical layers, often with a lightweight integration layer.The paper identifies suitable service granularity as a central challenge for architects.Source: §2 · p. 3
- Bounded contexts, use cases, resources, and code seams are discussed as ways to identify separable portions of a monolith, but no universally valid decomposition algorithm exists.The paper warns that incorrect domain modeling can produce architectures combining drawbacks of both Monoliths and Microservices.Source: §2 · p. 3
3 Related Work
Prior work discusses migration and service identification, but the paper finds no holistic review of concrete Microservices refactoring approaches and decomposition techniques. Existing reviews and pattern collections provide related but differently scoped evidence.
3 Related Work
- The authors identify no holistic literature review of concrete refactoring approaches and decomposition techniques for migrating monoliths to Microservices.A 2016 mapping study identified 3 of 21 studies on migration, and a 2017 review identified 16 of 71 migration-related studies.Source: §3 · pp. 3–4
- Balalaie et al.’s empirically identified migration patterns complement this review but present concepts at a higher abstraction level than concrete literature approaches.SOA service-identification research offers a related overview, though its suitability for Microservices may be limited by architectural differences.Source: §3 · p. 4
4 Research Method and Search Strategy
The review followed a planning, conducting, and documenting structure and searched three computer-science databases. Selection combined peer-review, language, contribution, and validation criteria with snowballing and qualitative assessment.
4 Research Method and Search Strategy
- The review searched ACM Digital Library, IEEE Xplore, and Google Scholar, using a three-step planning, conducting, and documenting structure.Fig. 1 illustrates the basic literature-search steps.Source: §4 · p. 4, Figure 1 · p. 4
- Search queries combined Microservice terms with optional monolith and refactoring, transformation, migration, decomposition, partitioning, or granularity terms.Source: §4 · pp. 4–5
- Studies had to be peer-reviewed, in English, relevant to the research question, and include documented validation; snowballing expanded the initial results.The final qualitative assessment considered technical depth, recency, and relevance.Source: §4 · p. 5
5 Results
The review selected ten approaches judged adequate for generalization, categorized them by decomposition strategy, and presents a decision guide to help architects choose for a scenario.
5 Results
- The literature review identified ten approaches with adequate abstraction and potential for generalization, while many other studies were tailored to specific scenarios.The work by Chen et al. appeared after the review was completed and was not included.Source: §5 · p. 5
5.1 Classification
- The classification groups decomposition strategies into static-code, metadata, workload-data, and dynamic-composition approaches.Static-code approaches derive cuts from source code; metadata approaches use artifacts such as UML, interfaces, or version-control history; workload-data approaches use operational measurements; dynamic composition recalculates service composition as workload changes.Source: §5.1 · p. 6
- Tables 2 and 3 compare approach type, applicability, strategy, atomic unit and granularity, inputs and outputs, evaluation, tool support, and validation.The review notes a general lack of tool support, which hinders automation, empirical evaluation, and thorough assessment.Source: §5.1 · p. 6, Table 2 · p. 7, Table 3 · p. 8
- Examples include clustering interface specifications by semantic similarity and clustering version histories by logical, semantic, or contributor coupling.The interface approach uses semantic similarity [4], while the version-history approach calculates decompositions through graph-based clustering.Source: §5.1 · p. 7
5.2 Decision Guide
- The decision guide routes architects through alternatives for a specific scenario and returns dashed branches to the main flow when an option does not fit.If all alternatives are discarded, it proposes Service Cutter (#5), described as the most mature tool-supported general-purpose approach in the review, though it requires a comprehensive system specification.Source: §5.2 · p. 9
- The guide groups approaches with dynamically changing granularity together rather than distinguishing them, reflecting their runtime environments and complexity.The authors say these environments are not discussed in sufficient detail for further differentiation.Source: §5.2 · p. 9
6 Conclusion
The review classifies ten architectural refactoring approaches into four groups and finds gaps in practical applicability, tools, and evaluation metrics. Its conclusions are bounded by a non-systematic, theoretical review and an unvalidated decision guide.
6 Conclusion
- A literature review identified and categorized ten recently proposed architectural refactoring approaches into four groups based on their decomposition strategies.The authors describe decomposition as the most challenging step from an architect’s perspective.Source: §6 · p. 11
- Most reviewed approaches are not universally applicable, and the field lacks practically applicable options with adequate tool support and metrics for verifying results.The approaches require different sets of input data; Gysel et al. is described as structured and universal, but depends on an exhaustive system specification.Source: §6 · p. 11
- The review was not systematic, used only three academic search engines, assessed techniques theoretically, and did not systematically construct or validate its decision guide.The authors state that thorough assessment requires testing approaches on sample applications or real-world systems.Source: §6 · p. 11
- Future work will combine static code analysis with runtime operations data, define quantitative decomposition metrics, and explore automation for large heterogeneous code bases.Source: §6 · p. 11