Monolith vs. Microservices Refactoring via Graph Comparison of Source Code vs. Domain Model

Abstract

A system / technique is provided that facilitates monolith-to-microservices refactoring via graph comparison of source code to domain model. The system is configured to have access to the source code of a monolithic application and a target domain model corresponding to the monolithic application, and is configured to refactor the monolithic application into microservices by aligning a first graph representing the source code with a second graph representing the target domain model.

Description

[Technical Field]

[0001] The present disclosure relates to microservices refactoring, and more specifically to monolith-to-microservices refactoring via graph comparison of source code to domain models. Summary of the Invention

[0002] The following presents a summary to provide a basic understanding of one or more embodiments of the invention. This summary is not intended to identify key or essential elements or to delineate the scope of particular embodiments or the claims. Its sole purpose is to present concepts in a simplified form as a prelude to the more detailed description that is presented later. In one or more embodiments described herein, a device, system, computer-implemented method, apparatus, and / or computer program product that facilitates monolith-to-microservices refactoring via graph comparison of source code to domain model is described.

[0003] According to one or more embodiments, a system is provided. The system may include a non-transitory memory capable of storing computer-executable components. The system may further include a processor operatively coupled to the memory and capable of executing the computer-executable components stored in the memory. In various embodiments, the computer-executable components may include an accessing component capable of accessing source code of a monolithic application and a target domain model corresponding to the monolithic application. In various aspects, the computer-executable components may further include a mapping component capable of refactoring the monolithic application into microservices by aligning a first graph representing the source code with a second graph representing the target domain model.

[0004] According to one or more embodiments, the above-described system may be implemented as a computer-implemented method and / or a computer program product. [Brief explanation of the drawings]

[0005] [Figure 1] FIG. 1 illustrates a block diagram of an exemplary, non-limiting system for facilitating monolith-to-microservices refactoring via graph comparison of source code to domain model, in accordance with one or more embodiments described herein.

[0006] [Figure 2] 1 illustrates an exemplary, non-limiting block diagram of source code for a monolithic application in accordance with one or more embodiments described herein.

[0007] [Figure 3] 1 illustrates an exemplary, non-limiting block diagram of a target domain model in accordance with one or more embodiments described herein.

[0008] [Figure 4] FIG. 1 illustrates a block diagram of an example, non-limiting system including a code graph and / or a model graph that facilitates monolith-to-microservices refactoring via graph comparison of source code to domain models, in accordance with one or more embodiments described herein.

[0009] [Figure 5] 1 illustrates an exemplary, non-limiting block diagram of a code graph and / or a model graph in accordance with one or more embodiments described herein. [Figure 6] 1 illustrates an exemplary, non-limiting block diagram of a code graph and / or a model graph in accordance with one or more embodiments described herein. [Figure 7] 1 illustrates an exemplary, non-limiting block diagram of a code graph and / or a model graph in accordance with one or more embodiments described herein.

[0010] [Figure 8] FIG. 1 illustrates a block diagram of an example non-limiting system including a set of node pairs that facilitates monolith-to-microservices refactoring via graph comparison of source code to domain model, in accordance with one or more embodiments described herein.

[0011] [Figure 9] 1 illustrates an exemplary, non-limiting block diagram showing how a set of node pairs is generated based on a code graph and / or a model graph, in accordance with one or more embodiments described herein. [Figure 10] 1 illustrates an exemplary, non-limiting block diagram showing how a set of node pairs is generated based on a code graph and / or a model graph, in accordance with one or more embodiments described herein. [Figure 11] 1 illustrates an exemplary, non-limiting block diagram showing how a set of node pairs is generated based on a code graph and / or a model graph, in accordance with one or more embodiments described herein. [Figure 12] 1 illustrates an exemplary, non-limiting block diagram showing how a set of node pairs is generated based on a code graph and / or a model graph, in accordance with one or more embodiments described herein.

[0012] [Figure 13] FIG. 1 illustrates a block diagram of an exemplary non-limiting system including feedback to facilitate monolith-to-microservices refactoring via graph comparison of source code to domain model, in accordance with one or more embodiments described herein.

[0013] [Figure 14]FIG. 1 illustrates a block diagram of an example, non-limiting system including a set of gaps that facilitates monolith-to-microservices refactoring via graph comparison of source code to domain model, in accordance with one or more embodiments described herein.

[0014] [Figure 15] 1 illustrates an exemplary, non-limiting block diagram showing how a set of gaps is identified based on a set of node pairs in accordance with one or more embodiments described herein. [Figure 16] 1 illustrates an exemplary, non-limiting block diagram showing how a set of gaps is identified based on a set of node pairs in accordance with one or more embodiments described herein.

[0015] [Figure 17] FIG. 1 illustrates a block diagram of an example, non-limiting system including a set of coding templates that facilitate monolith-to-microservices refactoring via graph comparison of source code to domain model, in accordance with one or more embodiments described herein.

[0016] [Figure 18] FIG. 1 illustrates a flow diagram of an exemplary, non-limiting, computer-implemented method for facilitating monolith-to-microservices refactoring via graph comparison of source code to domain model, in accordance with one or more embodiments described herein. [Figure 19] FIG. 1 illustrates a flow diagram of an exemplary, non-limiting, computer-implemented method for facilitating monolith-to-microservices refactoring via graph comparison of source code to domain model, in accordance with one or more embodiments described herein. [Figure 20] FIG. 1 illustrates a flow diagram of an exemplary, non-limiting, computer-implemented method for facilitating monolith-to-microservices refactoring via graph comparison of source code to domain model, in accordance with one or more embodiments described herein. [Figure 21]FIG. 1 illustrates a flow diagram of an exemplary, non-limiting, computer-implemented method for facilitating monolith-to-microservices refactoring via graph comparison of source code to domain model, in accordance with one or more embodiments described herein.

[0017] [Figure 22] FIG. 1 illustrates a flow diagram of an exemplary, non-limiting, computer-implemented method for facilitating monolith-to-microservices refactoring via graph comparison of source code to domain model, in accordance with one or more embodiments described herein.

[0018] [Figure 23] 1 illustrates a block diagram of an exemplary non-limiting operating environment in which one or more embodiments described herein may be facilitated.

[0019] [Figure 24] 1 illustrates an exemplary, non-limiting cloud computing environment in accordance with one or more embodiments described herein.

[0020] [Figure 25] 1 illustrates exemplary, non-limiting abstraction model layers in accordance with one or more embodiments described herein. DETAILED DESCRIPTION OF THE INVENTION

[0021] The following detailed description is merely exemplary and is not intended to limit the embodiments and / or the application or uses of the embodiments, nor is it intended to be limited by any express or implied information presented in the preceding Background or Summary sections or in the Detailed Description section.

[0022] One or more embodiments are now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a more thorough understanding of one or more embodiments. It will be apparent, however, that in various instances one or more embodiments may be practiced without these specific details.

[0023] A monolithic application may be a self-contained set of computer programs, each of which is a sequence of computer-executable instructions that may be independent of (e.g., avoid invocation / invocation of) other computing applications. That is, a monolithic application performs / facilitates an overarching function / task, where that overarching function / task is composed of many different sub-functions / sub-tasks, and where the code base of the monolithic application may include all (or substantially all) computer-executable instructions for performing / facilitating such many different sub-functions / sub-tasks. Monolithic applications are generally too large and / or cumbersome to fit into cloud-native environments, and they often fail to exhibit the benefits that cloud-native applications offer (e.g., scalability, continuous deployment, stateless deployment, agility, ease of troubleshooting).

[0024] In contrast to monolithic applications, microservices can be independently developable and / or deployable sub-applications that may depend on (e.g., call / invoke) other microservices and / or other computing applications. That is, a microservice can be a code base that performs / facilitates at most one or otherwise a small number of specific sub-functions / sub-tasks. In various cases, microservices can be cloud-based. In various cases, multiple microservices are loosely coupled together (e.g., via service-exposing method calls) to form an overall and / or overarching computing application.

[0025] In various aspects, it may be beneficial to modernize a monolithic application by refactoring the monolithic application into microservices. As one skilled in the art will appreciate, refactoring a monolithic application into microservices may include identifying which specific portions of the monolithic application's source code perform the same sub-functions / sub-tasks as various microservices, so that those specific portions of the source code can be replaced and / or substituted (e.g., incrementally and / or all at once) by those various microservices.

[0026] Some techniques for refactoring monolithic applications into microservices may operate in a bottom-up manner. In particular, such bottom-up techniques detect internal functional boundaries in the source code of a monolithic application, where the detected bounded portions of the source code may be treated as potential candidates for microservice exchange / replacement. Unfortunately, and as the inventors of various embodiments described herein recognize, such bottom-up techniques may fail to consider external information about which microservices are available and / or which sub-functions / sub-tasks those microservices perform. Due to such failure to consider external information about the microservices, such bottom-up techniques may often result in inaccurate, imprecise, and / or otherwise unhelpful refactoring results (e.g., such bottom-up techniques may suffer from granularity mismatches, sub-function / sub-task mismatches, and / or vocabulary mismatches between the detected bounded portions of the source code and the available microservices because external information about the available microservices is not considered).

[0027] Other techniques for refactoring monolithic applications into microservices may operate in a top-down manner. In particular, such top-down techniques (e.g., domain-driven design, event storming) may involve obtaining / constructing a target domain model (e.g., a banking industry architecture network (BIAN) model, an enhanced telecommunications operations map (eTOM) model). In various cases, the target domain model may be a standardized and / or non-standardized document that defines the functional expectations and, therefore, microservices to be met by the monolithic application. In various aspects, such top-down techniques may further involve having subject matter experts determine which portions of the monolithic application's source code correspond to which microservices dictated by the target domain model. The use of the target domain model as an external reference by such top-down techniques may help ameliorate some of the shortcomings of the bottom-up techniques described above. However, such top-down techniques are entirely manual processes and may consume several months' worth of effort.

[0028] Therefore, systems and / or techniques that can address one or more of these technical problems would be desirable.

[0029] Various embodiments described herein may ameliorate one or more of such technical problems. More specifically, various embodiments described herein may include devices, systems, computer-implemented methods, apparatus, and / or computer program products that can facilitate monolith-to-microservices refactoring via graph comparison of source code to a domain model. In other words, the inventors have devised a computer-implemented technique for automatically refactoring monolithic applications into microservices, which may include the application of graph-theoretic comparison metrics between the source code of the monolithic application and a target domain model corresponding to the monolithic application. Because such computer-implemented techniques may leverage the target domain model, such computer-implemented techniques may avoid the pitfalls that plague the bottom-up techniques described above. Furthermore, because such computer-implemented techniques may automate the process of monolith-to-microservices refactoring via the application of graph-theoretic comparison metrics, such computer-implemented techniques may consume orders of magnitude less time than the top-down techniques described above (e.g., such top-down techniques may consume months' worth of time, whereas the computer-implemented techniques described herein may consume merely minutes' worth of time).

[0030] Various embodiments described herein are considered computerized tools (e.g., any suitable combination of computer-executable hardware and / or computer-executable software) that can facilitate monolith-to-microservices refactoring via graph comparison of source code to domain models. In various aspects, such computerized tools can include an access component, a graph component, a mapping component, a feedback component, a gap component, and / or an execution component.

[0031] In various embodiments, any suitable monolithic application may exist. In various aspects, a monolithic application is implemented by source code written in any suitable coding language and / or using any suitable coding syntax. In various cases, the source code of a monolithic application may be one or more scripts defining any suitable number of programs. In various cases, each program written within the source code may be any suitable sequence of computer-executable instructions. In some aspects, a program written within the source code may perform any suitable number of non-exposing method calls on any suitable number of data objects. Furthermore, in some cases, a program written within the source code may perform any suitable number of program-exposing method calls. As one skilled in the art will appreciate, a data object may be one or more scalars, one or more vectors, one or more matrices, one or more tensors, one or more strings, and / or any suitable combination thereof. As those skilled in the art will further appreciate, a non-exposing method call may be any suitable electronic function, operation, transformation, and / or manipulation that may be performed on a data object and that is considered self-contained within a single program of source code (e.g., a non-exposing method call may avoid interaction with other programs written within the source code). In contrast, and as those skilled in the art will also appreciate, a program-exposing method call may be an electronic invocation, activation, and / or initiation of another program written within the source code.

[0032] As a non-limiting example, assume that source code includes Program A and Program B. In various cases, Program A may access an input vector (e.g., a data object) and perform a function (e.g., an unexposed method call) on the input vector, thereby resulting in a transformed vector (e.g., another data object). Further, in various instances, Program A may invoke (e.g., expose) Program B, so that Program B may then operate on and / or otherwise utilize (e.g., perform another unexposed method call on) the transformed vector.

