Monomer-to-microservice reconstruction via source code-to-domain model graph comparison

Abstract

Systems / techniques are provided that facilitate monomer-to-microservice reconstruction via source code-to-domain model graph comparison. In various embodiments, the system may access source code of the unitary application and a target domain model corresponding to the unitary application. In various aspects, the system may reconstruct a single application as a micro-service by aligning a first graph representing source code with a second graph representing a target domain model.

Description

Background Art

[0001] The present disclosure relates to microservices refactoring, and more particularly to monolith to microservices refactoring via source code to domain model graph comparison. Summary of the invention

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

[0003] According to one or more embodiments, a system is provided. The system may include a non-transitory memory that may store computer executable components. The system may also include a processor that may be operably coupled to the memory and may execute the computer executable components stored in the memory. In various embodiments, the computer executable components may include an access component that may access source code of a monolithic application and a target domain model corresponding to the monolithic application. In various aspects, the computer executable components may also include a mapping component that may reconstruct 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 system may be implemented as a computer-implemented method and / or a computer program product. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Figure 1 A block diagram of an example non-limiting system that facilitates monolith to microservice refactoring via source code to domain model diagram comparison is shown in accordance with one or more embodiments described herein.

[0006] Figure 2 An example non-limiting block diagram illustrating source code for a monolithic application according to one or more embodiments described herein.

[0007] Figure 3 An example non-limiting block diagram of a target domain model is shown in accordance with one or more embodiments described herein.

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

[0009] Figure 5-Figure 7 An example non-limiting block diagram of a code map and / or a model map is shown according to one or more embodiments described herein.

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

[0011] Figure 9-12 An example non-limiting block diagram illustrating how to generate a set of node pairs based on a code graph and / or a model graph is shown according to one or more embodiments described herein.

[0012] Fig.13 A block diagram of an example non-limiting system including feedback that facilitates monolith to microservice refactoring via source code to domain model diagram comparison is shown in accordance with one or more embodiments described herein.

[0013] Fig.14 A block diagram is shown of an example non-limiting system including a set of gaps that facilitate monolith to microservice refactoring via source code to domain model graph comparison in accordance with one or more embodiments described herein.

[0014] Figure 15-16 An example non-limiting block diagram illustrating how to identify a set of gaps based on a set of node pairs in accordance with one or more embodiments described herein is shown.

[0015] Fig.17 A block diagram of an example non-limiting system including a set of coding templates that facilitate monolith to microservice refactoring via source code to domain model diagram comparison is shown in accordance with one or more embodiments described herein.

[0016] Figure 18-Figure 21 A flow diagram is shown of an example non-limiting computer-implemented method of facilitating monolith to microservice refactoring via source code to domain model diagram comparison in accordance with one or more embodiments described herein.

[0017] Fig. 22 A flow diagram is shown of an example non-limiting computer-implemented method of facilitating monolith to microservice refactoring via source code to domain model diagram comparison in accordance with one or more embodiments described herein.

[0018] Fig.23 A block diagram is shown of an example non-limiting operating environment in which one or more embodiments described herein may be facilitated.

[0019] Fig.24An example non-limiting cloud computing environment is shown in accordance with one or more embodiments described herein.

[0020] Fig.25 Example non-limiting abstract model layers are shown in accordance with one or more embodiments described herein. DETAILED DESCRIPTION

[0021] The following detailed description is illustrative only and is not intended to limit the embodiments and / or the application or uses of the embodiments. In addition, there is no intention to be bound by any express or implied information presented in the previous background or summary or detailed description.

[0022] One or more embodiments are now described with reference to the accompanying drawings, wherein the same reference numerals are used throughout to represent the same elements. In the following description, for the purpose of explanation, numerous specific details are set forth in order to provide a more thorough understanding of one or more embodiments. However, in various cases, it is apparent that the one or more embodiments described may be practiced without these specific details.

[0023] A monolithic application may be a set of independent computer programs, where each computer program is a sequence of computer-executable instructions that may be independent of (e.g., may avoid calling / invoking) other computing applications. That is, a monolithic application may perform / facilitate an overall function / task, where the overall function / task may be composed of many different sub-functions / sub-tasks, and where the code base of the monolithic application may contain all (or substantially all) of the computer-executable instructions for performing / facilitating such many different sub-functions / sub-tasks. Monolithic applications may often be too large and / or too cumbersome to be suitable for cloud-native environments, and they may often fail to exhibit the benefits provided by cloud-native applications (e.g., scalability, continuous deployment, stateless deployment, agility, ease of troubleshooting).