[0033] In various embodiments, a monolithic application may be associated with a target domain model. As one skilled in the art will appreciate, a target domain model may be any suitable electronic natural language document, whether standardized and / or non-standardized, that specifies, describes, defines, and / or otherwise indicates the functionality desired, expected, and / or aspired to be satisfied by a monolithic application. In other words, a target domain model may be considered a reference taxonomy / hierarchy of business logic to which a monolithic application is desired / expected to conform. For example, a target domain model may specify any suitable number of service domains in which a monolithic application is desired / expected to be implemented, where a service domain may be a description / designation of distinct and cohesive clusters of business logic that are considered responsible for performing / facilitating any suitable number of business capabilities in any suitable number of business objects. As one skilled in the art will appreciate, a business object may be a description / designation of any suitable electronic information / data, and a business capability may be a description / designation of any suitable function, behavior, transformation, and / or operation performed / facilitated in the business objects. Furthermore, the target domain model may, in various aspects, describe / specify any suitable number of interactions desired / expected to occur between different service domains. As some non-limiting examples, the target domain model may be a BIAN specification or an eTOM specification.

[0034] In any case, each service domain specified in the target domain model may be known and / or considered to correspond to at least one microservice. That is, for any given service domain in the target domain model, the target domain model specifies what business capabilities are expected to be performed, facilitated, and / or otherwise provided by that given service domain, and there may be at least one known microservice that can perform, facilitate, and / or otherwise provide those specified business capabilities.

[0035] In various embodiments, it may be desirable to refactor a monolithic application into microservices. As described herein, computerized tools may automatically facilitate such refactoring by leveraging both the source code of the monolithic application and the target domain model.

[0036] In various embodiments, an access component of a computerized tool may receive and / or otherwise access the source code and / or target domain model electronically. In some aspects, the access component may obtain the source code and / or target domain model from any suitable centralized and / or decentralized data structure (e.g., a graph data structure, a relational data structure, a hybrid data structure), whether remote from and / or local to the access component. In other aspects, the access component may obtain the source code and / or target domain model from any other suitable computing device. In any case, the access component obtains and / or accesses the source code and / or target domain model electronically, such that other components of the computerized tool may interact with (e.g., read, write, edit, copy, manipulate) the source code and / or target domain model electronically.

[0037] In various embodiments, a graph component of a computerized tool may electronically generate a graph (e.g., a data structure having nodes / vertices and edges) based on the source code. More specifically, in various aspects, the graph component may electronically parse the source code of a monolithic application via any suitable static and / or dynamic (e.g., runtime-based) parsing technique. Through such parsing, the graph component may identify and / or otherwise detect programs written within the source code. Furthermore, through such parsing, the graph component may identify and / or otherwise detect program exposure method calls written within the source code. In particular, for any given program exposure method call written within the source code, the graph component may discover, through such parsing, which programs in the source code are configured to make the given program exposure method call and which programs in the source code are configured to be invoked by the given program exposure method call. Accordingly, in various instances, the graph component constructs and / or otherwise generates a graph such that each node / vertex of the graph represents an identified / detected program (e.g., the graph component may generate one new node / vertex per program), and / or such that each edge of the graph represents an identified / detected program-exposed method call (e.g., the graph component may generate one new edge per program-exposed method call). In various instances, such graphs are referred to as code graphs because they are created based on source code.

[0038] In some cases, the code graph may be unweighted. In other cases, the code graph may be weighted according to any suitable attributes / characteristics of the programs written in the source code. For example, for any given node in the code graph, the given node represents a given program, and the attributes of the given node may include: entry point association with other nodes (e.g., the entry point association attribute may indicate whether the given program appears in the execution trace of another specific program); common entry points with other nodes (e.g., the common entry point attribute may indicate whether the given program and another specific program have the same entry point as each other); inheritance (e.g., the inheritance attribute may indicate whether a data object manipulated by the given program inherits one or more of its characteristics from and / or leaves one or more of its characteristics to the data object of another specific program); and / or data object association (e.g., the data object association attribute may indicate whether the given program and another specific program operate on the same data object as each other).

[0039] As a non-limiting example, assume that source code includes Program X, Program Y, and Program Z. Also assume that Program X includes a first program exposure method call to Program Y and a second program exposure method call to Program Z. Furthermore, assume that Program Z includes a third program exposure method call to Program Y. In such a case, the graph component may parse the source code to thereby identify / detect Program X, Program Y, Program Z, the first program exposure method call, the second program exposure method call, and the third program exposure method call. In various aspects, the graph component may create a graph based on such parsing. In particular, the graph may include: node X representing Program X; node Y representing Program Y; and node Z representing Program Z. Also, because the first program exposure method call is made from Program X to Program Y, the graph may include a first directed edge between node X and node Y, where the first directed edge may be a point away from node X toward node Y. Similarly, because a second program exposure method call is made from program X to program Z, the graph may include a second directed edge between node X and node Z, where the second directed edge may point away from node X toward node Z. Similarly, because a third program exposure method call is made from program Z to program Y, the graph may include a third directed edge between node Z and node Y, where the third directed edge may point away from node Z toward node Y. In this manner, the graph component may generate a graph based on programs and / or program exposure method calls identified / detected by parsing through the source code. As mentioned above, such a graph may be referred to as a code graph.

[0040] Furthermore, as described above, the graph component may, in various aspects, dynamically parse source code (e.g., during runtime of the source code) to generate different execution traces and / or generated logs of the source code. In various instances, such different execution traces and / or generated logs may indicate different sequences of program-to-program interactions implementable by the source code (e.g., different execution orders and / or different execution branches that the source code may take in different contexts). In some cases, such different sequences of program-to-program interactions may be referred to as different program transactions. In any case, edge weights of the code graph may be based on such different sequences of program-to-program interactions. For example, there may be many different program exposure method calls written within the source code, and some of the many different program exposure method calls may be implemented / executed more frequently than others. In particular, a first subset of the many different program exposure method calls may be included and / or otherwise present in a larger proportion of the different sequences of program-to-program interactions. Accordingly, edges of the code graph that respectively represent a first subset of the many different program exposure method calls may be assigned a larger and / or more important weight value. In contrast, a second subset of the many different program exposure method calls may be implemented / executed less frequently. That is, the second subset of the many different program exposure method calls may be included and / or otherwise present in a smaller percentage of different sequences of program-to-program interactions (e.g., it may even be possible for a program exposure method call to not be present in any sequence of program-to-program interactions, in which case such a program exposure method call would be considered unused despite its presence in the source code). Accordingly, edges of the code graph that respectively represent a second subset of the many different program exposure method calls may be assigned a smaller and / or less important weight value.

[0041] As just described above, in various embodiments, a graph component of a computerized tool may electronically generate another graph based on the target domain model. More specifically, in various aspects, the graph component may electronically parse the target domain model via any suitable text parsing technique. Through such parsing, the graph component may identify and / or otherwise discover service domains specified within the target domain model (e.g., within the swagger portion of the target domain model). Furthermore, through such parsing, the graph component may identify and / or otherwise discover service domain interactions specified within the target domain model (e.g., within the transaction / processing flow portion of the target domain model). In particular, for any given service domain interaction specified within the target domain model, the graph component may discover via such parsing which service domains are desired / expected to initiate the given interaction and which service domains are desired / expected to be invoked by the given interaction. Accordingly, in various instances, the graph component constructs and / or otherwise generates a graph such that each node / vertex of the graph represents an identified / detected service domain (e.g., the graph component may generate one new node / vertex per service domain), and / or such that each edge of the graph represents an identified / detected service domain interaction (e.g., the graph component may generate one new edge per service domain interaction). In various instances, such a graph may be referred to as a model graph because it is created based on the target domain model.

[0042] In some cases, the model graph may be unweighted. In other cases, the model graph may be weighted according to any suitable attribute / characteristic of the service domain specified in the target domain model. For example, similar to above, for any given node in the model graph, the given node represents a given service domain, and the attributes of the given node may include: entry point associations with other nodes (e.g., the entry point association attribute may indicate whether the given service domain appears in the interaction trace of another particular service domain); common entry points with other nodes (e.g., the common entry point attribute may indicate whether the given service domain and another particular service domain have the same interaction entry points as each other); inheritance (e.g., the inheritance attribute may indicate whether a business object operated by the given service domain inherits one or more of its characteristics from a business object in another particular service domain and / or leaves one or more of its characteristics to a business object in another particular service domain); and / or business object associations (e.g., the business object association attribute may indicate whether the given service domain and another particular service domain operate the same business objects as each other).

[0043] As a non-limiting example, assume that a target domain model specifies service domain H, service domain I, and service domain J. Also assume that the target domain model specifies a first interaction from service domain H to service domain J and a second interaction from service domain I to service domain J. In such a case, the graph component parses the target domain model, thereby identifying / detecting service domain H, service domain I, service domain J, the first interaction, and the second interaction. In various aspects, the graph component may create a graph based on such parsing. In particular, the graph may include: node H representing program H; node I representing program I; and node J representing program J. Also, because the first interaction is from service domain H to service domain J, the graph may include a first directed edge between node H and node J, where the first directed edge may be a point away from node H toward node J. Similarly, since a second interaction is from service domain I to service domain J, the graph may include a second directed edge between node I and node J, where the second directed edge may point away from node I towards node J. In this manner, the graph component may generate a graph based on the service domains and / or service domain interactions identified / detected by parsing through the target domain model. As mentioned above, such a graph may be referred to as a model graph.

[0044] In various embodiments, a mapping component of a computerized tool may electronically refactor a monolithic application into microservices based on both the code graph and the model graph. More specifically, in various aspects, the mapping component may electronically align nodes of the code graph with nodes of the model graph, thereby resulting in a set of node pairs. In other words, the mapping component may map and / or otherwise correlate nodes of the model graph to corresponding nodes of the code graph (e.g., not necessarily one-to-one). Because nodes of the model graph may represent respective service domains specified by the target domain model, and because nodes of the code graph may represent respective programs written in the source code of the monolithic application, the set of node pairs may be considered to indicate which programs of the monolithic application embody (e.g., are most similar to) which service domains of the target domain model. Also, because each service domain is already known / considered to correspond to at least one microservice, the set of node pairs can therefore be considered to indicate which programs in the monolithic application are to be swapped / replaced by which known microservices. Further non-limiting details follow regarding how the mapping component may generate the set of node pairs.

[0045] In various aspects, the mapping component may electronically store, maintain, control, and / or otherwise access the graph convolutional neural network. In various cases, the graph convolutional neural network may exhibit any suitable architecture. For example, the graph convolutional neural network may include any suitable number of layers (e.g., an input layer, one or more hidden layers, an output layer), any suitable type of layer (e.g., a pooling layer, a batch normalization layer, a convolutional layer with any suitable convolution kernel), any suitable number of neurons in various layers (e.g., different layers may have the same and / or different numbers of neurons), any suitable activation functions (e.g., sigmoid, softmax, hyperbolic tangent, rectified linear unit) in various neurons (e.g., different neurons may have the same and / or different activation functions), and / or any suitable inter-neuron connections (e.g., forward connections, skip connections, recurrent connections).

[0046] In any case, a graph convolutional neural network can be configured to receive a graph as input and generate an embedded representation of the nodes of the input graph as output. In other words, for each given node of the input graph, the graph convolutional neural network generates / outputs a continuous vector having any appropriate dimension, where the continuous vector can represent the given node. That is, the values / magnitudes of the elements of the continuous vector can depend on the attributes and / or edge connectivity (e.g., neighborhood) of the given node. As one skilled in the art will appreciate, the graph convolutional neural network can undergo any appropriate type and / or style of training to learn how to accurately generate an embedded node-wise representation of the input graph. Non-limiting examples of such training can include supervised learning, unsupervised training, and / or reinforcement learning. As one skilled in the art will further appreciate, any appropriate training termination criteria, any appropriate training objective / loss / error function, and / or any appropriate training batch size can be implemented to train the graph convolutional neural network.

[0047] Accordingly, in various aspects, the mapping component executes a graph convolutional neural network on the code graph, which may cause the graph convolutional neural network to generate a set of embedded node-wise representations of the code graph. In particular, the mapping component may provide the code graph to an input layer of the graph convolutional neural network (e.g., each neuron in the input layer may receive a respective node from the code graph), the code graph completes a forward pass through one or more hidden layers of the graph convolutional neural network, and the output layer of the graph convolutional neural network may compute a set of embedded node-wise representations of the code graph based on the activations provided by the one or more hidden layers. In various cases, the set of embedded node-wise representations of the code graph may include one unique continuous vector for each unique node in the code graph. As one skilled in the art will appreciate, the graph convolutional neural network may therefore be considered to import the code graph into an embedding space.

[0048] Similarly, in various cases, the mapping component may run a graph convolutional neural network on the model graph, which may cause the graph convolutional neural network to generate a set of embedded node-wise representations of the model graph. In particular, the mapping component may provide the model graph to an input layer of the graph convolutional neural network (e.g., each neuron in the input layer may receive a respective node from the model graph), the model graph completes a forward pass through one or more hidden layers of the graph convolutional neural network, and the output layer of the graph convolutional neural network may compute a set of embedded node-wise representations of the model graph based on the activations provided by the one or more hidden layers. Just as noted above, in various cases, the set of embedded node-wise representations of the model graph may include one unique continuous vector for each unique node in the model graph. As one skilled in the art will appreciate, the graph convolutional neural network may therefore be viewed as importing the model graph into the same embedding space into which the code graph was imported. Accordingly, in various instances, each embedded node-wise representation of the model graph may be a continuous vector having the same dimension (e.g., the same number of elements) as each embedded node-wise representation of the code graph.

[0049] While the disclosure herein primarily describes various embodiments of the mapping component as generating embedded node-wise representations of the code graph and / or model graph via a graph convolutional neural network, this is merely a non-limiting example for ease of explanation. In various aspects, the mapping component may utilize and / or leverage any other suitable embedded representation learning techniques to create embedded node-wise representations of the code graph and / or model graph.

[0050] In any case, the mapping component may generate a set of node pairs based on the embedded node-wise representation of the code graph and based on the embedded node-wise representation of the model graph. More specifically, the mapping component may iterate through each node in the model graph. For each given node in the model graph, the mapping component may compare the embedded representation of the given node with the embedded representation of the node in the code graph. In various aspects, the mapping component may identify a node from the code graph having an embedded representation that is nearest and / or closest (e.g., in terms of Euclidean distance) to the embedded representation of the given node, and the mapping component may mark and / or otherwise label the identified node from the code graph as mapped to, linked to, correlated with, and / or paired with the given node from the model graph.

[0051] After all, the embedded representation of each node may be based on the edge connectivity (e.g., neighborhood) and / or attributes of that node. Thus, if a first node in the model graph has a similar and / or the same embedded representation (e.g., measured by Euclidean distance) as a second node in the code graph, this may indicate that the two nodes have similar / same edge connectivity and / or attributes. Furthermore, if a first node in the model graph has similar / same edge connectivity and / or attributes as a second node in the code graph, this may mean that the specified behavior of the service domain represented by the first node (e.g., as dictated by the target domain model) may closely match the actual behavior of the program represented by the second node (e.g., as dictated by the source code).

[0052] In any case, by iterating through each node in the model graph and searching for the node in the code graph with the nearest / closest embedded representation, the mapping component may map, link, correlate, and / or pair each node in the model graph with a corresponding node in the code graph, thereby resulting in a set of node pairs.

[0053] As described herein, the mapping component can therefore be thought of as importing both the code graph and the model graph into a common embedding space (e.g., via a graph convolutional neural network), and generating a set of node pairs based on inter-node distances in such common embedding space.

[0054] Although the disclosure herein primarily describes various embodiments of the mapping component as generating a set of node pairs based on a common embedding space technique, this is merely a non-limiting example for ease of explanation. In various aspects, the mapping component may generate the set of node pairs by implementing any other suitable graph alignment technique, such as a subgraph kernel technique. That is, regardless of which graph alignment technique is used by the mapping component, the result may be a set of node pairs.

[0055] In any case, the mapping component generates a set of node pairs, which may be thought of as mapping / linking nodes in the model graph to corresponding nodes in the code graph. Note that in various aspects, such mapping / linking / pairing may be, but need not be, one-to-one. For example, in some cases, there may be one or more nodes in the code graph to which no node in the model graph is mapped / linked / paired. As another example, in other cases, there may be nodes in the code graph to which more than one node from the model graph is mapped / linked / paired.

[0056] In various aspects, as described above, each node in the code graph may represent a respective program written in the source code. Also, as described above, each node in the model graph may represent a respective service domain specified in the target domain model. Accordingly, because the set of node pairs may map / link / correlate nodes in the code graph to nodes in the model graph, the set of node pairs may further be considered to map / link / correlate programs written in the source code to service domains specified by the target domain model. Furthermore, because each service domain is known / considered to correspond to at least one microservice, the set of node pairs may therefore further be considered to map / link / correlate programs written in the source code to known microservices. In other words, the set of node pairs may be considered to indicate how the source code of a monolithic application is refactored into microservices (e.g., to convey which programs written in the source code are replaced / replaced by which known microservices). Accordingly, the set of node pairs may be considered to be results obtained when microservice refactoring is facilitated / executed in a monolithic application.

[0057] In various aspects, the mapping component may calculate a confidence score for each of the set of node pairs. In various instances, for any given node pair, the confidence score may indicate how similar and / or dissimilar the two nodes listed in the given node pair are. In practice, as one skilled in the art will understand, if a first node from the model graph and a second node from the code graph are listed as mapped / linked / correlated to each other in the set of node pairs, this may mean that, of all nodes in the code graph, the second node is closest to (e.g., most similar and / or most dissimilar to) the first node in the model graph. Thus, it may be possible for two nodes to be significantly dissimilar from each other despite being mapped / linked / correlated to each other in the set of node pairs. In various instances, the confidence score may indicate how similar and / or dissimilar such two nodes are.

[0058] In various aspects, for any given node pair, the confidence score for that node pair may be a real-valued scalar whose value / magnitude may be based on the Euclidean distance separating the embedded representations of that node pair. For example, the confidence score may be inversely proportional to the Euclidean distance between the embedded representations of that node pair, such that the value / magnitude of the confidence score may increase as the Euclidean distance separating the embedded representations decreases.

[0059] As another example, for any given node pair, the confidence score for that node pair may be a categorical variable obtained based on a supplemental textual / semantic comparison with the target domain model of the source code. For example, assume that a first node from the model graph is listed in a set of node pairs as being mapped / linked / correlated to a second node from the code graph. Further, assume that the first node represents a particular service domain specified by the target domain model, and the second node represents a particular program written in source code. In various aspects, the mapping component may parse the target domain model in search of keywords associated with that particular service domain (e.g., keywords used in the definition / description of the business capability satisfied by that particular service domain, keywords used in the definition / description of the service domain interaction participated in by that particular service domain). Furthermore, in various instances, the mapping component may parse the source code in search of programs associated with such keywords (e.g., for programs in which method calls and / or coding comments prominently utilize such keywords). If such parsing reveals that programs written inside the source code are not more strongly associated with such keywords than a particular program (e.g., if the auxiliary natural language processing performed by the mapping component agrees that the first node and the second node should be mapped / linked / correlated to each other), the confidence scores of the first node and the second node may be set to the “trusted” category.In contrast, if such parsing instead reveals that some other programs written inside the source code are more strongly associated with such keywords than the particular program (e.g., if the auxiliary natural language processing performed by the mapping component disagrees that the first node and the second node should be mapped / linked / correlated to each other), the confidence scores of the first node and the second node may instead be set to the “unreliable” category.

[0060] In any case, the mapping component may generate a set of node pairs (e.g., refactoring results) by aligning the code graph with the model graph. The mapping component may, in various cases, generate a confidence score for such a set of node pairs.

[0061] In various embodiments, the execution component of the computerized tool electronically transmits electronic messages to any suitable computing device, where the electronic messages may indicate one or more of the sets of node pairs. That is, the execution component may, in some cases, electronically share with any suitable computing device the results obtained when a microservices refactoring is facilitated / executed in the monolithic application. In various other embodiments, the execution component of the computerized tool electronically renders one or more of the sets of node pairs on any suitable computer display, screen, and / or monitor, thereby making the sets of node pairs visible to a user / technician. That is, the execution component may, in various cases, electronically display the results obtained when a microservices refactoring is facilitated / executed in the monolithic application.

[0062] In various embodiments, a feedback component of a computerized tool may electronically access user-provided feedback regarding the sets of node pairs. In particular, in various aspects, the feedback component electronically transmits a request to any suitable computing device, where such request indicates one or more of the sets of node pairs, where such request may prompt a user of the computing device to approve and / or reject such one or more of the sets of node pairs. In various instances, in response to the request, the feedback component receives user-provided feedback from the computing device, where such user-provided feedback may approve and / or reject such one or more of the sets of node pairs. In some cases, in the case of rejected node pairs, the user-provided feedback indicates corrected / updated node pairs that may replace such rejected node pairs, and the feedback component may rewrite the rejected node pairs to become the corrected / updated node pairs accordingly. In some cases, the feedback component may subject all sets of node pairs to user review in this manner (e.g., may prompt the user for feedback regarding each of the sets of node pairs). In other cases, the feedback component may subject a less than all set of node pairs to the user's review in this manner (e.g., may avoid prompting the user for feedback on one or more node pairs). For example, in some cases, the feedback component may prompt the user for feedback on only those node pairs that exhibit insufficient confidence (e.g., only those node pairs whose category confidence score is set to the "unreliable" category and / or only those node pairs whose real-valued scalar confidence score fails to meet any suitable threshold level).

[0063] In various embodiments, a gap component of the computerized tool may electronically identify one or more gaps between the code graph and the model graph via any suitable natural language processing technique and based on the set of node pairs. For example, for any two nodes listed as mapped / linked / correlated in the set of node pairs, one of such two nodes may represent a particular service domain specified by the target domain model, and the other of such two nodes may represent a particular program written in source code. In various cases, the gap component may utilize string search to determine whether a gap exists between the business capabilities of the particular service domain and the unexposed method calls of the particular program. As a non-limiting example, the gap component may identify business capabilities to be satisfied / provided by the particular service domain via any suitable parsing technique. For each identified business capability, the gap component may parse through the particular program in search of at least one unexposed method call that matches and / or satisfies the identified business capability (e.g., contains the same keywords included in the description of the identified business capability). If the gap component fails to find at least one unexposed method call to any such identified business capabilities, the gap component may conclude that a gap exists between the business capabilities of the particular service domain and the unexposed method calls of the particular program, and the gap component may therefore record and / or log the gap. As another non-limiting example, the gap component may identify service domain interactions to be initiated by that particular service domain via any suitable parsing technique.For each identified service domain interaction, the gap component may parse through the particular program in search of at least one program exposure method call that matches and / or satisfies the identified service domain interaction (e.g., contains the same keywords included in the description of the identified service domain interaction). If the gap component fails to find at least one program exposure method call for any such identified service domain interactions, the gap component may conclude that a gap exists between the service domain interactions of the particular service domain and the program exposure method calls of the particular program, and the gap component may therefore record and / or log the gap.

[0064] In any case, the gapping component may utilize natural language processing (e.g., string search) to identify / detect gaps between the model graph and the code graph. In various embodiments, the execution component may address such gaps electronically. In some cases, the execution component may address such gaps by generating and / or transmitting an electronic alert to any suitable computing device, where such electronic alert may indicate the existence of such gaps and / or where such electronic alert may indicate that such gaps require attention / repair. In other cases, the execution component may address such gaps by inserting one or more coding templates into the source code that address and / or fill such gaps (e.g., if the source code is missing an unexposed method call that corresponds to a particular business capability, then the execution component may insert a pre-written unexposed method call template that implements such business capability into the source code).

[0065] Accordingly, various embodiments described herein may be considered computerized tools that may facilitate monolith-to-microservices refactoring based on a graph comparison of source code to a domain model.

[0066] Various embodiments described herein may be utilized to use hardware and / or software to solve problems of a highly technical nature that are not abstract and cannot be performed as a set of mental activities by a human (e.g., to facilitate monolith-to-microservices refactoring based on a graph comparison of source code to a domain model). Additionally, some of the processes performed may be performed by a special-purpose computer (e.g., a source code parser, a target domain model parser, a graph convolutional neural network). In various aspects, some defined tasks associated with various embodiments described herein may include: accessing, by a device operatively coupled to a processor, source code of a monolithic application and a target domain model corresponding to the monolithic application; and / or refactoring, by the device, the monolithic application into microservices by aligning, by the device, a first graph representing the source code with a second graph representing the target domain model.

[0067] Such a defined task cannot be performed by the human mind without a computer. In fact, neither the human mind nor a person using pen and paper can electronically access the source code and / or target domain model of a monolithic application, electronically generate graphs (e.g., data structures with nodes / vertices and edges) to represent the source code and the target domain model, respectively, and electronically refactor the monolithic application by aligning the two graphs with each other (e.g., via co-embedding space techniques such as graph convolutional neural networks). Instead, such a defined task is intrinsically and intimately tied to computer technology and cannot be implemented outside of a computing environment (e.g., a monolithic application is an executable set of programs, where each program is a set of coding commands that are compiled and / or executed; thus, a monolithic application is an inherently computerized construct that cannot exist in the human mind or simply on paper; correspondingly, computer-implemented tools that can refactor a monolithic application into microservices are likewise inherently computerized constructs that cannot exist in any reasonable, practical, or practicable way without a computer).

[0068] In various instances, one or more embodiments described herein may integrate the teachings described herein into practical applications. As mentioned above, some techniques for facilitating monolith-to-microservices refactoring may be bottom-up techniques. Such bottom-up techniques fail to consider external microservice information, which may cause such bottom-up techniques to produce refactoring results that are not reliable enough. As also mentioned above, other techniques for facilitating monolith-to-microservices refactoring may be top-down techniques. While top-down techniques may implement a target domain model to consider external microservices information, such top-down techniques may be a fully manual process that consumes months' worth of time. In stark contrast, embodiments described herein may include monolith-to-microservices refactoring achieved through the alignment of a graph representing the monolithic source code to another graph representing the target domain model. More specifically, such alignment may be facilitated by importing both graphs into a common embedding space (e.g., via a graph convolutional neural network) and then pairing / mapping / linking nodes between the two graphs based on Euclidean distance. Because such embodiments may make use of the target domain model, they may avoid pitfalls experienced by bottom-up techniques. Also, because the embedding-based graph alignment is automated / computer-implemented, such embodiments may consume less time compared to top-down techniques. Thus, various embodiments described herein may be considered concrete, tangible technical improvements in the field of microservice refactoring. Furthermore, as explained above, microservice refactoring may be considered a useful and practical end in itself.After all, monolithic applications, due to their enormous size and tight internal coupling, often fail to exhibit the benefits of cloud-native applications (e.g., scalability, continuous deployment, stateless deployment, agility, ease of troubleshooting), which can be addressed through performance microservices refactoring. Therefore, in any case, the various embodiments described herein certainly constitute useful and practical applications of computers.