[0024] Compared to a monolithic application, a microservice can be an independently developable and / or independently deployable sub-application that can depend on (e.g., can 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 a small number of specific sub-functions / subtasks. In various instances, a microservice can be cloud-based. In various cases, multiple microservices can be loosely coupled together (e.g., via service exposure method calls) to form an overall and / or overall computing application.

[0025] In various aspects, it can be beneficial to modernize a monolithic application by refactoring the monolithic application into microservices. As will be appreciated by one of ordinary skill in the art, refactoring a monolithic application into microservices can involve identifying which specific portions of the source code of the monolithic application perform the same sub-functions / sub-tasks as the various microservices, such 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 a monolithic application into microservices can work in a bottom-up manner. Specifically, such bottom-up techniques can detect functional boundaries within the source code of a monolithic application, wherein the detected bounded portions of the source code can be considered as potential candidates for microservice replacement / alternatives. Unfortunately, and as recognized by the inventors of the various embodiments described herein, such bottom-up techniques may fail to take into account external information about which microservices are available and / or which sub-functions / sub-tasks those microservices perform. Due to this failure to consider external information about microservices, such bottom-up techniques may typically produce inaccurate, imprecise and / or otherwise useless reconstruction 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 a monolithic application into microservices can work in a top-down manner. Specifically, such top-down techniques (e.g., domain-driven design, event storming) can involve obtaining / building a target domain model (e.g., a banking industry architecture network (BIAN) model, an enhanced telecommunications operation map (eTOM) model). In various cases, the target domain model can be a standardized and / or non-standardized document that defines the capabilities expected to be satisfied by the monolithic application and therefore defines microservices. In various aspects, such top-down techniques can also include enabling subject matter experts to determine which parts of the source code of the monolithic application correspond to which microservices indicated by the target domain model. Such top-down techniques use the target domain model as external reference information to help improve some of the shortcomings of the above-mentioned bottom-up techniques. However, such top-down techniques can be a completely manual process that consumes the equivalent of many months of work.

[0028] Therefore, there may be a need for systems and / or techniques that can address one or more of these technical issues.

[0029] The various embodiments described herein can improve one or more such technical problems. More specifically, the various embodiments described herein may include systems, computer-implemented methods, devices, and / or computer program products that can facilitate monolithic to microservice reconstruction via source code to domain model graph comparison. In other words, the inventors have designed a computer-implemented technique for automatically reconstructing a monolithic application into a microservice, which computer-implemented technique may involve the application of a graph-theoretic comparison metric between the source code of the monolithic application and the target domain model corresponding to the monolithic application. Because such a computer-implemented technique can utilize the target domain model, such a computer-implemented technique can avoid the defects that plague the above-mentioned bottom-up technique. In addition, because such a computer-implemented technique can automate the process of monolithic to microservice reconstruction by applying graph-theoretic comparison metrics, such a computer-implemented technique can consume many orders of magnitude less time than the above-mentioned top-down technique (for example, such a top-down technique can consume months of time, while the computer-implemented technique described herein can consume only minutes of time).

[0030] Various embodiments described herein may be considered to be computerized tools (e.g., any suitable combination of computer-executable hardware and / or computer-executable software) that may facilitate monolith-to-microservice refactoring via source code-to-domain model graph comparison. In various aspects, such a computerized tool may 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, there may be any suitable monolithic application. In various aspects, the monolithic application may be implemented by source code, which may be written in any suitable coding language and / or in any suitable coding syntax. In various instances, the source code of the monolithic application may be one or more scripts defining any appropriate number of programs. In various cases, each program written in the source code may be any suitable sequence of computer executable instructions. In some aspects, the program written in the source code may perform any suitable number of non-exposed method calls on any suitable number of data objects. In addition, in some cases, the program written in the source code may perform any suitable number of program exposure method calls. As will be understood by those of ordinary skill in the art, the 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 will be further understood by those of ordinary skill in the art, the non-exposed method call may be any suitable electronic function, operation, transformation, and / or manipulation that may be performed on a data object and may be considered to be self-contained within a single program of the source code (e.g., the non-exposed method call may avoid interacting with other programs written in the source code). In contrast, and as will also be appreciated by one of ordinary skill in the art, a program-exposed method call may be an electronic invoke, 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 can access an input vector (e.g., a data object) and can perform a function (e.g., a non-exposed method call) on the input vector, thereby producing a transformed vector (e.g., another data object). In addition, in various instances, program A can invoke (e.g., can expose) program B, so that program B can then operate on and / or otherwise utilize (e.g., can perform another non-exposed method call on) the transformed vector.

[0033] In various embodiments, a monolithic application may be associated with a target domain model. As will be understood by those of ordinary skill in the art, the target domain model may be any suitable electronic natural language document, whether standardized and / or non-standardized, which specifies, describes, defines and / or otherwise indicates the capabilities that the monolithic application expects, anticipates and / or desires to achieve. In other words, the target domain model may be considered as a reference classification / hierarchy of the business logic that the monolithic application expects / expects to comply with. For example, the target domain model may specify any suitable number of service domains of the monolithic application that is expected / expected to be implemented, wherein the service domain may be a description / specification of a discrete, cohesive cluster of business logic that is considered responsible for executing / facilitating any suitable number of business capabilities for any suitable number of business objects. As will be understood by those of ordinary skill in the art, a business object may be a description / specification of any suitable electronic information / data fragment, and a business capability may be a description / specification of any suitable function, operation, transformation and / or manipulation that may be performed / facilitated on a business object. In addition, in various aspects, the target domain model may describe / specify any suitable number of interactions that may be expected / 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 may specify which business capabilities should 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, a computerized tool can automatically facilitate such a refactoring by utilizing both the source code and the target domain model of the monolithic application.

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

[0037] In various embodiments, a graph component of a computerized tool can electronically generate a graph (e.g., a data structure having nodes / vertices and edges) based on source code. More specifically, in various aspects, the graph component can electronically parse the source code of a monolithic application via any suitable static and / or dynamic (e.g., runtime-based) parsing technology. Via such parsing, the graph component can identify and / or otherwise detect programs written within the source code. In addition, via such parsing, the graph component can identify and / or otherwise detect program-exposed method calls written within the source code. Specifically, for any given program-exposed method call written within the source code, the graph component can discover via such parsing which program of the source code is configured to make the given program-exposed method call, and which program of the source code is configured to be invoked by the given program-exposed method call. Thus, in various instances, the graph component can construct and / or otherwise generate a graph such that the nodes / vertices of the graph represent the identified / detected programs, respectively (e.g., the graph component can generate a new node / vertex for each program), and / or such that the edges of the graph represent the identified / detected program-exposed method calls, respectively (e.g., the graph component can generate a new edge for each program-exposed method call). In various cases, such a graph can be referred to as a code graph because it can be created based on source code.

[0038] In some cases, the code graph can be unweighted. In other cases, the code graph can be weighted according to any suitable attributes / characteristics of the program written in the source code. For example, for any given node in the code graph, the given node can represent a given program, and the attributes of the given node can include: entry point association with other nodes (e.g., the entry point association attribute can indicate whether the given program appears in the execution trajectory of another specific program); common entry points with other nodes (e.g., the common entry point attribute can indicate whether the given program and another specific program have the same entry points as each other); inheritance (e.g., the inheritance attribute can indicate whether the data object manipulated by the given program inherits one or more of its characteristics from the data object of another specific program 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 can 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 the source code includes program X, program Y, and program Z. In addition, assume that program X includes a first program-exposed method call to program Y and a second program-exposed method call to program Z. In addition, assume that program Z includes a third program-exposed method call to program Y. In this case, the graph component can parse the source code to identify / detect program X, program Y, program Z, the first program-exposed method call, the second program-exposed method call, and the third program-exposed method call. In various aspects, the graph component can create a graph based on such parsing. In particular, the graph can include: a node X representing program X; a node Y representing program Y; and a node Z representing program Z. In addition, because the first program-exposed method call can point from program X to program Y, the graph can include a first directed edge between node X and node Y, wherein the first directed edge can be away from node X and point to node Y, and similarly, because the second program-exposed method call can point from program X to program Z, the graph can include a second directed edge between node X and node Z, wherein the second directed edge can be away from node X and point to node Z. Similarly, because the third program-exposed method call can be directed from program Z to program Y, the graph can include a third directed edge between node Z and node Y, wherein the third directed edge can be directed away from node Z to node Y, such that the graph component can generate a graph based on programs and / or program-exposed method calls identified / detected through parsing of source code. As described above, such a graph can be referred to as a code graph.

[0040] In addition, as described above, in various aspects, the graph component can dynamically parse the source code (e.g., during the runtime of the source code) to generate different execution traces and / or production logs of the source code. In various instances, such different execution traces and / or production logs can indicate different program-to-program interaction sequences that can be implemented by the source code (e.g., different execution orders and / or different execution branches that can be presented in different contexts that can indicate the source code). In some cases, such different program-to-program interaction sequences can be referred to as different program transactions. In any case, the edge weights of the code graph can be based on such different program-to-program interaction sequences. For example, there can be many different program-exposed method calls written in the source code, but some of the many different program-exposed method calls can be implemented / executed more frequently than others. Specifically, the first subset of many different program-exposed method calls can be involved in and / or otherwise exist in a larger proportion of different sequences of program-to-program interactions. Therefore, larger and / or more important weight values ​​can be assigned to the edges in the code graph that represent the first subset of many different program-exposed method calls, respectively. On the contrary, the second subset of many different program-exposed method calls can be implemented / executed less frequently. That is, a second subset of the many different program-exposed method calls may be involved and / or otherwise present in a smaller portion of the different program-to-program interaction sequences (e.g., it is even possible that the program-exposed method calls do not exist in any program-to-program interaction sequence, in which case such program-exposed method calls are considered unused despite being present in the source code). Accordingly, smaller and / or less important weight values ​​may be assigned to edges in the code graph that respectively represent the second subset of the many different program-exposed method calls.

[0041] As described above, in various embodiments, a graph component of a computerized tool may electronically generate another graph based on a target domain model. More specifically, in various aspects, the graph component may electronically parse the target domain model via any suitable text parsing technique. Via such parsing, the graph component may identify and / or otherwise detect service domains specified within the target domain model (e.g., within a swagger portion of the target domain model). Furthermore, via such parsing, the graph component may identify and / or otherwise detect service domain interactions specified within the target domain model (e.g., within a transaction / process 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 domain is expected / expected to initiate a given interaction, and which service domain is expected / expected to be invoked by the given interaction. Thus, in various instances, the graph component can construct and / or otherwise generate a graph such that the nodes / vertices of the graph represent the identified / detected service domains, respectively (e.g., the graph component can generate a new node / vertex for each service domain), and / or such that the edges of the graph represent the identified / detected service domain interactions, respectively (e.g., the graph component can generate a new edge for each service domain interaction). In various cases, such a graph can be referred to as a model graph because it can be created based on a 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 appropriate attributes / characteristics of the service domain specified in the target domain model. For example, and similarly to as described above, for any given node in the model graph, the given node may represent a given service domain, and the attributes of the given node may include: entry point associations with other nodes (e.g., entry point association attributes may indicate whether the given service domain appears in the interaction trajectory of another specific service domain); common entry points with other nodes (e.g., common entry point attributes may indicate whether the given service domain and another specific service domain have the same interaction entry points as each other); inheritance (e.g., inheritance attributes may indicate whether the business object manipulated by the given service domain inherits one or more of its characteristics from the business object of another specific service domain and / or leaves one or more of its characteristics to the business object of another specific service domain); and / or business object associations (e.g., business object association attributes may indicate whether the given service domain and another specific service domain manipulate the same business objects as each other).

[0043] As a non-limiting example, assume that the target domain model specifies service domain H, service domain I, and service domain J. In addition, 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 this case, the graph component can parse the target domain model to identify / detect service domain H, service domain I, service domain J, the first interaction, and the second interaction. In various aspects, the graph component can create a graph based on such parsing. In particular, the graph can include: a node H representing program H; a node I representing program I; and a node J representing program J. In addition, because the first interaction can be performed from service domain H to service domain J, the graph can include a first directed edge between node H and node J, wherein the first directed edge can point away from node H to node J. Similarly, because the second interaction can be performed from service domain I to service domain J, the graph can include a second directed edge between node I and node J, wherein the second directed edge can point away from node I to node J. In this way, the graph component can generate a graph based on the service domains and / or service domain interactions identified / detected by parsing the target domain model. As mentioned above, such a diagram may be referred to as a model diagram.

[0044] In various embodiments, a mapping component of a computerized tool can electronically reconstruct a monolithic application into microservices based on both a code graph and a model graph. More specifically, in various aspects, a mapping component can electronically align nodes of a code graph with nodes of a model graph, thereby generating a set of node pairs. In other words, a mapping component can map and / or otherwise associate (e.g., not necessarily in a one-to-one manner) nodes of a model graph to corresponding nodes of a code graph. Since the nodes of a model graph can represent corresponding service domains specified by a target domain model, and since the nodes of a code graph can represent corresponding programs written in the source code of a monolithic application, it can be considered that a set of node pairs indicates which programs of a monolithic application embody (e.g., are most similar to) which service domains of a target domain model. In addition, because each service domain may already be known / considered to correspond to at least one microservice, a set of node pairs can therefore be considered to indicate which programs of a monolithic application can be replaced / replaced by which known microservices. The following are further non-limiting details on how a mapping component can generate a set of node pairs.

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

[0046] In any case, the graph convolutional neural network can be configured to receive a graph as input and produce 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 can generate / output a continuous vector of any appropriate dimension, where the continuous vector can represent the given node. That is, the value / amplitude of the elements of the continuous vector can depend on the attributes and / or edge connectivity (e.g., neighborhood) of the given node. As will be understood by those of ordinary skill in the art, the graph convolutional neural network may have undergone any suitable type and / or style of training in order to learn how to accurately generate an embedded node-by-node representation of the input graph. Non-limiting examples of such training may include supervised training, unsupervised training, and / or reinforcement learning. As will be further understood by those of ordinary skill in the art, any suitable training termination criteria, any suitable training objective / loss / error function, and / or any suitable training batch size may be implemented to train the graph convolutional neural network.

[0047] Thus, in various aspects, a mapping component may perform a graph convolutional neural network on a code graph, which may cause the graph convolutional neural network to generate a set of embedded node-by-node representations of the code graph. Specifically, the mapping component may feed the code graph to an input layer of the graph convolutional neural network (e.g., each neuron of the input layer may receive a corresponding node from the code graph), the code graph may complete 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-by-node representations of the code graph based on the activations provided by the one or more hidden layers. In various cases, a set of embedded node-by-node representations of the code graph may include a unique continuous vector for each unique node of the code graph. As will be appreciated by one of ordinary skill in the art, the graph convolutional neural network may therefore be considered to import the code graph into an embedding space.

[0048] Similarly, in various instances, the mapping component can perform a graph convolutional neural network on the model graph, which can cause the graph convolutional neural network to generate a set of embedded node-by-node representations of the model graph. Specifically, the mapping component can feed the model graph to the input layer of the graph convolutional neural network (e.g., each neuron of the input layer can receive a corresponding node from the model graph), the model graph can complete 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 can calculate a set of embedded node-by-node representations of the model graph based on the activations provided by the one or more hidden layers. As described above, in various cases, a set of embedded node-by-node representations of the model graph can include a unique continuous vector for each unique node of the model graph. As will be understood by those of ordinary skill in the art, the graph convolutional neural network can therefore be considered to import the model graph into the same embedding space as the code graph. Therefore, in various instances, each embedded node-by-node representation of the model graph can be a continuous vector having the same dimension (e.g., the same number of elements) as each embedded node-by-node representation of the code graph.

[0049] Although the disclosure herein mainly describes various embodiments of the mapping component as generating an embedded node-by-node representation of a code graph and / or a model graph via a graph convolutional neural network, this is only a non-limiting example to facilitate explanation. In various aspects, the mapping component can utilize and / or use any other suitable embedded representation learning technology to create an embedded node-by-node representation of a code graph and / or a model graph.

[0050] In any case, the mapping component can generate a set of node pairs based on the embedded node-by-node representation of the code graph and based on the embedded node-by-node representation of the model graph. More specifically, the mapping component can iterate through each node in the model graph. For each given node in the model graph, the mapping component can 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 can identify from the code graph a node with an embedded representation that is closest and / or closest (e.g., in terms of Euclidean distance) to the embedded representation of the given node, and the mapping component can mark and / or otherwise mark the nodes identified in the code graph as being mapped, linked, associated and / or paired to a given node in the model graph.

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

[0052] In any case, the mapping component can map, link, associate, and / or pair each node in the model graph to a corresponding node in the code graph by performing an iteration over each node in the model graph and searching for the node in the code graph having the nearest / closest embedded representation, thereby producing a set of node pairs.

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

[0054] Although the disclosure mainly describes various embodiments of the mapping component as generating node pair sets based on the common embedding space technology, this is only a non-limiting example to facilitate explanation. In various aspects, the mapping component can generate node pair sets by implementing any other suitable graph alignment technology, such as the subgraph kernel technology. That is, no matter which graph alignment technology the mapping component uses, the result can be a node pair set.

[0055] In any case, the mapping component can generate a set of node pairs, which can be thought of as mapping / linking nodes of the model graph to corresponding nodes of the code graph. Note that in various aspects, such mapping / linking / pairing can but need not be one-to-one. For example, in some instances, there can 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 instances, there can 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 can represent a corresponding program written in the source code. In addition, as described above, each node in the model graph can represent a corresponding service domain specified in the target domain model. Therefore, because the node pair set can map / link / correlate the nodes of the code graph to the nodes of the model graph, the node pair set can be further considered as mapping / linking / correlating the program written in the source code to the service domain specified by the target domain model. In addition, because each service domain can be known / considered to correspond to at least one microservice, the node pair set can be further considered as mapping / linking / associating the program written in the source code to a known microservice. In other words, the node pair set can be considered to indicate how the source code of a monolithic application can be refactored into microservices (for example, it can be considered to convey which programs written in the source code can be replaced / replaced by which known microservices). Therefore, the node pair set can be considered as the result obtained when promoting / performing microservice refactoring on a monolithic application.

[0057] In various aspects, the mapping component can calculate a confidence score for each node pair in the node pair set. In various instances, for any given node pair, the confidence score can indicate how similar and / or dissimilar the two nodes listed in the given node pair are. In fact, as will be understood by those of ordinary skill in the art, when a first node from a model graph and a second node from a code graph are listed as being mapped / linked / associated with each other in a node pair group, this can mean that, of all the nodes in the code graph, the second node is the node that is closest (e.g., most similar and / or least similar) to the first node in the model graph. Therefore, two nodes may be very different from each other, despite being mapped / linked / associated with each other in a node pair set. In various cases, the confidence score can indicate how similar and / or dissimilar the two nodes are.

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

[0059] As another example, for any given node pair, the confidence score for the node pair can be a categorical variable obtained based on a supplemental textual / semantic comparison of the source code with the target domain model. For example, assume that a first node from the model graph is listed in a set of node pairs as being mapped / linked / related to a second node from the code graph. Furthermore, assume that the first node represents a specific service domain specified by the target domain model, and the second node represents a specific program written in the source code. In various aspects, the mapping component can parse the target domain model while searching for keywords associated with the specific service domain (e.g., keywords used in the definition / description of business capabilities satisfied by the specific service domain, keywords used in the definition / description of service domain interactions in which the specific service domain participates). Furthermore, in various instances, the mapping component can parse the source code to search for programs associated with these keywords (e.g., searching for programs whose method calls and / or coding comments significantly utilize these keywords). If such parsing reveals that no program written within the source code is more strongly associated with such a keyword than the particular program (e.g., if the supplemental natural language processing performed by the mapping component agrees that the first node and the second node should be mapped / linked / associated with each other), the confidence scores of the first node and the second node can be set to a "sure" category. Conversely, if such parsing instead reveals that some other program written within the source code is more strongly associated with such a keyword than the particular program (e.g., if the supplemental natural language processing performed by the mapping component does not believe that the first node and the second node should be mapped / linked / associated with each other), the confidence scores of the first node and the second node can instead be set to a "distrusted" category.

[0060] In any case, the mapping component can generate a set of node pairs (eg, reconstruction results) by aligning the code graph with the model graph, and the mapping component can generate confidence scores for such a set of node pairs in various instances.

[0061] In various embodiments, the execution component of the computerized tool can electronically transmit an electronic message to any suitable computing device, where the electronic message can indicate one or more node pairs in the set of node pairs. That is, in some cases, the execution component can electronically share with any suitable computing device the results obtained when facilitating / performing microservice refactoring on a monolithic application. In various other embodiments, the execution component of the computerized tool can electronically present one or more node pairs in the set of node pairs on any suitable computer display, screen, and / or monitor, making the set of node pairs visible to a user / technician. That is, in various cases, the execution component can electronically display the results obtained when facilitating / performing microservice refactoring on a monolithic application.

[0062] In various embodiments, the feedback component of the computerized tool can electronically access the feedback provided by the user about the node pair set. Specifically, in various aspects, the feedback component can send a request electronically to any suitable computing device, wherein such a request can indicate one or more node pairs in the node pair set, and wherein such a request can prompt the user of the computing device to approve and / or reject such one or more node pairs in the node pair set. In various instances, in response to the request, the feedback component can receive feedback provided by the user from the computing device, wherein such user-provided feedback can approve and / or reject such one or more node pairs in the pair of node pairs. In some cases, for rejected node pairs, the feedback provided by the user can indicate the corrected / updated node pairs that can replace such rejected node pairs, and the feedback component can rewrite the rejected node pairs accordingly to become corrected / updated node pairs. In some cases, the feedback component can subject all node pair sets to user review in this way (e.g., the user can be prompted for feedback on each node pair in the node pair set). In other cases, the feedback component may subject less than all of the node pairs set to user review in this manner (e.g., may avoid prompting the user for feedback regarding one or more node pairs). For example, in some cases, the feedback component may prompt the user for feedback only regarding those node pairs that exhibit insufficient confidence (e.g., only regarding those node pairs whose classification confidence scores are set to the "not sure" category; and / or only regarding those node pairs whose real-valued scalar confidence scores fail to meet any suitable threshold level).

[0063] In various embodiments, a gap component of a computerized tool may electronically identify one or more gaps between a code graph and a model graph via any suitable natural language processing technique and based on a node pair set. For example, for any two nodes listed as mappings / links / associations in the node pair set, one of the two nodes may represent a specific service domain specified by the target domain model, and the other of the two nodes may represent a specific program written in the source code. In various cases, the gap component may utilize a string search to determine whether there is a gap between the business capabilities of the specific service domain and the non-exposed method calls of the specific program. As a non-limiting example, the gap component may identify the business capabilities to be fulfilled / provided by the specific service domain via any suitable parsing technique. For each identified business capability, the gap component may parse a specific program to search for at least one non-exposed method call that matches and / or satisfies the identified business capability (e.g., including keywords identical to keywords included in the description of the identified business capability). If the gap component fails to find at least one non-exposed method call for any such identified business capability, the gap component may infer that there is a gap between the business capabilities of the specific service domain and the non-exposed method calls of the specific program, and the gap component may record and / or record the gap accordingly. As another non-limiting example, the gap component can identify service domain interactions to be initiated by the particular service domain via any suitable parsing technique. For each identified service domain interaction, the gap component can parse the particular program to search for at least one program-exposed method call that matches and / or satisfies the identified service domain interaction (e.g., includes keywords that are the same as keywords included in the description of the identified service domain interaction). If the gap component fails to find at least one program-exposed method call for any such identified service domain interaction, the gap component can infer that there is a gap between the service domain interaction of the particular service domain and the program-exposed method call of the particular program, and the gap component can record and / or log the gap accordingly.

[0064] In any case, the gap component can 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 can resolve such gaps electronically. In some cases, the execution component can resolve such gaps by generating and / or transmitting an electronic warning to any suitable computing device, wherein such electronic warnings may indicate the existence of such gaps, and / or wherein such electronic warnings may indicate that such gaps require attention / remediation. In other cases, the execution component can resolve these gaps by inserting one or more coding templates that resolve and / or fill these gaps into the source code (e.g., if the source code lacks a non-exposed method call corresponding to a specific business capability, the execution component can insert a pre-written non-exposed method call template that executes such a business capability into the source code).

[0065] Therefore, the various embodiments described herein may be considered as computerized tools that may facilitate monolith to microservice refactoring based on source code to domain model diagram comparison.

[0066] Various embodiments described herein may be employed to solve problems that are highly technical in nature (e.g., to facilitate monolith to microservice refactoring based on source code to domain model graph comparison) using hardware and / or software that are not abstract and cannot be performed as a set of mental actions by a person. In addition, some of the processes performed may be performed by a dedicated computer (e.g., source code parser, target domain model parser, 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 monolith application and a target domain model corresponding to the monolith application; and / or refactoring, by the device, the monolith application into microservices by aligning a first graph representing the source code with a second graph representing the target domain model.

[0067] Without a computer, the human mind cannot perform such defined tasks. Indeed, neither the human mind nor a person with a 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) representing the source code and target domain model, respectively, and electronically reconstruct the monolithic application by aligning the two graphs with each other (e.g., via a common embedding space technique, such as a graph convolutional neural network). Rather, such defined tasks are inherently and unavoidably associated with computer technology and cannot be implemented outside of a computing environment (e.g., a monolithic application is a collection of executable programs, where each program is a set of coded commands that can be compiled and / or run; thus, a monolithic application is an inherently computerized construct that cannot exist in a human mind or merely on paper; thus, a computer-implemented tool that can reconstruct a monolithic application into microservices is likewise an inherently computerized construct that cannot exist in any reasonable, practicable, or feasible manner without a computer).

[0068] In various cases, one or more embodiments described herein may integrate the concepts described herein into practical applications. As described above, some techniques for facilitating monolith to microservice refactoring may be bottom-up techniques. Such bottom-up techniques may not take into account external microservice information, which may cause such bottom-up techniques to produce unreliable refactoring results. Also as described above, other techniques for facilitating monolith to microservice refactoring may be top-down techniques. Although top-down techniques may implement a target domain model in order to take into account external microservice information, such top-down techniques may be a completely manual process that consumes months of time. In contrast, the embodiments described herein may include a monolith to microservice refactoring implemented by aligning a graph representing a monolith source code with another graph representing a target domain model. More specifically, such alignment may be facilitated by importing two graphs (e.g., via a graph convolutional neural network) into a common embedding space and then pairing / mapping / linking nodes between the two graphs based on Euclidean distance. Because such an embodiment can utilize a target domain model, such an embodiment can avoid the defects experienced by bottom-up techniques. In addition, because embedding-based graph alignment can be automated / computer-implemented, such an embodiment can consume much less time than top-down techniques. Therefore, the various embodiments described herein can be considered as concrete, tangible technical improvements in the field of microservices refactoring. Moreover, as described above, microservices refactoring can be considered as a useful and practical end in itself. After all, due to their huge size and tight internal coupling, monolithic applications often fail to exhibit the benefits of cloud native applications (e.g., scalability, continuous deployment, stateless deployment, agility, ease of troubleshooting), and such failures can be addressed through the performance of 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 this disclosure describe non-limiting examples of various embodiments. It should also be understood that the drawings are not necessarily drawn to scale.

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

[0071] In various aspects, the monolithic application 104 can be any suitable monolithic application. In various examples, source code 106, which can be written in any suitable coding language and / or using any suitable coding syntax, can include computer executable instructions and / or coding commands that make up the monolithic application 104. Figure 2 is shown in more detail in .

[0072] Figure 2 An example non-limiting block diagram 200 of source code 106 according to one or more embodiments described herein is shown. As shown, source code 106 may include a program set 202. In various aspects, program set 202 may include n programs for any suitable positive integer n: program 1 to program n. In various instances, the program of source code 106 may be a sequence of computer executable commands that may perform any suitable number of non-exposed method calls on any suitable number of data objects and / or may perform any suitable number of program exposed method calls. In various cases, the data object 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 call may be any suitable function, operation, calculation, and / or transformation that may be performed on the data object and may be self-contained (e.g., may be performed without interacting with and / or calling another program) . In contrast, a program exposed method call may be any suitable call, activation, and / or initiation of another program written in source code 106. As a non-limiting example, program 1 may execute any one of a set of non-exposed method calls 1 on any one of a set of data objects 1, wherein the set of non-exposed method calls 1 may include any suitable number of non-exposed method calls of any suitable type, and wherein the set of data objects 1 may include any suitable number of data objects of any suitable type. Furthermore, as shown, program 1 may execute any program-exposed method call 1 of a set of program-exposed method calls 1, each of which may invoke / activate any of the other n-1 programs written in source code 106. As another non-limiting example, program n may execute any one of a set of non-exposed method calls n on any one of a set of data objects n, wherein the set of non-exposed method calls n may include any suitable number of non-exposed method calls of any suitable type, and wherein the set of data objects n may include any suitable number of data objects of any suitable type. Furthermore, as shown, program n may execute any program-exposed method call n among a set of program-exposed method calls n, each of which may invoke / activate any of the other n-1 programs written in the source code 106 .

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

[0074] In various aspects, the target domain model 108 can be any suitable electronic document capable of specifying, describing, and / or otherwise defining (e.g., in natural language text) the capabilities and / or transaction structures that are expected to be provided by the monolithic application 104. Figure 3 is shown in more detail in .

[0075] Figure 3 An example non-limiting block diagram 300 of a target domain model 108 according to one or more embodiments described herein is shown. 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, where m is any suitable positive integer m: service domain 1 to service domain m. In some cases, m may be equal to n. In other cases, m may not be equal to n. In various instances, a service domain may be a description and / or specification of an inner cluster of business logic that is expected, expected, and / or otherwise assumed 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 that can be performed on a business object. Therefore, in various instances, a business capability may be considered a natural language simulation and / or description of a non-exposed method call, and a business object may be considered a natural language simulation and / or description of a data object. As a non-limiting example, as shown, service domain 1 may be expected to perform any business capability in a set of business capabilities 1 on any business object in a set of business objects 1, where the set of business capabilities 1 may include any suitable number of business capabilities of any suitable type, and where the set of business objects 1 may include any suitable number of business objects of any suitable type. Similarly, as shown, service domain m may be expected to perform any business capability in a set of business capabilities m on any business object in a set of business objects m, where the set of business capabilities m may include any suitable number of business capabilities of any suitable type, and where the set of business objects m may include any suitable number of business objects of any suitable type.

[0076] As further shown, the target domain model 108 can include a set of service domain interactions 304. In various aspects, the set of service domain interactions 304 can be a description / specification of which service domains in the target domain model 108 should call (e.g., should invoke, activate, and / or initiate) which other service domains in the target domain model 108. Thus, in various cases, the service domain interactions can be considered to be natural language analogs and / or descriptions of program-exposed method calls.

[0077] Despite Figure 3 , but the set of service domains 302 may be specified / described in a swagger definition portion of the target domain model 108, and the set of service domain interactions 304 may be specified / described in a transaction / process flow portion of the target domain model 108. As will be appreciated by one of ordinary skill in the art, some non-limiting example embodiments of the target domain model 108 may be a BIAN specification and / or an eTOM specification.

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

[0079] Despite Figure 3 , but each service domain in the set of service domains 302 may be known and / or otherwise considered to correspond to a corresponding microservice. For example, there may be a specific microservice that is known to facilitate and / or perform the set of business capabilities 1. Therefore, the specific microservice may be considered to correspond to and / or satisfy service domain 1. As another example, there may be a specific microservice that is known to facilitate / perform the set of business capabilities m, and therefore, the specific microservice may be considered to correspond to and / or satisfy service domain m. Therefore, each service domain specified in the target domain model 108 may be considered / considered to be associated with a microservice.

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

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

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

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

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

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

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

[0087] In various embodiments, the reconstruction system 102 can also include an execution component 124. In various cases, the execution component 124 can transmit any node pair in the set of node pairs to any suitable computing device and / or present any node pair on any suitable computer display, as described herein. In various other cases, the execution component 124 can insert one or more coding templates into the source code 106 to fill and / or fill one or more gaps identified by the gap component 122, as described herein.

[0088] Figure 4 A block diagram of an example non-limiting system 400 including a code map and / or a model map that can facilitate monolith to microservice refactoring via source code to domain model map comparison according to one or more embodiments described herein is shown. As shown, in some cases, system 400 can include the same components as system 100, and can also include a code map 402 and / or a model map 404.

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

[0090] Similarly, in various embodiments, the graph component 116 can electronically generate a model graph 404 based on the target domain model 108. Specifically, the graph component 116 can electronically parse the target domain model 108. As described above, such analysis can be static in some cases, dynamic in other cases, and / or both static and dynamic in yet another case. In any case, by parsing the target domain model 108, the graph component 116 can identify a set of service domains 302, can identify each business capability specified / defined for each service domain in the set of service domains 302, can identify each business object specified / defined for each service domain in the set of service domains 302, and / or can identify each service domain interaction in the set of service domain interactions 304. In various aspects, the graph component 116 can generate the model graph 404 based on such identification. As non-limiting examples, each node of the model graph 404 may represent a respective 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 a respective one of the set of service domain interactions 304 specified by the target domain model 108 .

[0091] This will refer to Figure 5-Figure 7 Further discussion.

[0092] First, consider Figure 5 As shown in the figure, Figure 5 A non-limiting block diagram 500 showing additional example details of a code graph 402 and / or a model graph 404 is depicted. In various aspects, as shown, the code graph 402 may include a code graph node set 502 and / or a code graph edge set 504. In various instances, as described above, the code graph 402 may include a unique node for each unique program written in the source code 106. Thus, because there may be n programs in the source code 106, there may be n nodes in the code graph node set 502: code graph node 1 that may represent program 1 to code graph node n that may represent program n. In various cases, also as described above, the code graph 402 may include a unique edge for each unique program exposed method call written in the source code 106. Thus, because there may be p programs exposed method calls in the source code 106, there may be p edges in the code graph edge set 504: code graph edge 1 that may represent the first program exposed method call written in the source code 106, to code graph edge p that may represent the pth program exposed method call written in the source code 106.

[0093] Likewise, in various aspects, the model graph 404 may include a model graph node set 506 and / or a model graph edge set 508. In various instances, as described above, the model graph 404 may include one unique node for each unique service domain specified in the target domain model 108. Thus, because there may be m service domains in the target domain model 108, there may be m nodes in the model graph node set 506: model graph node 1 may represent service domain 1, and model graph node m may represent service domain m. In various cases, as described above, the model graph 404 may include one unique edge for each unique service domain interaction specified in the target domain model 108. Thus, because there may be q service domain interactions in the target domain model 108, there may be q edges in the model graph edge set 508: model graph edge 1 that may represent a first service domain interaction specified in the target domain model 108 to model graph edge q that may represent a qth service domain interaction specified in the target domain model 108.

[0094] Next, consider Figure 6 . Figure 6An example non-limiting view 600 of the code graph 402 is shown. For purposes of explanation, assume that the source code 106 includes seven programs: program 602, program 604, program 606, program 608, program 610, program 612, and program 614. Further, assume that the source code 106 includes seven program-exposed method calls: program-exposed method call 616 from program 602 to program 604, program-exposed method call 618 from program 602 to program 606, program-exposed method call 620 from program 602 to program 608, program-exposed method call 622 from program 604 to program 610, program-exposed method call 624 from program 606 to program 612, program-exposed method call 626 from program 608 to program 606, and program-exposed method call 628 from program 608 to program 614. In this 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. In addition, in this 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 can build the code graph 402 by parsing the source code 106 and by identifying the programs written within the source code 106 and the program exposed method calls.

[0095] Now, consider Figure 7 . Figure 7An example non-limiting view 700 of the model diagram 404 is shown. 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. Furthermore, assume that the 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 this case, as shown in the figure, 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. In addition, in this case and as shown in the figure, model graph 404 may include: a directed edge pointing from the node representing service domain 702 to the node representing service domain 704, a directed edge pointing from the node representing service domain 702 to the node representing service domain 706, a directed edge pointing from the node representing service domain 702 to the node representing service domain 708, a directed edge pointing from the node representing service domain 704 to the node representing service domain 710, a directed edge pointing from the node representing service domain 706 to the node representing service domain 712, a directed edge pointing from the node representing service domain 706 to the node representing service domain 708, and a directed edge pointing from the node representing service domain 710 to the node representing service domain 712. In this manner, the graph component 116 can build the model graph 404 by parsing the target domain model 108 and by identifying the service domains and service domain interactions specified in the target domain model 108 .

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

[0097] In addition, in various aspects, as described above, the graph component 116 can dynamically parse the source code 106. More specifically, the graph component 116 can analyze the source code 106 during the runtime of the source code 106, thereby generating different execution traces and / or production logs of the source code 106. In various instances, such different execution traces and / or production logs can indicate different program-to-program interaction sequences that can be implemented by the source code 106 (for example, it can indicate that the source code 106 can execute different orders of the assembly 202 in different contexts). In some cases, such different program-to-program interaction sequences can be referred to as different program transactions. In any case, the edge weights of the code graph 402 can be based on such different program-to-program interaction sequences. For example, some program-exposed method calls can exist in a larger proportion of such different program-to-program interaction sequences. Therefore, the edges of the code graph 402 representing such more frequently executed program-exposed method calls can have heavier weights. On the other hand, some program-exposed method calls can exist in a smaller proportion of such different program-to-program interaction sequences. Therefore, the edges of the code graph 402 representing such less frequently executed program-exposed method calls may have lighter weights.

[0098] Figure 8 A block diagram of an example non-limiting system 800 including a set of node pairs that can facilitate monolith to microservice refactoring via source code to domain model graph comparison according to one or more embodiments described herein is shown. As shown, in some cases, system 800 can include the same components as system 400, and can also include a set of node pairs 802.

[0099] In various embodiments, the mapping component 118 can electronically generate a node pair set 802 based on the code graph 402 and the model graph 404. More specifically, the mapping component 118 can align the code graph 402 with the model graph 404 to identify which nodes of the code graph 402 are most similar to which nodes of the model graph 404, and the result of such alignment can be the node pair set 802. In some examples, the mapping component 118 can facilitate such alignment by implementing a common embedding space technique. This will refer to Figure 9-12 Explain in more detail.

[0100] First, consider Fig. 9, which shows an example non-limiting block diagram 900 showing how a code graph 402 can be imported into an embedding space. In various embodiments, the mapping component 118 can electronically store, electronically maintain, electronically control, and / or otherwise electronically access a graph convolutional neural network 902 (e.g., hereinafter referred to as "GCN 902"). In various aspects, the GCN 902 can exhibit any suitable internal architecture. That is, the GCN 902 can include any suitable number and / or type of layers, any suitable number of neurons in each layer, any suitable activation function in each neuron, and / or any suitable interneuron connection. In any case, the GCN 902 can be configured to receive a graph as input and produce an embedded node-by-node representation of the input graph as output. As will be understood by one of ordinary skill in the art, the embedded representation of a graph node can be a vector having any suitable dimension (e.g., any suitable number of elements), such that the value / magnitude of the elements of the vector can depend on the attributes, characteristics, and / or edges of the graph node. As will be further appreciated by one of ordinary skill in the art, GCN 902 may learn to generate accurate embedded node-by-node representations by undergoing any suitable training type / paradigm (e.g., supervised training, unsupervised training, reinforcement learning), any suitable training batch size, any suitable objective function, and / or any suitable training termination criterion.

[0101] Thus, in various aspects, the mapping component 118 can perform the GCN 902 on the code graph 402, and the result can be a set of embedded node-by-node representations 904. More specifically, the input layer of the GCN 902 can receive the code graph 402, the code graph 402 can complete a forward pass through one or more hidden layers of the GCN 902, and the output layer of the GCN 902 can calculate a set of embedded node-by-node representations 904 based on the activations generated by the one or more hidden layers. In various examples, as shown, the set of embedded node-by-node representations 904 can correspond to the code graph node set 502, respectively. That is, because the code graph node set 502 can include n nodes, the set of embedded node-by-node representations 904 can include n embeddings: the embedded representation of code graph node 1 to the embedded representation of code graph node n. As described above, the embedded representation of code graph node 1 can be a real-valued vector of any suitable dimension, where the elements of such vector can depend on the attributes, characteristics, and / or edges of code graph node 1, and similarly, the embedded representation of code graph node n can be a real-valued vector of any suitable dimension, where the elements of such vector can depend on the attributes, characteristics, and / or edges of code graph node n. In various aspects, the set of embedded node-by-node representations 904 can have the same dimensions as each other.

[0102] Now, consider Fig.10, which illustrates an example non-limiting block diagram 1000 illustrating how a model graph 404 may be imported into the same embedding space as a code graph 402. In various embodiments, as shown, the mapping component 118 may perform the GCN 902 on the model graph 404, and the result may be a set of embedded node-by-node representations 1002. More specifically, an input layer of the GCN 902 may receive the model graph 404, the model graph 404 may complete a forward pass through one or more hidden layers of the GCN 902, and an output layer of the GCN 902 may compute a set of embedded node-by-node representations 1002 based on activations generated by the one or more hidden layers. In various instances, as shown, the set of embedded node-by-node representations 1002 may correspond to the model graph node sets 506, respectively. That is, because the model graph node set 506 may include m nodes, a set of embedded node-by-node representations 1002 may include m embeddings: an embedded representation of model graph node 1 to an embedded representation of model graph node m As described above, the embedded representation of model graph node 1 may be a real-valued vector of any suitable dimension, where the elements of such a vector may depend on the attributes, characteristics and / or edges of model graph node 1, and similarly, the embedded representation of model graph node m may be a real-valued vector of any suitable dimension, where the elements of such a vector may depend on the attributes, characteristics and / or edges of model graph node m. In various aspects, the set of embedded node-by-node representations 1002 may have the same dimensions as each other.

[0103] Because both the set of embedded node-by-node representations 904 and the set of embedded node-by-node representations 1002 can be generated by the GCN 902, each embedded node-by-node representation in the set of embedded node-by-node representations 1002 can have the same dimensions as each embedded node-by-node representation in the set of embedded node-by-node representations 904, so that vector arithmetic can be performed between the set of embedded node-by-node representations 904 and the set of embedded node-by-node representations 1002. In other words, the GCN 902 can be considered to import 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 with the embedded representation of the model graph 404. In other words, when given a node from the model graph 404 and another node from the code graph 402, the embedded representations of the two nodes can be similar when the two nodes have similar attributes, characteristics, and / or edges, and the embedded representations of the two nodes can be dissimilar when the two nodes have dissimilar attributes, characteristics, and / or edges.

[0104] Although the present invention mainly describes an embodiment in which the mapping component 118 generates a set of embedded node-by-node representations 904 and / or a set of embedded node-by-node representations 1002 via the GCN 902, this is only a non-limiting example to facilitate explanation. In various aspects, the mapping component 118 can implement any other suitable embedded representation learning technology to generate a set of embedded node-by-node representations 904 and / or a set of embedded node-by-node representations 1002.

[0105] Now, consider Fig.11 , which shows an example non-limiting block diagram 1100 illustrating how to generate the set of node pairs 802 based on the set of embedded node-by-node representations 904 and / or the set of embedded node-by-node representations 1002 .

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

[0107] For example, the mapping component 118 may identify a node in the code graph 402 that has an embedded representation that is closest to / closest to the model graph node 1, and such an identified node may be referred to as the mapped code graph node 1 (note that such an identified node is not necessarily Figure 5 In various examples, the mapping component 118 can thus create a node pair 1 in the node pair collection 802, where the node pair 1 can be any suitable electronic record indicating that the model graph node 1 is linked / associated with the mapped code graph node 1.

[0108] As another example, the mapping component 118 may identify which node in the code graph 402 has an embedded representation that is closest to / closest to the model graph node m, and such identified node may be referred to as the mapped code graph node m (note that such identified node is not necessarily Figure 5 In various cases, as described above, the mapping component 118 can therefore create a node pair m in the node pair collection 802, where the node pair m can be any suitable electronic record indicating that the model graph node m is linked / associated with the mapped code graph node m.

[0109] Although various embodiments of the mapping component 118 generating the node pair set 802 via the common embedding space technique (e.g., through the GCN 902) are mainly described herein, this is only a non-limiting example to facilitate explanation. In various instances, the mapping component 118 can generate the node pair set 802 by utilizing any other suitable graph alignment technique, such as a subgraph kernel technique.

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

[0111] As a non-limiting example, node pair 1 may indicate that model graph node 1 is linked / associated with mapped code graph node 1, which may be considered as indicating / conveying that service domain 1 (and therefore microservices known / believed to correspond to service domain 1) is linked / associated with 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 / associated with mapped code graph node m, which may be considered as indicating / conveying that service domain m (and therefore microservices known / believed to correspond to service domain m) is linked / associated with the program represented by mapped code graph node m.

[0112] In any case, the node pair set 802 can be considered to indicate which programs of the source code 106 correspond to which known microservices. Therefore, the node pair set 802 can be considered to indicate how the monolithic application 104 can be refactored into microservices. That is, the node pair set 802 can be considered to be the result obtained when performing / facilitating microservice refactoring 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 of the model graph 404 and nodes of the code graph 402. For example, it may be the case that a node in the code graph 402 cannot be mapped / linked / associated to any node in the model graph 404 (e.g., in which case the program represented by the node may be considered to not satisfy / embody any service domain specified in the target domain model 108). As another example, it may be the case that a node in the code graph 402 may be mapped / linked / associated to more than one node from the model graph 404 (e.g., in which case the program represented by the node may be considered to satisfy / embody multiple service domains specified in the target domain model 108).

[0114] In various embodiments, the mapping component 118 can generate a confidence score for each node pair in the node pair set 802. This will refer to Fig.12 For more discussion. As shown in the figure,

[0115] Fig.12 An example non-limiting block diagram 1200 is shown that illustrates how confidence scores are generated for a set of node pairs 802 .

[0116] In various aspects, the mapping component 118 can generate a confidence score 1 for the node pair 1. In some instances, the confidence score 1 can be a real-valued scalar whose magnitude can indicate how similar and / or dissimilar the model graph node 1 is to the mapped code graph node 1. In fact, in this case, the mapping component 118 can determine the Euclidean distance that separates 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 can be inversely proportional to the Euclidean distance. In other instances, the confidence score 1 can be a categorical variable generated based on a supplementary text / semantic analysis of the source code 106 and / or the target domain model 108. For example, in this case, the mapping component 118 can parse the target domain model 108 when searching for keywords associated with the service domain represented by the model graph node 1, and the mapping component 118 can parse the source code 106 when searching for annotations and / or method calls that utilize these keywords. If this analysis identifies the program represented by the mapped code graph node 1, the confidence score 1 can be set to a "confident" state. On the other hand, if such analysis identifies a program other than that represented by mapped code graph node 1, then confidence score 1 may be set to an "unsure" state.

[0117] In some cases, the confidence score m can be a real-valued scalar whose magnitude can indicate how similar and / or dissimilar the model graph node m is to the mapped code graph node m. In other cases, the confidence score m can be a categorical variable generated based on supplementary text / semantic analysis of the source code 106 and / or the target domain model 108. As described above, in this case, the mapping component 118 can parse the target domain model 108 when searching for keywords associated with the service domain represented by the model graph node m, and the mapping component 118 can parse the source code 106 when searching for annotations and / or method calls that utilize these keywords. If this analysis identifies the program represented by the mapped code graph node m, the confidence score 1 can be set to a "confident" state. On the other hand, if this analysis identifies a program different from the program represented by the mapped code graph node m, the confidence score m can be set to an "unsure" state.

[0118] Fig.13 A block diagram of an example non-limiting system 1300 including feedback that can facilitate monolith to microservice refactoring via source code to domain model diagram comparison according to one or more embodiments described herein is shown. As shown, in some cases, system 1300 can include the same components as system 800, and can also include feedback 1302.

[0119] In various embodiments, the feedback component 120 may send the node pair set 802 to any suitable computing device (not shown), and the feedback component 120 may prompt a user of the computing device to approve and / or reject any of the node pairs in the node pair set 802. In response to such prompting, the feedback component 120 may electronically receive, retrieve, and / or otherwise access feedback 1302 from such a computing device. In various aspects, the feedback 1302 may be any suitable electronic data that approves and / or rejects any of the node pairs in the node pair set 802. In some cases, for any node pair that is rejected, the feedback 1302 may indicate an updated and / or otherwise corrected node pair. In this case, the feedback component 120 may replace the rejected node pair in the node pair set 802 with the updated / corrected node pair. In some cases, the feedback component 120 may prompt a user for feedback on all node pair sets 802 in this manner. In other cases, the feedback component 120 can prompt the user for feedback on less than all of the node pair sets 802 in this manner (e.g., feedback can be requested only for those node pairs whose scalar confidence scores fail to meet a threshold level and / or whose classification confidence scores are set to an “unsure” state).

[0120] Fig.14 A block diagram of an example non-limiting system 1400 including a set of gaps that can facilitate monolith to microservice refactoring via source code to domain model diagram comparison according to one or more embodiments described herein is shown. As shown, in some cases, system 1400 can include the same components as system 1300, and can also include a set of gaps 1402.

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

[0122] Fig.15An example non-limiting block diagram 1500 is shown, which shows how to identify gaps between business capabilities and non-exposed method calls. In various embodiments, the node pair 1502 can be any one of the node pairs in the node pair set 802. As shown, the node pair 1502 can indicate that the model graph node 1504 is linked / associated with the mapped code graph node 1506. For the purpose of illustration, it is assumed that the model graph node 1504 represents the account recovery service domain 1508 specified in the target domain model 108, and it is also assumed that the mapped code graph node 1506 represents the account recovery program 1512 written in the source code 106. In various instances, the account recovery service domain 1508 can be responsible for executing a set of account recovery business capabilities 1510. As some non-limiting examples, the account recovery business capability set 1510 may include an "activation" capability, an "initiate" capability, a "retrieval" capability, and / or an "update" capability. In addition, the account recovery program 1512 may include a set of account recovery non-exposed method calls 1514. As some non-limiting examples, the set of account recovery non-exposed 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 account recovery business capability set 1510 to identify relevant keywords (e.g., “activate,” “initiate,” “retrieve,” “update”), and the gap component 122 may utilize string searches and / or any other suitable natural language processing techniques to search for such relevant keywords in the account recovery non-exposed method calls 1514. If there are any relevant keywords in the account recovery business capability set 1510 that are not found within the set of account recovery non-exposed method calls 1514, the gap component 122 may infer that there is a gap between the account recovery service domain 1508 and the account recovery program 1512, and the gap component 122 may record / log the gap in the gap set 1402. Fig.15 In a non-limiting example, the keyword analysis / string search may conclude that the set of account recovery non-exposed method calls 1514 fails to include a method call corresponding to a “retrieve” capability specified in the set of account recovery business capabilities 1510 .

[0123] Fig.16An example non-limiting block diagram 1600 is shown, which shows how to identify gaps between service domain interactions and method calls exposed by programs. In various embodiments, node pairs 1502, model graph nodes 1504, mapped code graph nodes 1506, account recovery service domains 1508, and account recovery programs 1512 can be as described above. In various aspects, the account recovery service domain 1508 can be expected / expected to participate in a set of account recovery service domain interactions 1602. As some non-limiting examples, a set of account recovery service domain interactions 1602 may include interactions with the "company current account" service domain, interactions with the "location maintenance" service domain, and interactions with the "product catalog" service domain. In addition, the account recovery program 1512 may include a set of method calls 1604 exposed by the account recovery program. As some non-limiting examples, the method calls 1604 exposed by the account recovery program may include calls to the "company current account" program and calls to the "product catalog" program. In various cases, the gap component 122 can parse the set of account recovery service domain interactions 1602 to identify relevant keywords (e.g., "company current account", "position maintenance", "product catalog"), and the gap component 122 can utilize string searching and / or any other suitable natural language processing techniques to search for these relevant keywords in the account recovery program exposure method calls 1604. If there are any relevant keywords in the set of account recovery service domain interactions 1602 that are not found in the set of account recovery program exposure method calls 1604, the gap component 122 can conclude that there is a gap between the account recovery service domain 1508 and the account recovery program 1512, and the gap component 122 can record / record the gap in a set of collections 1402. Fig.16 In a non-limiting example, keyword analysis / string search may infer that the method calls 1604 exposed by the set of account recovery programs fail to include a call to a program corresponding to the “place keeping” service domain specified in the set of account recovery service domain interactions 1602 .

[0124] Fig.17 A block diagram of an example non-limiting system 1700 including a set of coding templates that can facilitate monolith to microservice refactoring via source code to domain model diagram comparison according to one or more embodiments described herein is shown. As shown, in some cases, system 1700 can include the same components as system 1400, and can also include a set of coding templates 1702.

[0125] In various embodiments, because the node pair set 802 can be considered a microservice reconstruction result, the execution component 124 can electronically share the node pair set 802 (and / or a subset thereof) so that subsequent decisions about microservice reconstruction can be made for the monolithic application 104. For example, in some cases, the execution component 124 can send the node pair set 802 (or a subset thereof) to any suitable computing device (not shown). As another example, in some cases, the execution component 124 can present the node pair set 802 (or a subset thereof) on any suitable computing monitor / screen (not shown). In some instances, such transmission and / or presentation can be considered an electronic recommendation to reconstruct the monolithic application 104 based on the node pair set 802 (e.g., as an electronic recommendation to replace / substitute programs of the source code 106 with known microservices based on which programs of the source code 106 correspond to which service domains specified by the target domain model 108). Furthermore, in some cases, the execution component 124 can similarly transmit to any suitable computing device and / or present on any suitable computer display / monitor a set of gaps 1402 (or a subset thereof) to notify a user of any identified mismatches between the source code 106 and the target domain model 108 .

[0126] In addition, in various aspects, the execution component 124 can electronically store, maintain and / or otherwise access the set of coding templates 1702, and the execution component 124 can selectively insert any one of the coding templates in the set of coding templates 1702 into the source code 106 to fill and / or otherwise address a set of gaps 1402. In other words, the set of coding templates 1702 can be any suitable sequence of pre-written and / or pre-classified computer executable instructions (e.g., can be pre-written non-exposed method calls, can be pre-written program exposed method calls). In various aspects, the execution component 124 can electronically identify (e.g., via keyword matching) which one of the set of coding templates 1702 will resolve and / or fill a set of gaps 1402, and the execution component 124 can electronically insert this identified coding template into the source code 106. In this way, the execution component 124 can help improve the set of gaps 1402 (e.g., can help improve the mismatch that has been identified between the source code 106 and the target domain model 108).

[0127] Figure 18-Figure 21 Flowcharts of example, non-limiting computer-implemented methods 1800, 1900, 2000, and 2100 are shown that can facilitate monolith to microservice refactoring via source code to domain model diagram comparison according to one or more embodiments described herein. In various cases, the refactoring system 102 can facilitate the computer-implemented methods 1800-2100.

[0128] In various embodiments, act 1802 may include accessing, by a device (eg, 114) operatively coupled to a processor, the monolithic source code (eg, 106) and the reference domain model (eg, 108).

[0129] In various aspects, act 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, the nodes of the first graph may represent programs written in the monolithic source code, and the edges of the first graph may represent method calls exposed by the programs written in the monolithic source code.

[0130] In various examples, action 1806 can 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 can represent service domains specified by the reference domain model, and edges of the second graph can represent service domain interactions specified by the reference domain model.

[0131] In various aspects, act 1808 may include performing, by a device (e.g., via 118), a graph convolutional neural network (e.g., 902) on the first graph, thereby generating an embedded representation of nodes of the first graph (e.g., 904).

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

[0133] In various embodiments, act 1902 may include initializing, by the device (eg, via 118), a set of mapped node pairs (eg, 802). The set may initially be empty.

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

[0135] In various examples, act 1906 can include selecting, by the device (eg, via 118 ), a node from the second graph that has not been mapped to any node in the first graph.

[0136] In various cases, act 1908 may include identifying, by the device (eg, via 118 ), a node in the first graph whose embedded representation is closest (eg, in terms of Euclidean distance) to an embedded representation of a node selected from the second graph.

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

[0138] In various embodiments, action 2002 may include user-provided feedback (e.g., 1302) accessed by a device (e.g., via 120) to approve or adjust the set of mapped node pairs. In various cases, for each mapped node pair, a confidence score (e.g., one of 1202) may be calculated based on Euclidean distance and / or semantic / keyword analysis, and the user may be prompted for feedback regarding those mapped node pairs whose confidence scores are below any suitable threshold level.

[0139] In various aspects, action 2004 may include sending, by the device (e.g., via 124) to any suitable computing device and / or presenting, 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 have been 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., may be considered 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 may be known / considered to correspond to one or more microservices). As shown, computer-implemented method 2000 may proceed to action 2102 of computer-implemented method 2100.

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

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

[0142] In various instances, action 2108 can include detecting, by the device (e.g., via 122), one or more attribute gaps (e.g., some of the attribute gaps in 1402) between the first node and the second node by semantically comparing business capabilities specified by a reference domain model for the service domain (e.g., 1510) with non-exposed method calls written in the program (e.g., 1514).

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

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

[0145] Fig. 22 A flow chart illustrating an example non-limiting computer-implemented method 2200 that can facilitate monolith to microservice refactoring via source code to domain model graph comparison according to one or more embodiments described herein. In various circumstances, the refactoring system 102 can facilitate the computer-implemented method 2200 .

[0146] In various embodiments, act 2202 may include accessing, by a device operatively coupled to a 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.

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

[0148] Despite Fig. 22 Not explicitly shown, but the computer-implemented method 2200 may also include: generating, by the device (e.g., via 116), the first graph by parsing the source code in a search for a program (e.g., 202) and method calls exposed by the program, wherein the nodes (e.g., 502) of the first graph respectively represent the program, and wherein the edges (e.g., 504) of the first graph respectively represent method calls exposed by the program; and generating, by the device (e.g., via 116), the second graph by parsing the target domain model in a search for service domains (e.g., 302) and service domain interactions (e.g., 304), wherein the nodes (e.g., 506) of the second graph respectively represent service domains, and wherein the edges (e.g., 508) of the second graph respectively represent service domain interactions.

[0149] Despite Fig. 22 Although not shown in FIG. 8 , aligning the first graph with the second graph may generate a set of node pairs (eg, 802 ) that respectively map nodes of the first graph to nodes of the second graph, wherein the nodes of the second graph respectively correspond to microservices.

[0150] Those of ordinary skill in the art will appreciate that the disclosure herein describes non-limiting examples of various embodiments. To facilitate description and / or explanation, the various parts disclosed herein use the term "each" when discussing various embodiments. Those of ordinary skill in the art will appreciate that this use of the term "each" is a non-limiting example. In other words, when the disclosure herein provides a description of "each" applied to some specific 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, it may be that such a description is applied to less than "each" of the specific object and / or component.

[0151] To provide additional context for the various embodiments described herein, Fig.23 The following discussion is intended to provide a brief, general description of a suitable computing environment 2300 in which various embodiments described herein may be implemented. Although the embodiments are 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 conjunction with other program modules and / or as a combination of hardware and software.

[0152] Generally, program modules include routines, programs, components, data structures, etc. that perform specific tasks or implement specific abstract data types. In addition, those skilled in the art will appreciate that the methods of the present invention can be implemented with other computer system configurations, including single-processor or multi-processor computer systems, minicomputers, mainframe computers, Internet of Things (IoT) devices, distributed computing systems, as well as personal computers, handheld computing devices, microprocessor-based or programmable consumer electronics, etc., each of which can be operably coupled to one or more associated devices.

[0153] The illustrated embodiments of the 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.

[0154] Computing devices typically include various media, which may include computer-readable storage media, machine-readable storage media, and / or communication media, the two terms being used differently from each other herein as follows. Computer-readable storage media or machine-readable storage media may be any available storage media that can be accessed by a computer, and include volatile and non-volatile media, removable and non-removable media. By way of example and not limitation, computer-readable storage media or machine-readable storage media may be implemented in conjunction with any method or technology for storing information such as computer-readable or machine-readable instructions, program modules, structured data, or unstructured data.

[0155] Computer-readable storage media may include, but are 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 disk read-only memory (CD-ROM), digital versatile disk (DVD), Blu-ray disk (BD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, solid-state drives or other solid-state storage devices, or other tangible and / or non-transitory media that may be used to store the desired information. In this regard, the terms "tangible" or "non-transitory" herein as applied to storage, memory, or computer-readable media will be understood to exclude only the propagation of transitory signals themselves as modifiers, and not merely disclaim all standard storage, memory, or computer-readable media that propagate transitory signals themselves.

[0156] Computer-readable storage media may be accessed by one or more local or remote computing devices, such as via access requests, queries, or other data retrieval protocols, to perform various operations on the information stored by the media.

[0157] Communication media typically embodies computer readable instructions, data structures, program modules, or other structured or unstructured data in a data signal such as a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery or transmission media. The term "modulated data signal" or multiple signals refers to a signal that has one or more characteristics set or changed in a manner that encodes information in one or more 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.

[0158] Reference again Fig.23 , an example environment 2300 for implementing various embodiments of aspects described herein includes a computer 2302, which includes 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 used as the processing unit 2304.

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

[0160] The computer 2302 also 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, such as a solid state drive, an optical drive, etc., which can read or write from a disk 2322 such as a CD-ROM disk, a DVD, a BD, etc. Although the internal HDD 2314 is shown as being located within 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 the HDD 2314 or in place of the HDD. The HDD 2314, external storage device(s) 2316, and drive 2320 may be connected to the system bus 2308 via a HDD interface 2324, an external storage interface 2326, and a drive interface 2328, respectively. The 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.

[0161] The drives and their associated computer-readable storage media provide non-volatile storage of data, data structures, computer-executable instructions, etc. For the computer 2302, the drives and storage media accommodate the storage of any data in an appropriate digital format. Although the above description of computer-readable storage media refers to corresponding types of storage devices, it should be understood by those skilled in the art that other types of computer-readable storage media, whether currently existing or developed in the future, may also be used in the example operating environment, and further, any such storage media may contain computer-executable instructions for performing the methods described herein.

[0162] 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. All or portions of the operating system, applications, modules, and / or data may also 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.

[0163] Computer 2302 may optionally include emulation technology. For example, a hypervisor (not shown) or other intermediary may emulate the hardware environment of operating system 2330, and the emulated hardware may optionally be different from the hardware of the operating system 2330. Fig.23. In addition, the operating system 2330 can provide a runtime environment, such as a Java runtime environment or a .NET framework for application 2332. The runtime environment is a consistent execution environment that allows application 2332 to run on any operating system that includes a runtime environment. Similarly, the operating system 2330 can support containers, and the application 2332 can be in the form of a container, which is a lightweight, independent, executable software package that includes, for example, code, runtime, system tools, system libraries, and settings for the application.

[0164] In addition, the computer 2302 can be enabled with a security module, such as a trusted processing module (TPM). For example, with a TPM, the boot component hashes the next at the time of the boot component, and waits for the result to match the security value before loading the next boot component. This process can occur at any layer in the code execution stack of the computer 2302, for example, applied at the application execution level or the operating system (OS) kernel level, thereby achieving security at any code execution level.

[0165] A user may 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) may 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 a virtual reality headset, a game pad, a stylus, an image input device (e.g., camera(s)), a gesture sensor input device, a visual movement sensor input device, an emotion or facial detection device, a biometric input device (e.g., a fingerprint or iris scanner), etc. These and other input devices are typically connected to the processing unit 2304 through an input device interface 2344, which may be coupled to the system bus 2308, but may also be connected through 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.

[0166] 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.

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

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

[0169] When used in a WAN networking environment, the computer 2302 may include a modem 2360, or may be connected to a communication server on the WAN 2356 by other means to establish communications over the WAN 2356, such as over the Internet. The modem 2360 may be internal or external, a wired or wireless device, and it may be connected to the system bus 2308 via the input device interface 2344. In a networked environment, program modules described 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 the computers may be used.

[0170] When used in a LAN or WAN networking environment, the computer 2302 can access a cloud storage system or other network-based storage system, in addition to or in lieu of the external storage device 2316 described above, such as, but not limited to, a network virtual machine that provides one or more aspects of storage or processing of information. Typically, the connection between the computer 2302 and the cloud storage system can be established over the LAN 2354 or WAN 2356, for example, via an adapter 2358 or a modem 2360, respectively. When the computer 2302 is connected to the associated cloud storage system, the external storage interface 2326 can manage the storage provided by the cloud storage system, with the help of the adapter 2358 and / or the modem 2360, as it manages other types of external storage. For example, the external storage interface 2326 can be configured to provide access to cloud storage sources as if those sources were physically connected to the computer 2302.

[0171] Computer 2302 may be operable to communicate with any wireless device or entity that is operatively arranged in wireless communications, such as printers, scanners, desktop and / or portable computers, portable data assistants, communication satellites, any device or location associated with a wirelessly detectable tag (e.g., a public telephone booth, a kiosk, a store shelf, etc.), and a telephone. This may include Wireless Fidelity (Wi-Fi) and Bluetooth wireless technologies. Thus, the communications may be a predefined structure such as a conventional network, or simply an ad hoc communication between at least two devices.

[0172] Reference now Fig.24 , depicts an illustrative cloud computing environment 2400. As shown, cloud computing environment 2400 includes one or more cloud computing nodes 2402 with which local computing devices used by cloud computing consumers can communicate, such as, for example, personal digital assistants (PDAs) or cellular phones 2404, desktop computers 2406, laptop computers 2408, and / or automotive computer systems 2410. Nodes 2402 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as private clouds, community clouds, public clouds, or hybrid clouds, or combinations thereof, as described above. This allows cloud computing environment 2400 to provide infrastructure, platforms, and / or software as services for which cloud consumers do not need to maintain resources on local computing devices. It should be understood that Fig.24 The types of computing devices 2404-2410 shown in are exemplary only, and computing node 2402 and cloud computing environment 2400 can communicate with any type of computing device over any type of network and / or network-addressable connection (eg, using a web browser).

[0173] Reference now Fig.25, showing a cloud computing environment 2400 ( Fig.24 ) provides a set of functional abstraction layers. For the sake of brevity, repeated descriptions of similar elements used in other embodiments described herein are omitted. It should be understood in advance that Fig.25 The components, layers, and functions shown in are intended to be illustrative only, and the embodiments described herein are not limited thereto. As described, the following layers and corresponding functions are provided.

[0174] The hardware and software layer 2502 includes hardware and software components. Examples of hardware components include: host 2504; server 2506 based on RISC (Reduced Instruction Set Computer) architecture; server 2508; blade server 2510; storage device 2512; and network and networking components 2514. In some embodiments, software components include network application server software 2516 and database software 2518.

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

[0176] In one example, the management layer 2532 may provide the functionality described below. Resource provisioning 2534 provides dynamic procurement of computing resources and other resources used to perform tasks within a cloud computing environment. Metering and pricing 2536 provides cost tracking when utilizing resources within a cloud computing environment, as well as bills or invoices for consuming these resources. In one example, these resources may include application software licenses. Security provides authentication for cloud consumers and tasks, as well as protection for 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 the required service levels are met. Service level agreement (SLA) planning and fulfillment 2542 provides pre-scheduling and procurement of cloud computing resources, where future demand is predicted based on the SLA.

[0177] Workload layer 2544 provides examples of functionality that can take advantage of a cloud computing environment. Examples of workloads and functionality that can be provided from this layer include: mapping and navigation 2546; software development and lifecycle management 2548; virtual classroom education delivery 2550; data analytics processing 2552; transaction processing 2554; and differential private federated learning processing 2556. The various embodiments described herein can utilize reference Fig.24 and Fig.25 The cloud computing environment described herein is used to perform one or more differentially private federated learning processes according to various embodiments described herein.

[0178] Flowcharts and block diagrams in the accompanying drawings show the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present invention.In this regard, each frame in a flow chart or a block diagram can represent a module, a segment or a part of an instruction, which includes one or more executable instructions for realizing the logical function of (multiple) specified.In some alternative embodiments, the function noted in the frame may not occur in the order noted in the figure.For example, two frames shown continuously can actually be performed substantially simultaneously, or these frames can sometimes be performed in reverse order, depending on the function involved.It will also be noted that the combination of the frames in each frame of the block diagram and / or the flow chart diagram and the block diagram and / or the flow chart diagram can be realized by a dedicated hardware-based system that performs a specified function or action or performs a combination of special hardware and computer instructions.

[0179] In addition, 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 employs A or B" is intended to mean any natural inclusive arrangement. That is, if X employs A; X employs B; or X employs both A and B, then "X employs A or B" is satisfied in any of the foregoing instances. In addition, unless otherwise specified or clear from the context to refer to the singular form, the articles "one" and "an" as used in this specification and the drawings should generally be interpreted as meaning "one or more". As used herein, the terms "example" and / or "exemplary" are used to indicate use as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited to these examples. In addition, any aspect or design described herein as "example" and / or "exemplary" is not necessarily to be construed as being preferred or advantageous over other aspects or designs, nor is it meant to exclude equivalent exemplary structures and techniques known to those of ordinary skill in the art.

Claims

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

2. The system of claim 1, wherein the computer executable components further comprise: A graph component that: generating the first graph by parsing the source code in search of programs and program-exposed method calls, wherein nodes of the first graph respectively represent the programs, and wherein edges of the first graph respectively represent the program-exposed method calls; and The second graph is generated by parsing the target domain model in a search of service domains and service domain interactions, wherein nodes of the second graph respectively represent the service domains, and wherein edges of the second graph respectively represent the service domain interactions.

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

4. The system of claim 1, wherein aligning the first graph with the second graph generates a set of node pairs, the set of node pairs respectively mapping nodes of the first graph to nodes of the second graph, wherein the nodes of the second graph respectively correspond to the microservices.

5. The system of claim 4, wherein the mapping component aligns the first graph with the second graph based on a Euclidean distance that separates an embedded node-by-node representation of the first graph from an embedded node-by-node representation of the second graph, respectively.

6. The system of claim 4, wherein the computer executable components further comprise: A feedback component accesses user-provided feedback, wherein the user-provided feedback accepts or rejects at least one node pair in the set of node pairs.

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

8. The system according to claim 7, wherein: The gap component determines that there is a gap between the non-exposed method call and the business capability or between the program-exposed method call and the service domain interaction, and wherein the computer executable component further comprises: An execution component inserts a coding template into the program that resolves the gap.

9. A computer-implemented method comprising: 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; as well as The monolithic application is refactored into microservices by the device by aligning a first graph representing the source code with a second graph representing the target domain model.

10. The computer-implemented method of claim 9, further comprising: generating, by the device, the first graph by parsing the source code in a search for programs and program-exposed method calls, wherein nodes of the first graph respectively represent the programs, and wherein edges of the first graph respectively represent the program-exposed method calls; as well as The second graph is generated by the device by parsing the target domain model in a search of service domains and service domain interactions, wherein nodes of the second graph respectively represent the service domains, and edges of the second graph respectively represent the service domain interactions.

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

12. The computer-implemented method of claim 9, wherein aligning the first graph with the second graph produces a set of node pairs, the set of node pairs respectively mapping nodes of the first graph to nodes of the second graph, wherein the nodes of the second graph respectively correspond to the microservices.

13. The computer-implemented method of claim 12, wherein aligning the first graph with the second graph is based on a Euclidean distance that separates an embedded node-by-node representation of the first graph from an embedded node-by-node representation of the second graph, respectively.

14. The computer-implemented method of claim 12, further comprising: User-provided feedback is accessed by the device, wherein the user-provided feedback accepts or rejects at least one node pair in the set of node pairs.

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

16. The computer-implemented method of claim 15, further comprising: Determining, by the device, that there is a gap between the non-exposed method call and the business capability or between the program-exposed method call and the service domain interaction; as well as A coding template that resolves the gap is inserted into the program by the device.

17. A computer program product for facilitating monolith to microservice refactoring via source code to domain model diagram comparison, the computer program product comprising a non-transitory computer readable memory having program instructions embodied therein, the program instructions being executable by a processor to cause the processor to: Accessing source code of a monolithic application and a target domain model corresponding to the monolithic application; and The monolithic application is refactored into microservices by aligning a first graph representing the source code with a second graph representing the target domain model.

18. The computer program product of claim 17, wherein the program instructions are further executable to cause the processor to: generating the first graph by parsing the source code in search of programs and program-exposed method calls, wherein nodes of the first graph respectively represent the programs, and wherein edges of the first graph respectively represent the program-exposed method calls; and The second graph is generated by parsing the target domain model in a search of service domains and service domain interactions, wherein nodes of the second graph respectively represent the service domains, and wherein edges of the second graph respectively represent the service domain interactions.

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

20. The computer program product of claim 17, wherein aligning the first graph with the second graph produces a set of node pairs, the set of node pairs respectively mapping nodes of the first graph to nodes of the second graph, wherein the nodes of the second graph respectively correspond to the microservices.

Images