[0069] It should be understood that the drawings and disclosure herein illustrate non-limiting examples of various embodiments. It should be further understood that the drawings are not necessarily drawn to scale.

[0070] 1 illustrates a block diagram of an exemplary, non-limiting system 100 that can facilitate monolith-to-microservices refactoring via a graph comparison of source code to a domain model, in accordance with one or more embodiments described herein. As shown, a monolith-to-microservices refactoring system 102 (e.g., hereinafter "refactoring system 102") can be electronically integrated with the source code 106 of a monolithic application 104 and / or with a target domain model 108 associated with the monolithic application 104 via any suitable wired and / or wireless electronic connection.

[0071] In various aspects, monolithic application 104 may be any suitable monolithic application. In various instances, source code 106, written in any suitable coding language and / or using any suitable coding syntax, may include computer-executable instructions and / or coding commands that make up monolithic application 104. This is shown in more detail with respect to FIG. 2.

[0072] 2 illustrates an exemplary, non-limiting block diagram 200 of source code 106 in accordance with one or more embodiments described herein. As shown, source code 106 may include a set of programs 202. In various aspects, set of programs 202 may include n programs, i.e., Program 1 through Program n, for any suitable positive integer n. In various cases, the programs of source code 106 may be sequences of computer-executable commands that may perform any suitable number of non-exposed method calls on any suitable number of data objects and / or any suitable number of program-exposed method calls. In various cases, the data objects may be one or more scalars, one or more vectors, one or more matrices, one or more tensors, and / or one or more strings, and the non-exposed method calls may be any suitable functions, operations, calculations, and / or transformations that are performed on data objects and that may be self-contained (e.g., may be performed without interacting with and / or invoking another program). In contrast, a program-exposing method call may be any suitable invocation, activation, and / or initiation of another program written within source code 106. As a non-limiting example, program 1 executes any of set 1 of non-exposed method calls on any of set 1 of data objects, where set 1 of non-exposed method calls may include any suitable number of non-exposed method calls of any suitable type, and set 1 of data objects may include any suitable number of data objects of any suitable type. Also, as shown, program 1 executes any of set 1 of program-exposed method calls, each of which may invoke / activate any of n-1 other programs written in source code 106.As another non-limiting example, program n executes any of set n of non-exposed method calls on any of set n of data objects, where set n of non-exposed method calls may include any suitable number of non-exposed method calls of any suitable type, and set n of data objects may include any suitable number of data objects of any suitable type. Further, as shown, program n executes any of set n of program-exposed method calls, each of which may launch / activate any of n-1 other programs written in source code 106.

[0073] For purposes of example / explanation, assume that there are a total of p program exposed method calls written within source code 106 for any suitable positive integer p.

[0074] In various aspects, the target domain model 108 may be any suitable electronic document (e.g., natural language text) that may specify, describe, and / or otherwise define the functionality and / or transaction structure expected to be provided by the monolithic application 104. This is shown in more detail with respect to FIG.

[0075] FIG. 3 illustrates an example, non-limiting block diagram 300 of a target domain model 108 in accordance with one or more embodiments described herein. As shown, the target domain model 108 may include a set of service domains 302. In various aspects, the set of service domains 302 may include m service domains, for any suitable positive integer m, i.e., Service Domain 1 through Service Domain m. In some cases, m may equal n. In other cases, m may not equal n. In various instances, a service domain may be a description and / or specification of a cohesive cluster of business logic desired, expected, and / or otherwise envisioned to perform a set of business capabilities on a set of business objects. In various cases, a business object may be a description / specification of any suitable electronic data, and a business capability may be a description / specification of any suitable function, operation, calculation, and / or transformation performed on a business object. Accordingly, in various instances, a business capability may be considered a natural language analog to and / or description of an unexposed method invocation, and a business object may be considered a natural language analog to and / or description of a data object. As a non-limiting example, as shown, service domain 1 is expected to perform any of set 1 of business capabilities on any of set 1 of business objects, where set 1 of business capabilities may include any suitable number of business capabilities of any suitable type, and where set 1 of business objects may include any suitable number of business objects of any suitable type. Similarly, as shown, service domain m is expected to perform any of set m of business capabilities on any of set m of business objects, where set m of business capabilities may include any suitable number of business capabilities of any suitable type, and where set m of business objects may include any suitable number of business objects of any suitable type.

[0076] As further shown, the target domain model 108 may include a set of service domain interactions 304. In various aspects, the set of service domain interactions 304 may be a description / designation of which service domains in the target domain model 108 are expected to invoke (e.g., launch, activate, and / or initiate) which other service domains in the target domain model 108. Accordingly, in various cases, the service domain interactions may be considered as a natural language analog to and / or description of programmatically exposed method calls.

[0077] 3, the set of service domains 302 may be specified / described in the swagger definition portion of the target domain model 108, while the set of service domain interactions 304 may be specified / described in the transaction / processing flow portion of the target domain model 108. As one skilled in the art will appreciate, some non-limiting example embodiments of the target domain model 108 may be BIAN and / or eTOM specifications.

[0078] For purposes of illustration / description, assume that for any suitable positive integer q, there are a total of q service domain interactions specified by the target domain model 108. In some cases, q may be equal to p. In other cases, q may not be equal to p.

[0079] Although not explicitly shown in FIG. 3 , each of the set of service domains 302 may be known and / or otherwise considered to correspond to a respective microservice. For example, there may be a particular microservice known to facilitate and / or perform business capability set 1. Accordingly, that particular microservice may be considered to correspond to and / or otherwise fulfill service domain 1. As another example, there may be a particular microservice known to facilitate / perform business capability set m. Thus, that particular microservice may be considered to correspond to and / or otherwise fulfill service domain m. Thus, each service domain specified in the target domain model 108 may be known / considered to be associated with a microservice.

[0080] 1, it may be desirable to refactor a monolithic application 104 into microservices. As described herein, a refactoring system 102 may automatically facilitate such refactoring by leveraging both source code 106 and a target domain model 108.

[0081] In various embodiments, refactoring system 102 may include a processor 110 (e.g., a computer processing unit, a microprocessor) and non-transitory computer-readable memory 112 operatively connected and / or coupled to processor 110. Memory 112 may store computer-executable instructions that, when executed by processor 110, may cause processor 110 and / or other components of refactoring system 102 (e.g., access component 114, graph component 116, mapping component 118, feedback component 120, gap component 122, execution component 124) to perform one or more operations. In various embodiments, memory 112 may store, and processor 110 may execute, the computer-executable components (e.g., access component 114, graph component 116, mapping component 118, feedback component 120, gap component 122, execution component 124).

[0082] In various embodiments, refactoring system 102 may include an access component 114. In various aspects, access component 114 may electronically receive and / or otherwise electronically access source code 106 and / or target domain model 108. In various cases, access component 114 may electronically search for and / or retrieve source code 106 and / or target domain model 108 from any suitable centralized and / or decentralized data structure, whether remote from and / or local to access component 114. In any case, access component 114 electronically accesses source code 106 and / or target domain model 108 so that other components of refactoring system 102 may electronically interact with source code 106 and / or target domain model 108.

[0083] In various embodiments, the refactoring system 102 may further include a graph component 116. In various aspects, the graph component 116 may generate a code graph based on the source code 106 and / or may generate a model graph based on the target domain model 108, as described herein.

[0084] In various embodiments, the refactoring system 102 may further include a mapping component 118. In various instances, as described herein, the mapping component may align a code graph with a model graph, thereby resulting in a set of node pairs. In various cases, the set of node pairs may be considered to indicate which programs in the source code 106 are correlated with which service domains in the target domain model 108. Because each service domain is known / considered to correspond to a microservice, the set of node pairs may therefore be considered to correlate the microservice with the program in the source code 106.

[0085] In various embodiments, refactoring system 102 may further include a feedback component 120. In various aspects, as described herein, feedback component 120 may prompt and / or access feedback provided by a user to confirm and / or reject any of the sets of node pairs.

[0086] In various embodiments, refactoring system 102 may further include a gap component 122. In various instances, as described herein, gap component 122 may detect one or more gaps (e.g., one or more inconsistencies) between the code graph and the model graph through natural language processing and based on a set of node pairs.

[0087] In various embodiments, refactoring system 102 may further include execution component 124. In various cases, execution component 124 may transmit to any suitable computing device and / or render any of the sets of node pairs on any suitable computer display, as described herein. In various other cases, execution component 124 may insert one or more coding templates into source code 106 to plug and / or fill one or more gaps identified by gap component 122, as described herein.

[0088] 4 illustrates a block diagram of an exemplary, non-limiting system 400 including a code graph and / or a model graph that can facilitate monolith-to-microservices refactoring via graph comparison of source code to a domain model, in accordance with one or more embodiments described herein. As shown, system 400 may, in some cases, include the same components as system 100 and may further include a code graph 402 and / or a model graph 404.

[0089] In various embodiments, the graph component 116 may electronically generate the code graph 402 based on the source code 106. More specifically, the graph component 116 may electronically parse the source code 106. In some cases, such parsing may be static. That is, such parsing may occur before runtime of the source code 106 and / or without otherwise executing / performing the source code 106. In other cases, such parsing may be dynamic. That is, such parsing may occur during and / or after runtime / execution of the source code 106. In still other cases, such parsing may be both static and dynamic. In any case, by parsing through the source code 106, the graph component 116 may identify the set of programs 202, identify each unexposed method call that each of the set of programs 202 is configured to execute, identify each data object that each of the set of programs 202 is configured to manipulate / consider, and / or identify each exposed program method call that each of the set of programs 202 is configured to execute. In various aspects, graph component 116 may generate code graph 402 based on such identification. As a non-limiting example, each node of code graph 402 may represent a respective one of set 202 of programs written in source code 106, and each edge of code graph 402 may represent a respective program-exposed method call written within source code 106.

[0090] Similarly, in various embodiments, the graph component 116 may electronically generate the model graph 404 based on the target domain model 108. In particular, the graph component 116 may electronically parse the target domain model 108. As noted above, such parsing may be static in some cases, dynamic in other cases, and / or both static and dynamic in still other cases. In any case, by parsing through the target domain model 108, the graph component 116 may identify a set of service domains 302, each business capability specified / defined for each of the set of service domains 302, each business object specified / defined for each of the set of service domains 302, and / or each set of service domain interactions 304. In various aspects, the graph component 116 may generate the model graph 404 based on such identification. As a non-limiting example, each node of the model graph 404 may represent one of the set of service domains 302 specified by the target domain model 108, and each edge of the model graph 404 may represent one of the set of service domain interactions 304 specified by the target domain model 108.

[0091] This is further explained with respect to FIGS.

[0092] First, consider FIG. 5. As shown, FIG. 5 illustrates a non-limiting block diagram 500 showing additional exemplary details of code graph 402 and / or model graph 404. In various aspects, as shown, code graph 402 may include a set of code graph nodes 502 and / or a set of code graph edges 504. In various instances, as described above, code graph 402 may include one unique node for each unique program written within source code 106. Accordingly, because there may be n programs in source code 106, there may be n nodes in set of code graph nodes 502: code graph node 1, which may represent program 1, through code graph node n, which may represent program n. In various instances, as also mentioned above, code graph 402 may include one unique edge for each unique program-exposed method call written within source code 106. Therefore, since there may be p program exposed method calls in source code 106, there may be p edges in set 504 of code graph edges, namely: code graph edge 1, which may represent the first program exposed method call written in source code 106, to code graph edge p, which may represent the pth program exposed method call written in source code 106.

[0093] Similarly, in various aspects, model graph 404 may include a set of model graph nodes 506 and / or a set of model graph edges 508. In various instances, as described above, model graph 404 may include one unique node for each unique service domain specified within target domain model 108. Accordingly, because there may be m service domains in target domain model 108, there may be m nodes in set of model graph nodes 506, namely, model graph node 1, which may represent service domain 1, through model graph node m, which may represent service domain m. In various instances, as also mentioned above, model graph 404 may include one unique edge for each unique service domain interaction specified within target domain model 108. Accordingly, because there may be q service domain interactions in target domain model 108, there may be q edges in set of model graph edges 508, namely, model graph edge 1, which may represent the first service domain interaction specified in target domain model 108, through model graph edge q, which may represent the qth service domain interaction specified in target domain model 108.

[0094] Consider now Figure 6, which illustrates an exemplary, non-limiting diagram 600 of a code graph 402. For purposes of explanation, assume that source code 106 includes seven programs: program 602, program 604, program 606, program 608, program 610, program 612, and program 614. Further, assume that source code 106 includes seven program expose method calls: expose program method call 616 from program 602 to program 604, expose program method call 618 from program 602 to program 606, expose program method call 620 from program 602 to program 608, expose program method call 622 from program 604 to program 610, expose program method call 624 from program 606 to program 612, expose program method call 626 from program 608 to program 606, and expose program method call 628 from program 608 to program 614. In such a case, as shown, code graph 402 may include: a node representing program 602, a node representing program 604, a node representing program 606, a node representing program 608, a node representing program 610, a node representing program 612, and a node representing program 614. Furthermore, in such a case and as shown, code graph 402 may include: a directed edge pointing from the node representing program 602 to the node representing program 604, a directed edge pointing from the node representing program 602 to the node representing program 606, a directed edge pointing from the node representing program 602 to the node representing program 608, a directed edge pointing from the node representing program 604 to the node representing program 610, a directed edge pointing from the node representing program 606 to the node representing program 612, a directed edge pointing from the node representing program 608 to the node representing program 606, and a directed edge pointing from the node representing program 608 to the node representing program 614.In this manner, the graph component 116 may construct the code graph 402 by parsing the source code 106 and identifying the programs and program-exposed method calls written in the source code 106 .

[0095] Now consider Figure 7, which illustrates an exemplary, non-limiting diagram 700 of a model graph 404. For purposes of explanation, assume that the target domain model 108 includes six service domains: service domain 702, service domain 704, service domain 706, service domain 708, service domain 710, and service domain 712. Further assume that target domain model 108 includes seven service domain interactions: service domain interaction 714 from service domain 702 to service domain 704, service domain interaction 716 from service domain 702 to service domain 706, service domain interaction 718 from service domain 702 to service domain 708, service domain interaction 720 from service domain 704 to service domain 710, service domain interaction 722 from service domain 706 to service domain 712, service domain interaction 724 from service domain 706 to service domain 708, and service domain interaction 726 from service domain 710 to service domain 712. In such a case, as shown, model graph 404 may include: a node representing service domain 702, a node representing service domain 704, a node representing service domain 706, a node representing service domain 708, a node representing service domain 710, and a node representing service domain 712.Further, in such a case, as shown, model graph 404 may include: a directed edge pointing from a node representing service domain 702 to a node representing service domain 704, a directed edge pointing from a node representing service domain 702 to a node representing service domain 706, a directed edge pointing from a node representing service domain 702 to a node representing service domain 708, a directed edge pointing from a node representing service domain 704 to a node representing service domain 710, a directed edge pointing from a node representing service domain 706 to a node representing service domain 712, a directed edge pointing from a node representing service domain 706 to a node representing service domain 708, and a directed edge pointing from a node representing service domain 710 to a node representing service domain 712. In this manner, graph component 116 may construct model graph 404 by parsing target domain model 108 and identifying the service domains and service domain interactions specified in target domain model 108.

[0096] Although not explicitly shown in the figure, the nodes and / or edges in code graph 402 may be unweighted in some cases and / or weighted according to program attributes / characteristics in other cases. As some non-limiting examples, node attributes of code graph 402 may include: an entry point association attribute (e.g., for any given programs i and j in source code 106, this attribute may indicate whether program j acts as an entry point for program i); a common entry point attribute (e.g., for any given programs i and j in source code 106, this attribute may indicate whether programs i and j have the same entry point as each other); an inheritance attribute (e.g., for any given programs i and j in source code 106, this attribute may indicate whether an inheritance relationship exists between programs i and j); and / or a data object attribute (e.g., for any given programs i and j in source code 106, this attribute may indicate whether programs i and j operate on the same data object as each other). Similarly, although not explicitly shown in the figures, the nodes and / or edges in the model graph 404 may be unweighted in some cases and / or weighted according to service domain attributes / characteristics in other cases.As some non-limiting examples, node attributes of the model graph 404 may include: an entry point association attribute (e.g., for any given service domains i and j in the target domain model 108, this attribute may indicate whether service domain j acts as an entry point for service domain i); a common entry point attribute (e.g., for any given service domains i and j in the target domain model 108, this attribute may indicate whether service domains i and j have the same entry point as each other); an inheritance attribute (e.g., for any given service domains i and j in the target domain model 108, this attribute may indicate whether an inheritance relationship exists between service domains i and j); and / or a business object attribute (e.g., for any given service domains i and j in the target domain model 108, this attribute may indicate whether service domains i and j operate on the same business object as each other).

[0097] Also, in various aspects, the graph component 116 may dynamically parse the source code 106, as described above. More specifically, the graph component 116 may analyze the source code 106 during runtime of the source code 106, thereby resulting in different execution traces and / or production logs of the source code 106. In various instances, such different execution traces and / or production logs may indicate different sequences of program-to-program interactions implementable by the source code 106 (e.g., may indicate different orders in which the source code 106 may execute the set of programs 202 in different contexts). In some cases, such different sequences of program-to-program interactions may be referred to as different program transactions. In any case, the edge weights of the code graph 402 may be based on such different sequences of program-to-program interactions. For example, some program-exposed method calls may be present in a greater proportion of such different sequences of program-to-program interactions. Accordingly, edges in the code graph 402 representing such program-exposed method calls that are executed more frequently may have a heavier weight. On the other hand, some program-exposed method calls may be present in a smaller percentage of such different sequences of program-program interactions, and therefore edges in code graph 402 representing such less frequently executed program-exposed method calls may have a lighter weight.

[0098] 8 illustrates a block diagram of an exemplary, non-limiting system 800 including a set of node pairs that can facilitate monolith-to-microservices refactoring via graph comparison of source code to domain model, in accordance with one or more embodiments described herein. As shown, system 800 may include the same components as system 400 in some cases and may further include set of node pairs 802.

[0099] In various embodiments, mapping component 118 may electronically generate set of node pairs 802 based on code graph 402 and model graph 404. More specifically, mapping component 118 aligns code graph 402 with model graph 404 to identify which nodes in code graph 402 are most similar to which nodes in model graph 404, and the result of such alignment may be set of node pairs 802. In some instances, mapping component 118 may facilitate such alignment by implementing a common embedding space technique, which is described in more detail with respect to Figures 9-12.

[0100] First, consider FIG. 9 , which illustrates an exemplary, non-limiting block diagram 900 showing how a code graph 402 is imported into an embedding space. In various embodiments, the mapping component 118 may electronically store, maintain, control, and / or otherwise access a graph convolutional neural network 902 (e.g., hereinafter “GCN 902”). In various aspects, the GCN 902 may exhibit any suitable internal architecture. That is, the GCN 902 may include any suitable number and / or type of layers, any suitable number of neurons in various layers, any suitable activation functions in the various neurons, and / or any suitable inter-neuron connections. In any case, the GCN 902 may be configured to receive a graph as input and to generate an embedded node-wise representation of the input graph as output. As one skilled in the art will appreciate, the embedding representation of a graph node may be a vector having any suitable dimension (e.g., any suitable number of elements), whereby the values / magnitudes of the elements of that vector may depend on the attributes, properties, and / or edges of that graph node. As one skilled in the art will further appreciate, GCN 902 may learn to generate accurate embedded node-wise representations by undergoing any suitable type / paradigm of training (e.g., supervised learning, unsupervised training, reinforcement learning), with any suitable training batch size, any suitable objective function, and / or any suitable training termination criteria.

[0101] Accordingly, in various aspects, mapping component 118 executes GCN 902 on code graph 402, and the result may be a set of embedded node-wise representations 904. More specifically, an input layer of GCN 902 may receive code graph 402, which completes a forward pass through one or more hidden layers of GCN 902, and an output layer of GCN 902 may compute set of embedded node-wise representations 904 based on the activations produced by the one or more hidden layers. In various instances, as shown, set of embedded node-wise representations 904 may each correspond to set of code graph nodes 502. That is, because set of code graph nodes 502 may include n nodes, set of embedded node-wise representations 904 may include n embeddings, namely: an embedded representation of code graph node 1 through an embedded representation of code graph node n. As mentioned above, the embedded representation of code graph node 1 may be a real-valued vector having any suitable dimension, where elements of such a vector may depend on attributes, characteristics, and / or edges of code graph node 1. Similarly, the embedded representation of a code graph node n may be a real-valued vector having any suitable dimension, where the elements of such a vector may depend on the attributes, properties, and / or edges of the code graph node n. In various cases, each of the sets of embedded node-wise representations 904 may have the same dimension as each other.

[0102] Consider now FIG. 10 , which illustrates an exemplary, non-limiting block diagram 1000 showing how the model graph 404 is imported into the same embedding space as the code graph 402. In various embodiments, as shown, the mapping component 118 runs the GCN 902 on the model graph 404, and the result may be a set of embedded node-wise representations 1002. More specifically, the input layer of the GCN 902 receives the model graph 404, the model graph 404 completes a forward pass through one or more hidden layers of the GCN 902, and the output layer of the GCN 902 computes the set of embedded node-wise representations 1002 based on the activations produced by the one or more hidden layers. In various instances, as shown, the sets of embedded node-wise representations 1002 may each correspond to a set of model graph nodes 506. That is, because the set of model graph nodes 506 may include m nodes, the set of embedded node-wise representations 1002 may include m embeddings, i.e., the embedded representation of model graph node 1 through the embedded representation of model graph node m. Just as noted above, the embedded representation of model graph node 1 may be a real-valued vector having any suitable dimensionality, where elements of such vector may depend on attributes, properties, and / or edges of model graph node 1. Similarly, the embedded representation of model graph node m may be a real-valued vector having any suitable dimensionality, where elements of such vector may depend on attributes, properties, and / or edges of model graph node m. In various cases, each of the sets of embedded node-wise representations 1002 may have the same dimensionality as each other.

[0103] Because both the set of embedded node-wise representations 904 and the set of embedded node-wise representations 1002 are generated by the GCN 902, each of the set of embedded node-wise representations 1002 has the same dimensions as each of the set of embedded node-wise representations 904, so that vector operations can be performed between the set of embedded node-wise representations 904 and the set of embedded node-wise representations 1002. In other words, the GCN 902 can be thought of as importing the code graph 402 and the model graph 404 into a common embedding space, so that the embedded representation of the code graph 402 can be compared to the embedded representation of the model graph 404. In further words, given a node from the model graph 404 and another node from the code graph 402, the embedded representations of the two nodes may be similar if the two nodes have similar attributes, properties, and / or edges, and the embedded representations of the two nodes may be dissimilar if the two nodes have dissimilar attributes, properties, and / or edges.

[0104] Although the disclosure herein primarily describes an embodiment in which mapping component 118 generates set of embedded node-wise representations 904 and / or set of embedded node-wise representations 1002 via GCN 902, this is merely a non-limiting example for ease of illustration. In various aspects, mapping component 118 may implement any other suitable embedding representation learning technique to generate set of embedded node-wise representations 904 and / or set of embedded node-wise representations 1002.

[0105] Now consider FIG. 11, which illustrates an exemplary, non-limiting block diagram 1100 showing how the set of node pairs 802 is generated based on the set of embedded node-wise representations 904 and / or the set of embedded node-wise representations 1002.

[0106] In various embodiments, as shown, mapping component 118 may generate set of node pairs 802 by analyzing Euclidean distances separating various ones of set of embedded node-wise representations 1002 from various ones of set of embedded node-wise representations 904. More specifically, mapping component 118 may iterate through each node in model graph 404 (e.g., may iterate through each of set of model graph nodes 506). For each particular node in model graph 404, mapping component 118 may identify a node in code graph 402 (e.g., may identify one of set of code graph nodes 502) such that the embedded representation of the identified node from code graph 402 is closest and / or nearest in terms of Euclidean distance to the embedded representation of the particular node from model graph 404. Accordingly, mapping component 118 may mark and / or record in node pair set 802 that such particular node from model graph 404 is mapped, linked, and / or otherwise correlated with the identified node from code graph 402. This may cause node pair set 802 to have a total of m node pairs: node pair 1 to node pair m (e.g., one node pair per model graph node).

[0107] For example, mapping component 118 may identify whichever node in code graph 402 has a nearest / closest embedded representation to the embedded representation of model graph node 1, and such identified node may be referred to as mapped code graph node 1 (note that such identified node is not necessarily the code graph node 1 shown in FIG. 5 ). In various instances, mapping component 118 may therefore create node pair 1 in node pair set 802, where node pair 1 may be any suitable electronic record indicating that model graph node 1 is linked / correlated to mapped code graph node 1.

[0108] As another example, mapping component 118 may identify whichever node in code graph 402 has a nearest / closest embedded representation to the embedded representation of model graph node m, and such identified node may be referred to as mapped code graph node m (note that such identified node is not necessarily the code graph node m shown in FIG. 5). In various cases, just as above, mapping component 118 may therefore create a node pair m in node pair set 802, where node pair m may be any suitable electronic record indicating that model graph node m is linked / correlated to mapped code graph node m.

[0109] While the disclosure herein primarily describes various embodiments in which mapping component 118 generates set of node pairs 802 via a common embedding space technique (e.g., via GCN 902), this is merely a non-limiting example for ease of explanation. In various instances, mapping component 118 may generate set of node pairs 802 by utilizing any other suitable graph alignment technique, such as a subgraph kernel technique.

[0110] In any case, because the set of node pairs 802 may map / link / correlate nodes of the code graph 402 to nodes of the model graph 404, because the nodes of the code graph 402 may represent programs written within the source code 106, and because the nodes of the model graph 404 may represent service domains specified by the target domain model 108, the set of node pairs 802 may therefore be considered to map / link / correlate programs written in the source code 106 to service domains specified by the target domain model 108. Also, because each service domain specified in the target domain model 108 is known / considered to correspond to a microservice, the set of node pairs 802 may therefore be considered to indicate which programs written in the source code 106 correspond to (e.g., perform the same function as and therefore can be replaced and / or replaced by) which known microservices.

[0111] As a non-limiting example, node pair 1 may indicate that model graph node 1 is linked / correlated to mapped code graph node 1. This may be considered to indicate / communicate that service domain 1 (and thus the microservice known / believed to correspond to service domain 1) is linked / correlated to the program represented by mapped code graph node 1. Similarly, as another non-limiting example, node pair m may indicate that model graph node m is linked / correlated to mapped code graph node m. This may be considered to indicate / communicate that service domain m (and thus the microservice known / believed to correspond to service domain m) is linked / correlated to the program represented by mapped code graph node m.

[0112] In any case, the set of node pairs 802 can be viewed as indicating which programs in the source code 106 correspond to which known microservices. Thus, the set of node pairs 802 can be viewed as indicating how the monolithic application 104 is refactored into microservices. That is, the set of node pairs 802 can be viewed as the results obtained when a microservice refactoring is performed / promoted on the monolithic application 104.

[0113] Note that in various cases, the set of node pairs 802 may, but need not, be a one-to-one mapping between nodes in the model graph 404 and nodes in the code graph 402. For example, it may be the case that a node in the code graph 402 is not mapped / linked / correlated to any node in the model graph 404 (e.g., in such a case, the program represented by that node may be considered to not satisfy / embody any of the service domains specified in the target domain model 108). As another example, it may be the case that a node in the code graph 402 is not mapped / linked / correlated to more than one node from the model graph 404 (e.g., in such a case, the program represented by that node may be considered to satisfy / embody more than one of the service domains specified in the target domain model 108).

[0114] In various embodiments, the mapping component 118 may generate a confidence score for each of the sets of node pairs 802. This is described more fully with respect to Figure 12. As shown, Figure 12 illustrates an exemplary, non-limiting block diagram 1200 showing how confidence scores are generated for the sets of node pairs 802.

[0115] In various aspects, the mapping component 118 may generate a confidence score 1 for node pair 1. In some cases, the confidence score 1 may be a real-valued scalar whose magnitude may indicate how similar and / or dissimilar the model graph node 1 is to the mapped code graph node 1. Indeed, in such cases, the mapping component 118 may determine the Euclidean distance separating the embedded representation of the model graph node 1 from the embedded representation of the mapped code graph node 1, and the confidence score 1 may be inversely proportional to that Euclidean distance. In other cases, the confidence score 1 may be a categorical variable generated based on ancillary textual / semantic analysis of the source code 106 and / or the target domain model 108. For example, in such cases, the mapping component 118 may parse the target domain model 108 in search of keywords associated with the service domain represented by the model graph node 1, and the mapping component 118 may parse the source code 106 in search of programs whose comments and / or method calls utilize such keywords. If such a parse identifies a program represented by the mapped code graph node 1, then confidence score 1 may be set to a "confident" state. On the other hand, if such a parse identifies a program other than that represented by the mapped code graph node 1, then confidence score 1 may be set to an "unconfident" state.

[0116] Similarly, the mapping component 118 may generate a confidence score m for node pair m. In some cases, the confidence score m may be a real-valued scalar whose magnitude may indicate how similar and / or dissimilar the model graph node m is to the mapped code graph node m. Indeed, in such cases, the mapping component 118 may determine the Euclidean distance separating the embedded representation of the model graph node m from the embedded representation of the mapped code graph node m, and the confidence score m may be inversely proportional to that Euclidean distance. In other cases, the confidence score m may be a categorical variable generated based on auxiliary textual / semantic analysis of the source code 106 and / or the target domain model 108. Just as noted above, in such cases, the mapping component 118 may parse the target domain model 108 in search of keywords associated with the service domain represented by the model graph node m, and the mapping component 118 may parse the source code 106 in search of programs whose comments and / or method calls utilize such keywords. If such a parse identifies a program represented by the mapped code graph node m, then the confidence score m may be set to a "trusted" state. On the other hand, if such a parse identifies a program other than that represented by the mapped code graph node m, then the confidence score m may be set to an "untrusted" state.

[0117] 13 illustrates a block diagram of an exemplary, non-limiting system 1300 including feedback that can facilitate monolith-to-microservices refactoring via graph comparison of source code to domain model, in accordance with one or more embodiments described herein. As shown, system 1300 may include the same components as system 800 in some cases and may further include feedback 1302.

[0118] In various embodiments, feedback component 120 transmits set of node pairs 802 to any suitable computing device (not shown), and feedback component 120 may prompt a user of the computing device to approve and / or reject any of set of node pairs 802. In response to such prompting, feedback component 120 may electronically receive, obtain, and / or otherwise access feedback 1302 from such computing device. In various aspects, feedback 1302 may be any suitable electronic data approving and / or rejecting any of set of node pairs 802. In some cases, for any rejected node pairs, feedback 1302 may indicate an updated and / or otherwise corrected node pair. In such cases, feedback component 120 may replace the rejected node pair in set of node pairs 802 with the updated / corrected node pair. In some cases, feedback component 120 may prompt a user for feedback in this manner for all sets of node pairs 802. In other cases, the feedback component 120 may prompt user feedback in this manner for less than all of the set of node pairs 802 (e.g., may request feedback only for those node pairs whose scalar confidence scores fail to meet a threshold level and / or whose categorical confidence scores are set to an "unreliable" state).

[0119] 14 illustrates a block diagram of an exemplary, non-limiting system 1400 including a set of gaps that can facilitate monolith-to-microservices refactoring via a graph comparison of source code to a domain model, in accordance with one or more embodiments described herein. As shown, system 1400 may include the same components as system 1300 in some cases and may further include a set of gaps 1402.

[0120] In various embodiments, gap component 122 may electronically identify and / or generate set of gaps 1402 based on set of node pairs 802 and / or based on textual / semantic analysis of source code 106 and target domain model 108. More specifically, for any node pair in set of node pairs 802, gap component 122 may identify a service domain and program corresponding to that node pair, and gap component 122 may compare the business capabilities of that service domain with the unexposed method calls of that program (e.g., via a string search) and / or gap component 122 may compare the service domain interactions of that service domain with the program exposed method calls of that program (e.g., via a string search). In various cases, set of gaps 1402 may be any suitable electronic data that records / logs mismatches between such business capabilities and such unexposed method calls, and / or between such service domain interactions and such program exposed method calls. This may be further described with respect to FIGS. 15-16 .

[0121] FIG. 15 illustrates an exemplary, non-limiting block diagram 1500 showing how gaps between business capabilities and unexposed method calls are identified. In various embodiments, node pair 1502 can be any of node pair sets 802. As shown, node pair 1502 can indicate that a model graph node 1504 is linked / correlated to a mapped code graph node 1506. For illustrative purposes, assume that model graph node 1504 represents an account restoration service domain 1508 specified in target domain model 108, and further assume that mapped code graph node 1506 represents an account restoration program 1512 written within source code 106. In various instances, account restoration service domain 1508 can be responsible for executing a set of account restoration business capabilities 1510. As some non-limiting examples, the set of account restoration business capabilities 1510 may include an “activate” function, an “initiate” function, a “retrieve” function, and / or an “update” function. Further, the account restoration program 1512 may include a set of account restoration unexposed method calls 1514. As some non-limiting examples, the set of account restoration unexposed method calls 1514 may include an “activate” method call, an “initiate” method call, and / or an “update” method call. In various cases, the gap component 122 may parse the set of account restoration business capabilities 1510 to identify relevant keywords (e.g., “activate,” “initiate,” “retrieve,” “update”), and the gap component 122 may search for such relevant keywords in the account restoration unexposed method calls 1514 by utilizing string searches and / or any other suitable natural language processing techniques.If there are any related keywords within the set of account restoration business capabilities 1510 that are not found within the set of account restoration non-exposed method calls 1514, then the gap component 122 may conclude that a gap exists between the account restoration service domain 1508 and the account restoration program 1512, and the gap component 122 may record / log such gap in the set of gaps 1402. In the non-limiting example of FIG. 15 , the keyword analysis / string search may conclude that the set of account restoration non-exposed method calls 1514 fails to include a method call corresponding to the “get” function specified in the set of account restoration business capabilities 1510.

[0122] FIG. 16 illustrates an exemplary, non-limiting block diagram 1600 showing how gaps between service domain interactions and program exposure method calls are identified. In various embodiments, the node pair 1502, model graph node 1504, mapped code graph node 1506, account restoration service domain 1508, and account restoration program 1512 may be as described above. In various aspects, the account restoration service domain 1508 may be desired / expected to participate in a set of account restoration service domain interactions 1602. As some non-limiting examples, the set of account restoration service domain interactions 1602 may include interactions with a “corporate current account” service domain, interactions with a “position keeping” service domain, and interactions with a “product directory” service domain. Additionally, the account restoration program 1512 may include a set of account restoration program exposure method calls 1604. As some non-limiting examples, the set of account restoration program exposure method invocations 1604 may include a program invocation for "company current account" and a program invocation for "product directory." In various cases, the gap component 122 may parse the set of account restoration service domain interactions 1602 to identify relevant keywords (e.g., "company current account," "location maintenance," "product directory"), and the gap component 122 may search for such relevant keywords in the account restoration program exposure method invocations 1604 by utilizing string search and / or any other suitable natural language processing techniques.If there are any related keywords within the set of account restoration service domain interactions 1602 that are not found within the set of account restoration program exposure method calls 1604, then the gap component 122 may conclude that a gap exists between the account restoration service domain 1508 and the account restoration program 1512, and the gap component 122 may record / log such gap in the set of gaps 1402. In the non-limiting example of FIG. 16 , the keyword analysis / string search may conclude that the set of account restoration program exposure method calls 1604 fails to include a call to a program corresponding to the “location maintenance” service domain specified in the set of account restoration service domain interactions 1602.

[0123] 17 illustrates a block diagram of an exemplary, non-limiting system 1700 including a set of coding templates that can facilitate monolith-to-microservices refactoring via graph comparison of source code to domain models, in accordance with one or more embodiments described herein. As shown, system 1700 can include the same components as system 1400 in some cases and can further include a set of coding templates 1702.

[0124] In various embodiments, because the set of node pairs 802 can be considered a result of a microservice refactoring, the execution component 124 electronically shares the set of node pairs 802 (and / or a subset thereof) so that subsequent decisions regarding microservice refactoring can be made for the monolithic application 104. For example, in some cases, the execution component 124 may transmit the set of node pairs 802 (or a subset thereof) to any suitable computing device (not shown). As another example, in some cases, the execution component 124 may render the set of node pairs 802 (or a subset thereof) on any suitable computing monitor / screen (not shown). In some cases, such transmission and / or rendering can be considered an electronic recommendation for refactoring the monolithic application 104 according to the set of node pairs 802 (e.g., an electronic recommendation to replace / replace programs in the source code 106 with known microservices based on which programs in the source code 106 correspond to which service domains specified by the target domain model 108). Additionally, in some cases, the execution component 124 may similarly transmit to any suitable computing device and / or render the set of gaps 1402 (or a subset thereof) to any suitable computer display / monitor, thereby notifying a user of any identified inconsistencies between the source code 106 and the target domain model 108.

[0125] Still further, in various aspects, execution component 124 may electronically store, maintain, and / or otherwise access set of coding templates 1702, and execution component 124 may selectively insert any of set of coding templates 1702 into source code 106 to thereby fill and / or otherwise address set of gaps 1402. In other words, set of coding templates 1702 may be any suitable sequence of pre-written and / or pre-categorized computer-executable instructions (e.g., pre-written non-exposed method calls, pre-written program exposed method calls). In various aspects, execution component 124 may electronically identify (e.g., via keyword matching) which of set of coding templates 1702 address and / or fill set of gaps 1402, and execution component 124 may electronically insert such identified coding templates into source code 106. In this manner, the execution component 124 may help to remedy the set of gaps 1402 (eg, help to remedy identified inconsistencies between the source code 106 and the target domain model 108).

[0126] 18, 19, 20, and 21 illustrate flow diagrams of exemplary, non-limiting computer-implemented methods 1800, 1900, 2000, and 2100 that can facilitate monolith-to-microservices refactoring via graph comparison of source code to domain model, in accordance with one or more embodiments described herein. In various cases, the refactoring system 102 can facilitate the computer-implemented methods 1800 through 2100.

[0127] In various embodiments, operation 1802 may include accessing the monolithic source code (e.g., 106) and the reference domain model (e.g., 108) by a device (e.g., 114) operably coupled to the processor.

[0128] In various aspects, operation 1804 may include generating, by the device (e.g., via 116), a first graph (e.g., 402) by parsing the monolithic source code. In various cases, nodes of the first graph may represent programs written in the monolithic source code, and edges of the first graph may represent programs exposing method calls written in the monolithic source code.

[0129] In various cases, operation 1806 may include generating, by the device (e.g., via 116), a second graph (e.g., 404) by parsing the reference domain model. In various cases, nodes of the second graph may represent service domains specified by the reference domain model, and edges of the second graph may represent service domain interactions specified by the reference domain model.

[0130] In various aspects, operation 1808 may include executing, by the device (e.g., via 118), a graph convolutional neural network (e.g., 902) on the first graph, thereby resulting in an embedded representation (e.g., 904) of the nodes of the first graph.

[0131] In various cases, operation 1810 may include executing, by the device (e.g., via 118), a graph convolutional neural network on the second graph, thereby resulting in an embedded representation (e.g., 1002) of the nodes of the second graph. As shown, computer-implemented method 1800 may then proceed to operation 1902 of computer-implemented method 1900.

[0132] In various embodiments, operation 1902 may include initializing, by the device (e.g., via 118), a set of mapped node pairs (e.g., 802), which may initially be empty.

[0133] In various aspects, operation 1904 may include determining, by the device (e.g., via 118), whether there are any nodes in the second graph that have not already been mapped to a node in the first graph. If not, the computer-implemented method 1900 may proceed to operation 2002 of the computer-implemented method 2000. If so, the computer-implemented method 1900 may instead proceed to operation 1906.

[0134] In various cases, operation 1906 may include selecting, by the device (e.g., via 118) and from the second graph, a node that is not already mapped to any node in the first graph.

[0135] In various cases, operation 1908 may include identifying, by the device (e.g., via 118) and in the first graph, a node whose embedded representation is nearest (e.g., in terms of Euclidean distance) to the embedded representation of the selected node from the second graph.

[0136] In various aspects, operation 1910 may include marking, by the device (e.g., via 118) and in the set of mapped node pairs, the selected node from the second graph as mapped to and / or associated with the identified node from the first graph. In various cases, the computer-implemented method 1900 may proceed back to operation 1904.

[0137] In various embodiments, operation 2002 may include accessing, by the device (e.g., via 120), user-supplied feedback (e.g., 1302) that approves or adjusts the set of mapped node pairs. In various cases, for each mapped node pair, a confidence score (e.g., one of 1202) is calculated based on Euclidean distance and / or semantic / keyword analysis, and the user is prompted for feedback regarding those mapped node pairs whose confidence score is below any suitable threshold level.

[0138] In various aspects, operation 2004 may include transmitting by the device (e.g., via 124) to any suitable computing device and / or rendering by the device (e.g., via 124) on any suitable computer screen an electronic message indicating the set of mapped node pairs (e.g., indicating those mapped node pairs that were approved by the feedback provided by the user). In various cases, the set of mapped node pairs may be considered to convey the results of the microservice refactoring (e.g., to indicate which programs written in the monolithic source code correspond to which service domains specified in the reference domain model, where each service domain is known / may be known to correspond to one or more microservices). As shown, computer-implemented method 2000 may proceed to operation 2102 of computer-implemented method 2100.

[0139] In various embodiments, operation 2102 may include determining, by the device (e.g., via 122), whether all mapped node pairs in the set have been analyzed. If so, the computer-implemented method 2100 may end at operation 2104. If not, the computer-implemented method 2100 may instead proceed to operation 2106.

[0140] In various aspects, operation 2106 may include selecting, by the device (e.g., via 122), from the set, a mapped node pair (e.g., 1502) that has not yet been analyzed, where the mapped node pair indicates that a first node (e.g., 1506) from a first graph corresponds to a second node (e.g., 1504) from a second graph, where the first node may represent a program written in monolithic source code (e.g., 1512) and / or the second node may represent a service domain specified by a reference domain model (e.g., 1508).

[0141] In various cases, operation 2108 may include detecting, by the device (e.g., via 122), one or more attribute gaps (e.g., some of 1402) between the first node and the second node by semantically comparing business capabilities (e.g., 1510) specified by a reference domain model for the service domain with / against unexposed method calls (e.g., 1514) written into the program.

[0142] In various aspects, operation 2110 may include detecting, by the device (e.g., via 122), one or more dependency gaps (e.g., others of 1402) between the first node and the second node by semantically comparing service domain interactions (e.g., 1602) specified by a reference domain model for the service domain with / against program exposed method calls (e.g., 1604) written into the program.

[0143] In various cases, operation 2112 may include inserting, by the device (e.g., via 124), one or more coding templates (e.g., 1702) into the program that can address / fill one or more attribute gaps and / or one or more dependency gaps. In various cases, the computer-implemented method 2100 may proceed back to operation 2102.

[0144] 22 illustrates a flow diagram of an exemplary, non-limiting computer-implemented method 2200 that can facilitate monolith-to-microservices refactoring via a graph comparison of source code to a domain model, in accordance with one or more embodiments described herein. In various cases, the refactoring system 102 can facilitate the computer-implemented method 2200.

[0145] In various embodiments, operation 2202 may include accessing, by a device operably coupled to the processor (e.g., via 114), source code (e.g., 106) of a monolithic application (e.g., 104) and a target domain model (e.g., 108) corresponding to the monolithic application.

[0146] In various aspects, operation 2204 may include refactoring, by the device (e.g., via 118), the monolithic application into microservices by aligning a first graph (e.g., 402) representing the source code with a second graph (e.g., 404) representing the target domain model.

[0147] Although not explicitly shown in FIG. 22 , the computer-implemented method 2200 may further include generating, by the device (e.g., via 116), a first graph by parsing the source code in search of programs (e.g., 202) and program exposure method calls, where each node (e.g., 502) of the first graph represents a program and each edge (e.g., 504) of the first graph represents a program exposure method call, and generating, by the device (e.g., via 116), a second graph by parsing the target domain model in search of service domains (e.g., 302) and service domain interactions (e.g., 304), where each node (e.g., 506) of the second graph represents a service domain and each edge (e.g., 508) of the second graph represents a service domain interaction.

[0148] Although not shown in FIG. 22, aligning the first graph with the second graph results in a set of node pairs (e.g., 802) that respectively map nodes in the first graph to nodes in the second graph, where each node in the second graph corresponds to a microservice.

[0149] Those skilled in the art will understand that the disclosure herein describes non-limiting examples of various embodiments. For ease of description and / or illustration, various portions of the disclosure herein utilize the term "each" when describing various embodiments. Those skilled in the art will understand that such use of the term "each" is a non-limiting example. In other words, when the disclosure herein provides a description applied to "each" of several particular objects and / or components, it should be understood that this is a non-limiting example of various embodiments, and it should be further understood that in various other embodiments, such a description may apply to less than "each" of the particular objects and / or components.

[0150] To provide additional context for the various embodiments described herein, Figure 23 and the following discussion are intended to provide a brief, general description of a suitable computing environment 2300 in which various embodiments of the embodiments described herein may be implemented. While the embodiments have been described above in the general context of computer-executable instructions that may be executed on one or more computers, those skilled in the art will recognize that the embodiments may also be implemented in combination with other program modules and / or combinations of hardware and software.

[0151] Generally, program modules include routines, programs, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Those skilled in the art will also appreciate that the methods of the invention can be practiced using other computer system configurations, including single-processor or multi-processor computer systems, minicomputers, mainframe computers, Internet of Things (IoT) devices, distributed computing systems, and personal computers, handheld computing devices, and microprocessor-based or programmable consumer electronics, each of which may be operatively coupled to one or more associated devices.

[0152] The illustrated embodiments herein may also be practiced in distributed computing environments where certain tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

[0153] A computing device typically includes a variety of media, which may include computer-readable storage media, machine-readable storage media, and / or communication media, and the two terms are used interchangeably herein as follows: A computer-readable storage medium or machine-readable storage medium may be any available storage medium that can be accessed by a computer, and includes both volatile and nonvolatile media, removable and non-removable media. By way of example and not limitation, a computer-readable storage medium or machine-readable storage medium may be implemented in connection with any method or technology for storing information, such as computer-readable or machine-readable instructions, program modules, structured or unstructured data, etc.

[0154] A computer-readable storage medium may include, but is not limited to, random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD), Blu-ray disc (BD) or other optical disc storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage device, solid-state drive or other solid-state storage device, or other tangible and / or non-transitory medium used to store the desired information. In this regard, the terms "tangible" or "non-transitory" herein as applied to storage, memory, or computer-readable medium should be understood as qualifiers to exclude only the propagating transitory signal per se, and do not waive rights to all standard storage, memory, or computer-readable medium that are not merely the propagating transitory signal per se.

[0155] The computer-readable storage medium may be accessed by one or more local or remote computing devices for various operations on the information stored by the medium, for example, via access requests, queries, or other data retrieval protocols.

[0156] Communication media typically embodies computer-readable instructions, data structures, program modules, or other structured or unstructured data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery or transport medium. The term "modulated data signal" or signal refers to a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal or signals. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media.

[0157] 23 , an exemplary environment 2300 for implementing various embodiments of the aspects described herein includes a computer 2302 having a processing unit 2304, a system memory 2306, and a system bus 2308. The system bus 2308 couples system components including, but not limited to, the system memory 2306 to the processing unit 2304. The processing unit 2304 can be any of a variety of commercially available processors. Dual microprocessors and other multi-processor architectures can also be utilized as the processing unit 2304.

[0158] The system bus 2308 may be any of several types of bus structures that may be further interconnected to a memory bus, a peripheral bus, and a local bus (with or without a memory controller) using any of a variety of commercially available bus architectures. The system memory 2306 includes ROM 2310 and RAM 2312. The basic input / output system (BIOS) is stored in non-volatile memory such as ROM, erasable programmable read-only memory (EPROM), or EEPROM, and contains the basic routines that help to transfer information between elements within the computer 2302, such as during start-up. The RAM 2312 may also include high-speed RAM such as static RAM for caching data.

[0159] The computer 2302 further includes an internal hard disk drive (HDD) 2314 (e.g., EIDE, SATA), one or more external storage devices 2316 (e.g., a magnetic floppy disk drive (FDD) 2316, a memory stick or flash drive reader, a memory card reader, etc.), and a drive 2320, e.g., a solid-state drive, optical disk drive, etc., capable of reading from or writing to a disk 2322, such as a CD-ROM disk, DVD, BD, etc. Alternatively, where a solid-state drive is involved, the disk 2322 is not included unless it is separate. While the internal HDD 2314 is illustrated as being located internal to the computer 2302, the internal HDD 2314 can also be configured for external use in a suitable chassis (not shown). Additionally, although not shown in the environment 2300, a solid-state drive (SSD) can be used in addition to or in place of the HDD 2314. HDD 2314, external storage device 2316, and drive 2320 may be connected to system bus 2308 by HDD interface 2324, external storage interface 2326, and drive interface 2328, respectively. Interface 2324 for external drive implementations may include at least one or both of Universal Serial Bus (USB) and Institute of Electrical and Electronics Engineers (IEEE) 1394 interface technologies. Other external drive connection technologies are within the contemplation of the embodiments described herein.

[0160] The drives and their associated computer-readable storage media provide non-volatile storage of data, data structures, computer-executable instructions, etc. For computer 2302, the drives and storage media accommodate the storage of any data in a suitable digital format. While the above description of computer-readable storage media refers to each type of storage device, it should be understood by those skilled in the art that other types of computer-readable storage media, whether now existing or developed in the future, may be used in the exemplary operating environment, and further that any such storage media may include computer-executable instructions for performing the methods described herein.

[0161] A number of program modules may be stored in the drives and RAM 2312, including an operating system 2330, one or more application programs 2332, other program modules 2334, and program data 2336. It is also possible that all or portions of the operating system, applications, modules, and / or data may be cached in RAM 2312. The systems and methods described herein may be implemented using various commercially available operating systems or combinations of operating systems.

[0162] Computer 2302 may optionally include emulation technology. For example, a hypervisor (not shown) or other intermediary emulates a hardware environment for operating system 2330, where the emulated hardware may optionally differ from the hardware illustrated in FIG. 23. In one such embodiment, operating system 2330 may comprise one virtual machine (VM) of multiple VMs hosted on computer 2302. Additionally, operating system 2330 may provide a runtime environment, such as the Java Runtime Environment or the .NET Framework, for application 2332. A runtime environment is a consistent execution environment that allows application 2332 to run on any operating system that includes the runtime environment. Similarly, operating system 2330 may support containers, where application 2332 may be in the form of a container, which is a lightweight, standalone, executable software package that includes, for example, code, runtime, system tools, system libraries, and settings for the application.

[0163] Additionally, computer 2302 can be enabled with a security module such as a Trusted Processing Module (TPM). For example, with a TPM, a boot component hashes the boot component within the next hour and waits until the result matches a protected value before loading the next boot component. This process can be performed at any layer in the code execution stack of computer 2302, for example, at the application execution level or the operating system (OS) kernel level, thereby enabling security at any level of code execution.

[0164] A user can enter commands and information into the computer 2302 through one or more wired / wireless input devices, such as a keyboard 2338, a touch screen 2340, and a pointing device such as a mouse 2342. Other input devices (not shown) can include a microphone, an infrared (IR) remote control, a radio frequency (RF) remote control, or other remote control, a joystick, a virtual reality controller and / or headset, a game pad, a stylus pen, an image input device such as a camera, a gesture sensor input device, a vision movement sensor input device, an expression or face detection device, a biometric input device such as a fingerprint or iris scanner, etc. These and other input devices are often connected to the processing unit 2304 through an input device interface 2344, which can be coupled to the system bus 2308, but can also be connected by other interfaces, such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR interface, a BLUETOOTH interface, etc.

[0165] A monitor 2346 or other type of display device may also be connected to the system bus 2308 via an interface, such as a video adapter 2348. In addition to the monitor 2346, computers typically include other peripheral output devices (not shown), such as speakers, printers, etc.

[0166] The computer 2302 may operate in a networked environment using logical connections via wired and / or wireless communications to one or more remote computers, such as a remote computer 2350. The remote computer 2350 may be a workstation, a server computer, a router, a personal computer, a portable computer, a microprocessor-based entertainment device, a peer device or other common network node, and typically includes many or all of the elements described relative to the computer 2302, although for simplicity, only the memory / storage device 2352 is illustrated. The logical connections depicted include wired / wireless connectivity to a local area network (LAN) 2354 and / or larger networks, such as a wide area network (WAN) 2356. Such LAN and WAN networking environments are commonplace in offices and companies and facilitate enterprise-wide computer networks, such as intranets, all of which may connect to a global communication network, such as the Internet.

[0167] When used in a LAN networking environment, the computer 2302 may be connected to the local network 2354 through a wired and / or wireless communication network interface or adapter 2358. The adapter 2358 facilitates wired or wireless communication to the LAN 2354, which may also include a wireless access point (AP) disposed thereon for communicating with the adapter 2358 in a wireless mode.

[0168] When used in a WAN networking environment, the computer 2302 may include a modem 2360 or may be connected to a communications server on the WAN 2356 via other means for establishing communications over the WAN 2356, such as via the Internet. The modem 2360, which may be internal or external and a wired or wireless device, may be connected to the system bus 2308 via the input device interface 2344. In a networked environment, program modules depicted relative to the computer 2302, or portions thereof, may be stored in the remote memory / storage device 2352. It will be appreciated that the network connections shown are examples and other means of establishing a communications link between computers may be used.

[0169] When used in either a LAN or WAN networking environment, computer 2302 may access cloud storage systems or other network-based storage systems, including, but not limited to, networked virtual machines, that provide one or more aspects of information storage or processing, in addition to or in place of external storage device 2316 as described above. Generally, a connection between computer 2302 and a cloud storage system may be established over LAN 2354 or WAN 2356, for example, by adapter 2358 or modem 2360, respectively. Upon connecting computer 2302 to an associated cloud storage system, external storage interface 2326, with the aid of adapter 2358 and / or modem 2360, can manage the storage provided by the cloud storage system as it manages other types of external storage. For example, external storage interface 2326 may be configured to provide access to cloud storage sources as if those sources were physically connected to computer 2302.

[0170] The computer 2302 may be operable to communicate with any wireless device or entity operably arranged in wireless communication, such as, for example, a printer, a scanner, a desktop and / or portable computer, a portable data assistant, a communications satellite, any appliance or location associated with a radio-detectable tag (e.g., a kiosk, a newsstand, a store shelf, etc.), and a telephone. This may include Wireless Fidelity (Wi-Fi) and Bluetooth® wireless technologies. Thus, communication may be in a predefined structure similar to a traditional network, or may simply be ad-hoc communication between at least two devices.

[0171] 24, an exemplary cloud computing environment 2400 is illustrated. As shown, the cloud computing environment 2400 includes one or more cloud computing nodes 2402 with which local computing devices used by cloud consumers, such as, for example, a personal digital assistant (PDA) or mobile phone 2404, a desktop computer 2406, a laptop computer 2408, and / or an automobile computer system 2410, may communicate. The nodes 2402 may communicate with each other. They may be physically or virtually grouped in one or more networks (not shown), such as a private, community, public, or hybrid cloud, or combinations thereof, as described hereinabove. This enables the cloud computing environment 2400 to provide infrastructure, platform, and / or software as a service for which the cloud consumer does not need to maintain resources on their local computing device. It will be understood that the types of computing devices 2404-2410 shown in FIG. 24 are intended to be illustrative only, and that computing node 2402 and cloud computing environment 2400 can communicate with any type of computerized device via any type of network and / or network-addressable connection (e.g., using a web browser).

[0172] Referring now to Figure 25, a set of functional abstraction layers provided by cloud computing environment 2400 (Figure 24) is shown. Repetitive descriptions of similar elements utilized in other embodiments described herein will be omitted for the sake of brevity. It should be understood in advance that the components, layers, and functions shown in Figure 25 are intended to be exemplary only, and the embodiments described herein are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0173] Hardware and software layer 2502 includes hardware and software components. Examples of hardware components include mainframe 2504, RISC (reduced instruction set computer) architecture-based servers 2506, servers 2508, blade servers 2510, storage devices 2512, and networks and networking components 2514. In some embodiments, software components include network application server software 2516 and database software 2518.

[0174] Virtualization layer 2520 provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers 2522, virtual storage 2524, virtual networks including virtual private networks 2526, virtual applications and operating systems 2528, and virtual clients 2530.

[0175] In one example, management layer 2532 may provide the following functions: Resource provisioning 2534 provides dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing 2536 provides cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification of cloud consumers and tasks, as well as protection of data and other resources. User portal 2538 provides access to the cloud computing environment for consumers and system administrators. Service level management 2540 provides cloud computing resource allocation and management so that required service levels are met. Service level agreement (SLA) planning and fulfillment 2542 provides advance arrangements and procurement of cloud computing resources where future requirements are anticipated according to SLAs.

[0176] Workload tier 2544 provides example functions for which cloud computing environments are utilized. Example workloads and functions provided from this tier include mapping and navigation 2546; software development and lifecycle management 2548; virtual classroom instruction delivery 2550; data analytics processing 2552; transaction processing 2554; and differential private federated learning processing 2556. Various embodiments described herein may utilize the cloud computing environment described with reference to Figures 24 and 25 to perform one or more differential private federated learning processes in accordance with various embodiments described herein.

[0177] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions described in the blocks may occur out of the order described in the figures. For example, two blocks shown in succession may, in fact, be executed substantially simultaneously, depending on the functionality involved, or the blocks may possibly be executed in the reverse order. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, are implemented by a dedicated hardware-based system that performs the specified functions or operations or executes a combination of dedicated hardware and computer instructions.

[0178] Additionally, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or." That is, unless otherwise specified or clear from the context, "X utilizes A or B" is intended to mean any of the natural inclusive permutations. That is, if X utilizes A; X utilizes B; or X utilizes both A and B, then "X utilizes A or B" is satisfied under any of the foregoing cases. Also, as used in this specification and the accompanying drawings, the articles "a" and "an" should generally be construed to mean "one or more" unless otherwise specified or clear from the context that the singular is intended. As used herein, the terms "example" and / or "exemplary" are used to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited to such examples. Additionally, any aspect or design described herein as "example" and / or "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects or designs, and is not intended to exclude equivalent exemplary structures and techniques known to those skilled in the art.

Claims

1. A processor executing computer-executable components stored in non-transitory computer-readable memory 1. A system comprising: an access component for accessing source code of a monolithic application and a target domain model corresponding to the monolithic application; and a mapping component that refactors the monolithic application into microservices by aligning a first graph representing the source code with a second graph representing the target domain model. A system having:

2. The computer-executable components further include: generating the first graph by parsing the source code in search of programs and program-exposed method calls, wherein each node of the first graph represents the program and each edge of the first graph represents the program-exposed method call; and generating the second graph by parsing the target domain model in retrieval of service domains and service domain interactions, wherein each node of the second graph represents a service domain and each edge of the second graph represents a service domain interaction; A graph component that The system of claim 1 , comprising:

3. The system of claim 2 , wherein the service domain is described by a swagger portion of the target domain model and the service domain interactions are described by a transaction flow portion of the target domain model.

4. 2. The system of claim 1, wherein the aligning the first graph with the second graph results in a set of node pairs that respectively map nodes of the first graph to nodes of the second graph, where each of the nodes of the second graph corresponds to a microservice.

5. 5. The system of claim 4, wherein the mapping component aligns the first graph with the second graph based on Euclidean distances separating embedded node-wise representations of the first graph from embedded node-wise representations of the second graph, respectively.

6. The computer-executable components further include: a feedback component that accesses user-provided feedback, wherein the user-provided feedback approves or rejects at least one of the set of node pairs. The system of claim 4 , comprising:

7. The set of node pairs indicates that a first node of the first graph is mapped to a second node of the second graph, the first node representing a program within the source code and the second node representing a service domain within the target domain model, and the computer-executable component further comprises: a gap component that compares, via natural language processing, unexposed method calls written inside the program with business capabilities specified by the target domain model for the service domain, and compares, via natural language processing, program exposed method calls written inside the program with service domain interactions specified by the target domain model for the service domain. The system of claim 4 , comprising:

8. The gap component determines that a gap exists between the unexposed method calls and the business capabilities or between the program exposed method calls and the service domain interactions, and the computer-executable component further comprises: an execution component that inserts into the program a coding template that addresses the gap; The system of claim 7 , comprising:

9. accessing, by a device operatively coupled to the processor, source code of a monolithic application and a target domain model corresponding to said monolithic application; and refactoring, by the device, the monolithic application into microservices by aligning a first graph representing the source code with a second graph representing the target domain model. A computer-implemented method comprising:

10. generating, by the device, the first graph by parsing the source code in search of programs and program-exposed method calls, wherein each node of the first graph represents the program and each edge of the first graph represents the program-exposed method call; and generating, by the device, the second graph by parsing the target domain model in retrieval of service domains and service domain interactions, wherein each node of the second graph represents a service domain and each edge of the second graph represents a service domain interaction. The computer-implemented method of claim 9 further comprising:

11. The computer-implemented method of claim 10 , wherein the service domain is described by a swagger portion of the target domain model and the service domain interactions are described by a transaction flow portion of the target domain model.

12. 10. The computer-implemented method of claim 9, wherein the aligning the first graph with the second graph results in a set of node pairs that respectively map nodes of the first graph to nodes of the second graph, where each of the nodes of the second graph corresponds to a microservice.

13. 13. The computer-implemented method of claim 12, wherein the aligning the first graph with the second graph is based on Euclidean distances separating embedded node-wise representations of the first graph from embedded node-wise representations of the second graph, respectively.

14. accessing, by the device, feedback provided by a user, wherein the feedback provided by the user approves or rejects at least one of the set of node pairs. The computer-implemented method of claim 12 further comprising:

15. The set of node pairs indicates that a first node of the first graph is mapped to a second node of the second graph, the first node representing a program within the source code and the second node representing a service domain within the target domain model, and further: comparing unexposed method calls written inside the program by the device and via natural language processing with business capabilities specified by the target domain model for the service domain; and comparing program exposed method calls written inside the program by the device and via natural language processing with service domain interactions specified by the target domain model for the service domain; The computer-implemented method of claim 12, comprising:

16. determining, by the device, that a gap exists between the unexposed method call and the business capability or between the program exposed method call and the service domain interaction; and inserting, by said device, into said program a coding template that addresses said gap. The computer-implemented method of claim 15 further comprising:

17. 1. A computer program product for facilitating monolith-to-microservices refactoring via graph comparison of source code to a domain model, the computer program product comprising: a non-transitory computer-readable memory having program instructions embodied therein, the program instructions causing a processor to: accessing the source code of a monolithic application and a target domain model corresponding to said monolithic application; and refactoring the monolithic application into microservices by aligning a first graph representing the source code with a second graph representing the target domain model; executable by the processor to perform Computer program products.

18. The program instructions: generating the first graph by parsing the source code in search of programs and program-exposed method calls, wherein each node of the first graph represents the program and each edge of the first graph represents the program-exposed method call; and generating the second graph by parsing the target domain model in search of service domains and service domain interactions, where each node of the second graph represents a service domain and each edge of the second graph represents a service domain interaction. and further operable to cause the processor to execute:

18. A computer program product according to claim 17.

19. 20. The computer program product of claim 18, wherein the service domain is described by a swagger portion of the target domain model and the service domain interactions are described by a transaction flow portion of the target domain model.

20. 18. The computer program product of claim 17, wherein the aligning the first graph with the second graph results in a set of node pairs that respectively map nodes of the first graph to nodes of the second graph, where each of the nodes of the second graph corresponds to a microservice.

Images