JP7824901B2 - Microservice design support system, microservice design support method and program - Google Patents

Description

The present invention relates to a microservice design support system, a microservice design support method, and a program.

A technology has been disclosed that allocates the necessary resources to each microservice that is divided into a monolithic system when migrating the system to a new microservice-based system (see Patent Document 1).

In order to improve business efficiency and productivity in companies, there is a demand to identify business processes that particularly contribute to business efficiency, and to turn these identified parts into microservices to enable flexible and rapid continuation of development. For example, in recent years, existing monolithic applications have been migrated to microservices based on the concept of domain-driven design. Domain-driven design is a design concept that models business processes based on information about a company's business domain.

Japanese Patent Application Laid-Open No. 2022-168796

In order to convert part of a business process into a microservice in order to improve business efficiency and productivity, it is necessary to identify the business processes that will particularly contribute to improving business efficiency. However, if the customer's business processes are complex, or if the customer themselves is not aware of which business processes should be converted into microservices in order to improve business efficiency, it is not easy to identify the business processes that should be converted into microservices.

In addition, business process reorganization is generally carried out by customers who are familiar with the business or experienced engineers, and takes a lot of time. Therefore, in order to achieve microservices in a short amount of time, it is important to speed up the process of reorganizing business processes and the process of identifying the target business processes.

Given the above situation, there was a demand for a method to provide design support for microservices that was independent of individual expertise.

To solve the above problems, one aspect of the present invention is a microservice design support system that supports the determination of areas in a user's business process to be turned into microservices, and includes a use case input unit, a ubiquitous language generation unit, and a subdomain information output unit. The use case input unit receives use cases related to the user's business process as text information. The ubiquitous language generation unit generates ubiquitous language related to the components included in the text information of the use cases input to the use case input unit. The subdomain information output unit groups use cases that contain matching or similar elements based on the ubiquitous language and use cases, and further subgroups the text information of the grouped use cases based on whether the information is similar in the business process, thereby generating subdomain information.

According to at least one aspect of the present invention, it is possible to provide design support for microservices that is free from dependency on individual users.
Problems, configurations, and effects other than those described above will become apparent from the following description of the embodiments.

FIG. 1 is a diagram illustrating an overview of a microservice design support system according to an embodiment of the present invention and a conventional technology. FIG. 1 is a block diagram illustrating an example of a functional configuration of a microservice design support system according to an embodiment of the present invention. 10 is a flowchart illustrating an example of a procedure for a ubiquitous language generation process according to an embodiment of the present invention. 10 is a flowchart illustrating an example of a procedure for a subdomain information generation process according to an embodiment of the present invention. 10 is a flowchart illustrating an example of a procedure for a subdomain classification process according to an embodiment of the present invention. FIG. 1 is a diagram illustrating a specific example of classification of use case descriptions according to an embodiment of the present invention. 10 is a flowchart illustrating an example of a procedure for past design information analysis processing according to an embodiment of the present invention. 10 is a flowchart illustrating an example of a procedure for calculating a similarity between previous design information according to an embodiment of the present invention. 10 is a flowchart illustrating an example of a procedure for a context information output process according to an embodiment of the present invention. 10 is a flowchart illustrating an example of a procedure for a microservice information output process according to an embodiment of the present invention. FIG. 2 is a diagram illustrating an example of a database of past design information according to an embodiment of the present invention. FIG. 2 is a diagram illustrating an example of a database of subdomain information according to an embodiment of the present invention. FIG. 2 illustrates an example database of context information according to an embodiment of the present invention. FIG. 1 illustrates an example of a database of microservice information according to an embodiment of the present invention. FIG. 10 is a diagram showing an example of a display of a use case description input according to an embodiment of the present invention. FIG. 10 is a diagram showing an example of a display of a ubiquitous language according to an embodiment of the present invention. FIG. 10 is a diagram showing an example of display of subdomain information according to an embodiment of the present invention. FIG. 10 is a diagram showing an example of a display for editing subdomain information according to an embodiment of the present invention. FIG. 10 is a diagram showing an example of display of attribute information of subdomain information according to an embodiment of the present invention. FIG. 10 is a diagram illustrating an example of a display of context information according to an embodiment of the present invention. FIG. 10 is a diagram illustrating a display example of a context map according to an embodiment of the present invention. FIG. 10 is a diagram illustrating an example of a display of microservice information according to an embodiment of the present invention. FIG. 1 is a diagram illustrating an example of a hardware configuration of a microservice design support system according to an embodiment of the present invention.

Examples of modes for carrying out the present invention (hereinafter referred to as "embodiments") will be described below with reference to the accompanying drawings. In this specification and the accompanying drawings, identical components or components having substantially the same functions will be designated by the same reference numerals, and duplicate descriptions will be omitted.

[Outline of the microservice design support system according to this embodiment and conventional technology]
First, an overview of a microservice design support system according to an embodiment of the present invention and a conventional technique will be described with reference to FIG.

Figure 1 shows an overview of a microservice design support system according to one embodiment of the present invention and conventional technology. In Figure 1, the upper part shows the conventional technology, and the lower part shows an overview of the microservice design support system according to this embodiment.

The conventional technology shown in the top row shows a case where business system 1 is divided into microservices on a functional basis. Because the division focuses on the functions of business system 1 (functions A to C), it is possible that a function (function B) used by multiple businesses (business a, business b) may be extracted. This is an undesirable design that relies on multiple businesses.

The microservice design support system according to this embodiment, shown in the lower part, divides systems into subdomains and context boundaries based on use cases. A use case describes what operations and responses should (or should not) be performed, starting from a specific state, when a user or other entity uses a business system to access a function or achieve a goal.

In this embodiment, by aggregating related use cases and designing subdomains and context boundaries, it is possible to design related functional units (functions B1, B2) for each business (business a, b) while maintaining independence. Furthermore, as will be described later, by also presenting subdomain candidates based on past design information (see past design information 22 in Figure 11), it is possible to provide the user (designer) with multiple materials for consideration.

[Functional configuration of the microservice design support system]
Next, the functional configuration of the microservice design support system according to this embodiment will be described with reference to FIG. 2.
FIG. 2 is a block diagram showing an example of the functional configuration of a microservice design support system according to this embodiment.

The microservice design support system 10 has a user interface unit 11, a use case input unit 12, a ubiquitous language generation unit 13, a subdomain information output unit 14, a context information output unit 15, and a microservice information output unit 16. The microservice design support system 10 also records use case description information 17, industry terminology 18, ubiquitous language 19, organizational information 20, business information 21, past design information 22, subdomain information 23, context information 24, and microservice information 25. This information is stored in the form of a database, table, or the like in the storage device 233 shown in Figure 23 (described below).

The user interface unit 11 presents the user with items that prompt user input, items that prompt user confirmation, items that prompt user editing, and the like at each step of microservice design, via screen displays, etc. Specifically, the user interface unit 11 displays various screens for entering use cases, checking and editing ubiquitous language, entering organizational information and business information, checking and editing subdomain information, checking and editing context information, and checking microservice information. The user interface unit 11 is realized using the display device 236 and input device 235 in Figure 23, which will be described later.

The use case input unit 12 accepts text information (use case descriptions) of use cases related to business operations from the user (user interface unit 11) and stores it in the use case description information 17.

The ubiquitous language generation unit 13 generates a list of ubiquitous language candidates by morphologically analyzing the use case descriptions in the use case description information 17 with reference to industry terminology 18. The ubiquitous language generation unit 13 then presents the list of ubiquitous language candidates to the user via the user interface unit 11, accepts confirmation and editing operations of the ubiquitous language candidates by the user, confirms the ubiquitous language, and stores it in the ubiquitous language 19.

The subdomain information output unit 14 generates subdomain candidate information by analyzing the analysis results (ubiquitous language 19) of the use case description information 17 by the ubiquitous language generation unit 13, as well as organizational information 20, business information 21, and past design information 22. The subdomain information output unit 14 then presents the subdomain candidate information to the user via the user interface unit 11, accepts confirmation and editing operations of the subdomain candidate information by the user, confirms the subdomain information, and stores it in the subdomain information 23.

The context information output unit 15 generates context candidate information by analyzing the subdomain information 23. The context information output unit 15 then presents the context candidate information to the user via the user interface unit 11, accepts confirmation and editing operations of the context candidate information by the user, confirms the context information, and stores it in the context information 24.

The microservice information output unit 16 generates microservice candidate information by analyzing the context information 24. The microservice information output unit 16 then presents the microservice candidate information to the user via the user interface unit 11, accepts confirmation and editing of the microservice candidate information by the user, finalizes the microservice information, and stores it in the microservice information 25.

Completion notifications are sent between the use case input unit 12, ubiquitous language generation unit 13, subdomain information output unit 14, context information output unit 15, and microservice information output unit 16 when processing by each processing block is completed.

[Ubiquitous Language Generation Processing]
Next, the ubiquitous language generation process in the microservice design support system 10 will be described with reference to FIG.
3 is a flowchart showing an example of the procedure of the ubiquitous language generation process. The ubiquitous language generation process is executed by the ubiquitous language generation unit 13.

In step S301, the ubiquitous language generation unit 13 obtains the use case description entered by the user from the use case description information 17.

Next, in step S302, the ubiquitous language generation unit 13 acquires industry terms 18 that correspond to the industry to be analyzed. The industry to be analyzed may be specified by receiving input from the user via the user interface unit 11, or the microservice design support system 10 may present multiple industry candidates to the user and allow the user to select one.

Next, in step S303, the ubiquitous language generation unit 13 performs loop processing on the acquired use case description.

In step S304, the ubiquitous language generation unit 13 performs morphological analysis on the use case description and classifies the components of the use case description, i.e., the sentence, into subject, predicate, object, and other components.

Next, in step S305, the ubiquitous language generation unit 13 checks whether the industry terminology 18 acquired in step S302 contains the same information as that contained in the classified sentence components. The information contained in the classified sentence components is the specific content of the parts of speech, such as nouns and verbs, contained in the component (an example of an element of a use case description). If a part of speech with the same content is contained in the industry terminology 18, that part of speech is assigned a higher priority than other parts of speech that are not included in the industry terminology 18. The priority may be specified as a character string such as "high" or a number such as "1." In this example, since the target part of speech is either included in the industry terminology 18 or not, the priority is either high or low (1 or 0). Note that if the parts of speech have the same priority, the order of those parts of speech is determined based on a pre-set rule (for example, alphabetical order).

Then, in step S306, the ubiquitous language generation unit 13 checks whether the execution of the loop processing has been completed for all use case descriptions. If the ubiquitous language generation unit 13 determines that the loop processing has not been completed, it returns to step S303 and continues processing, but if it determines that the loop processing has been completed, it proceeds to step S307.

In step S307, the ubiquitous language generation unit 13 performs a synonym analysis on the above parts of speech. Existing technologies and dictionaries can be used for the synonym analysis, such as WordNet or Word2Vec. The ubiquitous language generation unit 13 uses the results of the synonym analysis to create synonym groups for each part of speech. At this time, rules can be determined and stored in advance to determine the level of similarity required for determining synonyms. For example, a threshold value for similarity can be defined in advance, and groups can be created for each part of speech that has a similarity above the threshold.

Next, in step S308, the ubiquitous language generation unit 13 generates ubiquitous language candidates based on the analyzed parts of speech and their synonym groups. At this time, the ubiquitous language generation unit 13 sorts the parts of speech in descending order of priority according to the priority specified in step S305. In the case of synonym groups, groups containing many high-priority parts of speech may be sorted before other synonym groups.

Next, in step S309, the ubiquitous language generation unit 13 presents the ubiquitous language candidates generated in step S308 to the user via the user interface unit 11. The user selects which of the ubiquitous language candidates to confirm as the ubiquitous language via the user interface unit 11 (see Figure 16, described later). Furthermore, the user may edit the ubiquitous language or combine synonym groups into a single part of speech via the user interface unit 11. The ubiquitous language generation unit 13 accepts the user's selection and editing of the ubiquitous language candidate via the user interface unit 11.

Next, in step S310, the ubiquitous language generation unit 13 stores the results of the selection and editing of the ubiquitous language candidate received in step S309 in the ubiquitous language 19. When the processing of this step is completed, the ubiquitous language generation process ends.

[Subdomain information generation process]
Next, the subdomain information generation process in the microservice design support system 10 will be described with reference to FIG.
4 is a flowchart showing an example of the procedure for the subdomain information generation process, which is executed by the subdomain information output unit 14.

In step S401, the subdomain information output unit 14 obtains the target use case description from the use case description information 17.

Next, in step S402, the subdomain information output unit 14 performs subdomain classification processing by analyzing the use case description. Details of the subdomain classification processing will be explained using the flowchart in Figure 5.

Next, in step S403, the subdomain information output unit 14 generates subdomain candidate information by analyzing the past design information 22 (see FIG. 11, described later). The past design information 22 is information about microservice designs previously carried out by the designer or design company for other companies or business divisions. Details of the past design information analysis process will be explained using the flowchart in FIG. 7.

Next, in step S404, the subdomain information output unit 14 generates subdomain candidate information based on the analysis results of steps S402 and S403.

Next, in step S405, the subdomain information output unit 14 presents the subdomain candidate information to the user via the user interface unit 11. The user selects and edits the subdomain candidate information via the user interface unit 11 (see Figures 17 to 19, described below). The subdomain information output unit 14 accepts the user's selection and editing of the subdomain candidate information via the user interface unit 11.

Next, in step S406, the subdomain information output unit 14 stores the results of the selection and editing of the subdomain candidate information received in step S405 in the subdomain information 23. When the processing of this step is completed, the subdomain information generation process is completed.

[Subdomain classification process]
Next, the subdomain classification process (subroutine of S402) in the microservice design support system 10 will be described with reference to FIG. 5 .
FIG. 5 is a flowchart showing an example of the procedure of the subdomain classification process performed by the subdomain information output unit 14.

In step S501, the subdomain information output unit 14 performs morphological analysis on the use case descriptions acquired in step S401 to extract subjects and group the use case descriptions by subject.

Next, in step S502, the subdomain information output unit 14 executes loop processing (S503 to S507) on the grouped use case descriptions.

In step S503, the subdomain information output unit 14 extracts object and predicate pairs from the use case description.

Next, in step S504, the subdomain information output unit 14 performs a synonym analysis on the extracted predicate to obtain a list of synonyms for the predicate.

Next, in step S505, the subdomain information output unit 14 performs a synonym analysis of the object within the same group of use case descriptions to obtain synonyms of the object. The subdomain information output unit 14 then obtains use case descriptions from the same group whose objects or synonyms of the objects match the objects of the use case descriptions being processed (i.e., the use case descriptions from which object-predicate pairs have been extracted). Furthermore, the subdomain information output unit 14 performs a synonym analysis of the predicates of the obtained use case descriptions to obtain synonyms of the predicates, and obtains use case descriptions that match the predicates of the use case descriptions being processed or that match their synonyms.

The subdomain information output unit 14 obtains the semantic distances between the objects and the semantic distances between the predicates of the use case descriptions through synonym analysis, and records their average value as the similarity. If the subdomain information output unit 14 determines as a result of the analysis process that a corresponding use case description exists (YES in S505), the process proceeds to step S506. A corresponding use case description is one in which both the object and the predicate satisfy the above condition (either the object or a synonym matches). On the other hand, if the subdomain information output unit 14 determines that a corresponding use case description does not exist (NO in S505), the process proceeds to step S507.

In step S506, the subdomain information output unit 14 classifies the use case description (sentence unit) acquired in step S505 into the same subdomain as the use case description to be processed. The name of the subdomain may be a string combining the object and predicate of the use case description to be processed, or a string numbered in the order in which the groups were generated, such as "Group 1."

In step S507, the subdomain information output unit 14 classifies the use case description to be processed into a new subdomain. The name of the subdomain may be a string combining the object and predicate of the use case description to be processed, or a string numbered in the order in which the groups were generated, such as "Group 1."

Then, in step S508, the subdomain information output unit 14 checks whether any of the grouped use case descriptions have not yet been classified into a subdomain. If any unclassified use case descriptions remain, the subdomain information output unit 14 returns to step S502 and continues the loop processing. On the other hand, if no unclassified use case descriptions remain, the subdomain information output unit 14 ends the loop processing. When the processing of this step is completed, the subdomain classification processing ends, and the process proceeds to step S403.

[Specific examples of classification of use case description information]
Here, the classification of use case descriptions according to this embodiment will be described with a specific example with reference to FIG.
FIG. 6 is a diagram showing a specific example of classification of use case descriptions.

Let's consider the case where use case descriptions (a) to (f) are input as use case description information 17. Use case description (a) is "The policyholder can view the insurance product," use case description (b) is "The policyholder can refer to insurance information," and use case description (c) is "The policyholder can check the progress of the contract." Furthermore, use case description (d) is "The agent can check the progress of the contract," use case description (e) is "The insurance agent can view the insurance product," and use case description (f) is "The policyholder can check the contract details."

In Figure 6 (1), morphological analysis is performed on use case descriptions (a) to (f) to extract subjects and combinations of predicates and objects (corresponding to S501 to S503).

In Figure 6 (2), use case descriptions with the same subject are classified, and use case descriptions with similar nouns in the subject are grouped using synonym analysis (corresponding to S501). As a result, use case descriptions (a) to (c) and (f) are classified into group G1, and use case descriptions (d) and (e) are classified into group G2.

In Figure 6 (3), if there are use case descriptions with similar objects and synonymous predicates, they are classified into the same subdomain group (corresponding to S505 and S506). If no use case description that meets these conditions is found, a new subdomain group is created (corresponding to S505 and S507).

As a result, group G1 is divided into group G11, which includes use case descriptions (a) and (b), and group G12, which includes use case descriptions (c) and (f). Group G2 is also divided into group G21, which includes use case description (d), and group G22, which includes use case description (e).

Then, as described below, the classification results of this use case description are subjected to an analysis process using past design information in step S403, thereby creating subdomain candidate information.

[Past design information analysis processing]
Next, the past design information analysis process (subroutine of S403) in the microservice design support system 10 will be described with reference to FIG.
FIG. 7 is a flowchart showing an example of a procedure for past design information analysis processing by the subdomain information output unit 14.

In step S701, the subdomain information output unit 14 acquires the previous design information 22 (see Figure 11).

Next, in step S702, the subdomain information output unit 14 calculates the similarity between the information currently being processed and the previous design information 22. Details of the similarity calculation process will be explained using the flowchart in Figure 8. The information currently being processed refers to the ubiquitous language, industry/business type information, and organizational information acquired in steps S801 to S803 in Figure 8, which will be described later.

Next, in step S703, the subdomain information output unit 14 checks whether the similarity calculated in step S702 is equal to or greater than a threshold. If the subdomain information output unit 14 determines that the similarity is equal to or greater than the threshold (YES in S703), it proceeds to step S704. If the subdomain information output unit 14 determines that the similarity is less than the threshold (NO in S703), it terminates the past design information analysis process.

Here, the threshold value may be defined in advance in the microservice design support system 10. Alternatively, the user may specify the threshold value via the user interface unit 11 when executing the past design information analysis process. Furthermore, the microservice design support system 10 may store only one threshold value, or may store multiple threshold values. If multiple threshold values are stored, it is possible to generate multiple processing results by determining whether the similarity is greater than or equal to each threshold value, and proceeding to step S704 only for past design information whose similarity is greater than or equal to the threshold value.

In step S704, the subdomain information output unit 14 acquires subdomain information 113 of past design information 22 (plural pieces of past design information) whose similarity is equal to or greater than a threshold value.

Next, in step S705, the subdomain information output unit 14 acquires the use case description included in the corresponding subdomain information 113 of the past design information 22, classifies the components of the sentence into subject, predicate, and object through morphological analysis, and acquires synonyms for the parts of speech included in each component through synonym analysis. The subdomain information output unit 14 also acquires the use case description included in each subdomain of the subdomain candidate information currently being processed, classifies the components into subject, predicate, and object through morphological analysis, and acquires synonyms for each part of speech through synonym analysis.

The subdomain information output unit 14 then checks whether the parts of speech of the use case descriptions in the past design information 22 and the subdomain candidate information currently being processed match, or whether their synonyms match. If the parts of speech or synonyms of the comparison targets match, the subdomain information output unit 14 generates information in which the corresponding use case descriptions are assigned to each subdomain in the past design information 22 as new subdomain candidate information. When the processing of this step is completed, the past design information analysis process ends, and the process proceeds to step S404.

[Similarity calculation process for past design information]
Next, the similarity calculation process (subroutine of S702) for the past design information in the microservice design support system 10 will be described with reference to FIG. 8 .
FIG. 8 is a flowchart showing an example of a procedure for calculating the similarity with respect to past design information by the subdomain information output unit 14. In FIG.

In step S801, the subdomain information output unit 14 acquires the ubiquitous language of the subdomain candidate information currently being processed.

Next, in step S802, the subdomain information output unit 14 acquires the industry/business type information of the subdomain candidate information currently being processed. The industry/business type information may be stored in a configuration file (not shown) and specified by the microservice design support system 10 when the microservice design support system 10 is executed. Alternatively, the user may specify the industry/business type information (e.g., life insurance) via the user interface unit 11.

Next, in step S803, the subdomain information output unit 14 acquires organizational information related to the subdomain candidate information currently being processed. As with the industry/business type information, the organizational information may be specified when the microservice design support system 10 is executed, or may be specified by the user via the user interface unit 11.

Next, in step S804, the subdomain information output unit 14 performs loop processing on each piece of information from steps S801, S802, and S803.

In step S805, the subdomain information output unit 14 calculates the degree of similarity between each of the above information and the previous design information 22. That is, it acquires the ubiquitous language, industry/business type information, and organization information of the previous design information 22 corresponding to the subdomain, and calculates the degree of match (match rate) with each of the information in steps S801, S802, and S803.

For example, the degree of match of ubiquitous language may be calculated as the similarity by determining what percentage of all previous design information matches. The degree of match of industry/business type information may be calculated by determining whether the previous design information contains the same industry/business type information, scoring it as 1 if it does, or 0 if it does not. The degree of match of organizational information may be calculated as the similarity by determining what percentage of all previous design information matches, or the degree of match of organizational information may be calculated only if the industry/business type information matches. The total number of the degrees of match of each piece of information may be used as the similarity, or the average value of each piece of information may be used as the similarity.

Then, in step S806, the subdomain information output unit 14 checks whether any of the above information has yet to be calculated for its degree of match with the previous design information 22. If unprocessed information remains, the process returns to step S804 and continues loop processing. When the processing of this step is completed, the similarity calculation process for the previous design information is completed, and the process proceeds to step S703.

[Context information output processing]
Next, the context information output process in the microservice design support system 10 will be described with reference to FIG. 9 .
9 is a flowchart showing an example of the procedure of the context information output process. The context information output process is executed by the context information output unit 15.

In step S901, the context information output unit 15 obtains the relevant subdomain information from the subdomain information 23.

Next, in step S902, the context information output unit 15 checks the attribute information of the subdomain information 23 and sorts the subdomain information in the order of the attribute information. The attribute information may also be sorted according to whether each subdomain belongs to a "core subdomain," a "general-purpose subdomain," or a "support subdomain."

Next, in step S903, the context information output unit 15 generates context candidate information based on the names of each subdomain in the subdomain information 23.

Next, in step S904, the context information output unit 15 presents the context candidate information to the user via the user interface unit 11 (see FIG. 20, described later). The user can change the name of the context information or further combine or divide the context information via the user interface unit 11. The context information output unit 15 accepts editing operations by the user via the user interface unit 11 and updates the context information.

Next, in step S905, the context information output unit 15 accepts the user's operation to create and edit the connection relationships between contexts (see Figure 21 described later) via the user interface unit 11, and generates the connection relationships between contexts as context map information.

Next, in step S906, the context information output unit 15 stores the generated context information and context map information in the context information 24. When the processing of this step is completed, the context information output processing ends.

[Microservice information output processing]
Next, the microservice information output process in the microservice design support system 10 will be described with reference to FIG.
10 is a flowchart illustrating an example of the procedure of the microservice information output process. The microservice information output process is executed by the microservice information output unit 16.

In step S1001, the microservice information output unit 16 obtains information about the relevant context from the context information 24.

Next, in step S1002, the microservice information output unit 16 acquires attribute information for each context in the context information. The attribute information may be information indicating whether the subdomain corresponding to each context belongs to a "core subdomain," a "general subdomain," or a "support subdomain."

Next, in step S1003, the microservice information output unit 16 generates microservice candidate information using the attribute information acquired in step S1002. As an example, if the attribute information of a context is a core subdomain (e.g., "assessment" in Figure 19 described below), that context may be generated as microservice candidate information.

Next, in step S1004, the microservice information output unit 16 presents the microservice candidate information to the user via the user interface unit 11. The microservice candidate information may be highlighted so that the relevant portion can be identified on the context map of the context information stored in the context information 24, or the relevant context may be indicated by a character string. The user can edit the microservice candidate information by adding or deleting it via the user interface unit 11. The microservice information output unit 16 accepts editing operations for the microservice candidate information via the user interface unit 11 and updates the microservice candidate information.

Next, in step S1005, the microservice information output unit 16 stores the microservice candidate information as microservice information in the microservice information 25. When the processing of this step is completed, the microservice information output processing ends.

[Past design information]
Next, the contents of the previous design information 22 will be described with reference to FIG.
FIG. 11 is a diagram showing an example of the database of the past design information 22. As shown in FIG.

In the past design information 22, business type/industry information 111, organization information 112, subdomain information 113, context information 114, and microservice information 115 are associated and set (stored).

The business type/industry information 111 may be set to a string indicating the business type/industry to which this design information was applied, such as "life insurance," or may be set to a string that serves as an identifier for an external business type/industry dictionary (for example, "001").

Organizational information 112 is information about customers who use the business process for which microservices are being considered, and is, for example, information indicating the company, department, team, etc. related to the use case description (e.g., name, alphanumeric identifier, etc.).

Subdomain information 113 contains one or more subdomains included in the design information, and each subdomain is stored in the format of subdomain information 23 shown in Figure 12.

Context information 114 contains one or more contexts included in the design information, and is stored in the format of context information 24 shown in Figure 13.

Microservice information 115 contains one or more pieces of microservice information included in the design information, and is stored in the format of microservice information 25 shown in Figure 14. In Figure 11, a circle is displayed for the information in the target context information 114 (e.g., assessment), but a character string indicating the name of the context information 114 may also be displayed.

For example, in Figure 11, "Life Insurance" is set in business type/industry information 111, and "Company A Sales Department" is set in organization information 112. "Product Viewing," "Reception," and "Assessment" are set in subdomain information 113. Similarly, "Product Viewing," "Reception," and "Assessment" are also set in context information 114. Furthermore, "Assessment" from context information 114 is specified in microservice information 115.

[Subdomain Information]
Next, the contents of the subdomain information 23 will be described with reference to FIG.
FIG. 12 is a diagram showing an example of the database of the subdomain information 23. As shown in FIG.

The subdomain information 23 associates and stores a subdomain 121, a related use case description 122, a related ubiquitous language 123, a similarity 124, and attribute information 125.

A subdomain 121 has one character string set to indicate that subdomain. Multiple subdomains are set for each business domain (target business range). Therefore, a subdomain is entered for each type of subdomain 121 in the subdomain information 23. It can also be thought of as subdomain information 23 being created for each type of subdomain 121. Information in the subdomain information 23 is registered for each subdomain.

Use case description 122 contains a use case description associated with information on subdomain 121 through analysis by the subdomain information output unit 14.

The ubiquitous language 123 is set to a ubiquitous language associated with the information of the subdomain 121 through analysis by the ubiquitous language generation unit 13 and the subdomain information output unit 14.

The similarity 124 is set to the similarity between the information of the subdomain 121 (assessment in the example of FIG. 12) and the previous design information 22, calculated by the similarity calculation process (S702 in FIG. 7) of the subdomain information output unit 14.

Attribute information 125 contains attribute information set by the user for the associated subdomain via the user interface unit 11. In this embodiment, the subdomains provided are "core subdomain," "general subdomain," and "support subdomain" (see Figure 19 below).

A "core subdomain" is a subdomain that forms the core of a business domain. A "general-purpose subdomain" is a general-purpose subdomain that can be used not only in the target industry but also in other industries. A "support subdomain" is a subdomain that supports a core subdomain.

For example, in Figure 12, "assessment" is set as subdomain 121, and "Insurance company inspects documents," "Insurance company reviews health status," and "Insurance company inspects income status" are set as use case description 122. "Documents," "inspection," and "examination" are set as ubiquitous language 123. Furthermore, "0.80" is set as similarity 124, and "core subdomain" is set as attribute information 125. Note that the information stored in Figures 10 to 12 is accumulated based on use case descriptions within the scope of the business domain.

[Context Information]
Next, the contents of the context information 24 will be described with reference to FIG.
FIG. 13 is a diagram showing an example of a database of the context information 24. As shown in FIG.

Context information 24 associates and stores a context 131, a related subdomain 121, a related use case description 122, a related ubiquitous language 123, a similarity 124, and attribute information 125.

A single character string indicating the context is set in the context 131. The information in the context 131 is often the same as the information in the subdomain 121.
In the subdomain 121, one or more character strings indicating the subdomain associated with the information of the context 131 by the context information output unit 15 are set. In this example, the "assessment" of the subdomain 121 is associated with the "assessment" of the context 131. The number of subdomains for one context is not limited to one, and there may be multiple subdomains.
The use case description 122, the ubiquitous language 123, the similarity 124, and the attribute information 125 will not be described here.

[Microservices Information]
Next, the contents of the microservice information 25 will be described with reference to FIG.
FIG. 14 is a diagram illustrating an example of a database of the microservice information 25.

Microservice information 25 associates and stores a microservice 141, an associated context 131, an associated subdomain 121, an associated use case description 122, an associated ubiquitous language 123, a similarity 124, and attribute information 125.

A microservice 141 has one character string set to indicate the microservice.
In the context 131, one character string indicating a context associated with the information of the microservice 141 by the microservice information output unit 16 is set.
In the subdomain 121, one or more character strings indicating a subdomain associated with the information of the context 131 by the context information output unit 15 are set.
The use case description 122, the ubiquitous language 123, the similarity 124, and the attribute information 125 will not be described here.

[Example of use case description input display]
Next, a display example of a use case description input will be described with reference to FIG.
15 is a diagram showing an example of a display on the user interface unit 11 for inputting a use case description. In FIG. 15, an example of an interface screen 150 including an input field for a use case description is shown.

The interface screen 150 has a "Use Case" button 151, a "Ubiquitous" button 152, a "Subdomain" button 153, a "Bounded Context" button 154, a "Context Map" button 155, an input field for use case description 156, an "OK" button, and a "Cancel" button.

When the "Use Case" button 151 is pressed, the user interface unit 11 displays an interface screen 150 for inputting a use case description as shown in FIG.
When the "Ubiquitous" button 152 is pressed, the user interface unit 11 displays an interface screen 160 for checking and editing the ubiquitous language as shown in FIG.
When the "Subdomain" button 153 is pressed, the user interface unit 11 displays an interface screen 170 for checking and editing subdomain information as shown in FIG.
When the "bounded context" button 154 is pressed, the user interface unit 11 displays an interface screen 200 for checking and editing context information as shown in FIG.
When the "context map" button 155 is pressed, the user interface unit 11 displays an interface screen 210 for creating a context map as shown in FIG.

The input field 156 has input fields for each category to help the user organize and input use case descriptions. Figure 15 shows examples of categories (a) to (g). Each category has an assist button "?" that displays an explanation of that category.

For example, category (a) is "Product/Customer Value." The use case description for category (a) is "Customers can view insurance products."
Category (b) is "Price/Cost." The use case description for category (b) is "The insurance company (new contract) confirms the payment of the insurance premium."
Category (c) is "Place/Convenience." The use case description for category (c) is "Customers access using a Web browser."
Category (d) is "Promotion/Communication." The use case description for category (d) is "Customers can receive recommendations for insurance products."

Category (e) is "Personnel." The use case description "Customers use this system" is entered in category (e).
Category (f) is "Process." The use case description entered in category (f) is "The insurance company (common to all departments) sends various notifications to policyholders."
Category (g) is "Physical Evidence." The use case description entered in category (g) is "The insurance company (new contract) sends the insurance policy to the right holder."

Use case descriptions can be entered on multiple lines in a single input field 156. After entering use case descriptions for all categories in the input fields 156, pressing the "OK" button at the bottom will send the use case descriptions to the use case input unit 12 and transition to the example ubiquitous language display shown in Figure 16.

[Ubiquitous language display example]
Next, an example of a display of ubiquitous language will be described with reference to FIG.
16 is a diagram showing an example of a display on the user interface unit 11 for checking and editing a ubiquitous language. In FIG. 16, an example of an interface screen 160 for checking a list of ubiquitous language candidates and adopting a ubiquitous language is shown.

On the interface screen 160, a list of candidate ubiquitous languages generated by the ubiquitous language generation unit 13 is displayed in the left-hand column 161. The user can select a term to be used as a ubiquitous language from the candidate list and move the selected term to the ubiquitous language column 162 on the right by pressing the "Move" button 163 in the center of the screen. To cancel a term that has been moved to the ubiquitous language column 162 on the right, the user selects the term to be canceled from the list of ubiquitous languages and presses the "Back" button 164 to cancel the move.

For example, the following ubiquitous language candidates are registered: "customer," "policyholder," "insurance provider (new contract)," "system," "contract," "required information/required documents (application)," "documents," "inspection," "access," "authentication/authorization," "product viewing," and "application." In this example, all of the ubiquitous language candidates displayed in column 161 on the left have been moved to ubiquitous language column 162 on the right.

Furthermore, by pressing the "Edit" button 165, the user can display an editing window, where they can change the name of the ubiquitous language or add a new one. After selecting and editing all ubiquitous languages, by pressing the "OK" button at the bottom, the ubiquitous language is sent to the ubiquitous language generation unit 13, and the display transitions to the example of subdomain information shown in Figure 17.

[Example of subdomain information display]
Next, examples of displaying subdomain information will be described with reference to FIGS.
FIG. 17 is a diagram showing an example of a display on the user interface unit 11 for checking and editing subdomain information.

Figure 17 shows an example of an interface screen 170 for confirming and editing candidate information for subdomain information. The interface screen 170 has a file selection field for organization information 171, a file selection field for business information 172, a subdomain information display area 173, and an "Edit" button 174.

The user specifies and uploads the organizational information 171 file and business information 172 file related to this use case description. The organizational information 171 may be provided in text format, including the names of departments, teams, etc. related to the use case description, or in spreadsheet file format. The business information 172 may be provided in text format, including the names of departments and roles related to the use case description, or in spreadsheet file format.

In the subdomain information display area 173, subdomain information candidates are displayed using switchable tabs, allowing multiple subdomain information candidates to be displayed by switching between them. In Figure 17, the "Candidate 1" tag is selected. The subdomain information displays the subdomain candidate information generated by the subdomain information output unit 14.

For example, the following subdomain candidate information is displayed: "Access (browser/smartphone)," "Authentication/Authorization," "Contract Information Management," "System Operation," "Product Registration," "Product Viewing," "Application," "Inspection," "Appraisal," "Insurance Premium Deposit," "Policy Shipping," "Insurance Claim Application," "Review," "Insurance Claim Payment," "Progress Management (Contractor/Business)," and "Notification."

[Example of subdomain information editing]
FIG. 18 is a diagram showing an example of a display for editing subdomain information.
18, the user can draw arrows indicating connections between subdomains according to the business flow by pressing an "Edit" button 174. When the user presses the "Edit" button 174, an editing window is displayed, allowing the user to input lines and arrows between subdomains.

[Example of subdomain attribute information display]
FIG. 19 is a diagram showing an example of display of attribute information of subdomain information.
As shown in Fig. 19, the user can press an "Edit" button 174 to open an editing window and assign attribute information to each subdomain. Fig. 19 shows an example in which each subdomain has been edited to belong to one of a support subdomain 191, a core subdomain 192, and a general-purpose subdomain 193. For example, each subdomain can be easily distinguished from other subdomains by using different display colors or line styles for the support subdomain 191, the core subdomain 192, and the general-purpose subdomain 193.

After the user has finished editing the subdomain information, they can press the "OK" button at the bottom to send the currently displayed subdomain candidate information to the subdomain information output unit 14, and transition to the example context information display shown in Figure 20.

[Example of context information display]
Next, a display example of the context information will be described with reference to FIG.
FIG. 20 shows an example of a display on the user interface unit 11 for checking and editing context information.

Figure 20 shows an interface screen 200 as an example of how context information is displayed. The interface screen 200 has a "Use Case" button 151, a "Ubiquitous" button 152, a "Subdomain" button 153, a "Bounded Context" button 154, a "Context Map" button 155, a context information display area 201, an "Edit" button 202, an "OK" button, and a "Cancel" button.

The context information display area 201 displays the context information generated by the context information output unit 15. This context information is displayed in the order rearranged by the context information output unit 15. In this example, the upper row of the context information display area 201 displays the attribute information of the subdomain of the support subdomain 191 (product browsing, etc.), the middle row displays the attribute information of the subdomain of the core subdomain 192 (assessment), and the lower row displays the attribute information of the subdomain of the general-purpose subdomain 193 (insurance payment, etc.).

By pressing the "Edit" button 202, the user can launch an editing window where they can change the name of the context information, add new information, or merge multiple pieces of context information. When adding a new context, an editing screen is displayed where they can select and associate subdomain information.

After the user has finished editing the context information, they can press the "OK" button at the bottom to send the context information to the context information output unit 15, and the display will transition to the example context map shown in Figure 21. When integrating contexts by editing the user's context, the context information output unit 15 also integrates the associated subdomain information and ubiquitous language, and updates the subdomain information 23 and context information 24.

[Context map display example]
Next, a display example of a context map will be described with reference to FIG.
FIG. 21 is a diagram showing an example of a display on the user interface unit 11 for creating a context map.

In Figure 21, an interface screen 210 is shown as an example of a context map display. The interface screen 210 has a "Use Case" button 151, a "Ubiquitous" button 152, a "Subdomain" button 153, a "Bounded Context" button 154, a "Context Map" button 155, a context map display area 211, an "Edit" button 212, an "OK" button, and a "Cancel" button.

In the initial state, the context map display area 211 of the interface screen 210 displays the context information 24 after the context information editing in Figure 20 has been completed. The context map displayed on the interface screen 210 is a candidate diagram of the microservice boundary regarding the correspondence between each process included in the business process.

By pressing the "Edit" button 212, the user can launch an editing window and draw the connection relationships between contexts. The user can also add strings representing the upstream "U" and downstream "D" of the context to the lines between contexts. Furthermore, the user can add strings representing the connection method between contexts, such as open host service "OHS," anti-corruption layer "ACL," and published language "PL," to each context.

After the user has completed creating the context map, they can press the "OK" button at the bottom to send the context map to the microservice information output unit 16, and transition to the example microservice information display shown in Figure 22.

[Example of displaying microservice information]
Next, a display example of microservice information will be described with reference to FIG. 22.
FIG. 22 is a diagram showing a display example of the user interface unit 11 for checking and editing microservice information.

Figure 22 shows an example of an interface screen 210 in which candidate microservice information (microservice candidate 1 in the figure) is highlighted on a context map created by the user. The candidate microservice information displays the candidate microservice information created by the microservice information output unit 16. The candidate microservice information is displayed in an example in which the relevant context is surrounded by a line (e.g., border 221) that highlights the relevant context. Other display methods include changing the color of the relevant context or making it blink.

[Hardware configuration of the microservice design support system]
FIG. 23 is a diagram illustrating an example of the hardware configuration of the microservice design support system 10.
The microservice design support system 10 includes, as hardware, a computer 230. The computer 230 is used as a computer and includes a processor 231, a main memory 232, a storage device 233, a communication device 234, an input device 235, and a display device 236, which are connected to a bus 237.

The storage device 233 stores data in a writable and readable manner, and stores the use case description information 17, industry terminology 18, ubiquitous language 19, organizational information 20, business information 21, past design information 22, subdomain information 23, context information 24, and microservice information 25 shown in Figure 2.

The processor 231 reads the data stored in the storage device 233 into the main memory 232 and uses the main memory 232 to execute the processing of the software program. By the processor 231 executing the software program, the user interface unit 11, use case input unit 12, ubiquitous language generation unit 13, subdomain information output unit 14, context information output unit 15, and microservice information output unit 16 shown in Figure 2 are realized.

The communication device 234 transmits information processed by the processor 231 via a communication network, which may be wired or wireless, or both, and also transmits information received via the communication network to the processor 231. The information received by the communication device 234 is used for software processing in the processor 231.

The input device 235 is a device that accepts information entered by a user through a keyboard, mouse, or other operation. The information entered through the input device 235 is used for software processing in the processor 231.

The display device 236 is a device that displays image and text information on a display screen in accordance with software processing by the processor 231. The interface screens illustrated in Figures 15 to 22 are displayed by the display device 236.

As described above, the microservice design support system according to this embodiment is a microservice design support system that supports the user in determining which areas of their business process should be turned into microservices, and includes a use case input unit, a ubiquitous language generation unit, and a subdomain information output unit.
A use case related to a user's business process is input as text information (use case description) into the use case input unit (use case input unit 12).
The ubiquitous language generation unit (ubiquitous language generation unit 13) generates ubiquitous language related to components included in the text information of the use case input to the use case input unit.
The subdomain information output unit (subdomain information output unit 14) groups use cases that contain matching or similar elements based on the ubiquitous language and the use case, and further subgroups the text information of the grouped use cases based on whether the information is similar in the business process, thereby generating subdomain information.

According to this embodiment, it is possible to systematize the organization of steps included in a customer's business process (subdomain information generation) based on input information (use case text information) related to the business process (business domain) of the customer, and to support the creation of microservices. In other words, it is possible to realize design support for microservices that eliminates dependency on individual skills.
This has the effect of stabilizing design quality without relying on the intuition or experience of skilled workers.

The microservice design support system according to this embodiment can further include a context information output unit (context information output unit 15) that generates context information representing boundaries between similar contexts in a business process based on subdomain information, and a microservice information output unit (microservice information output unit 16) that generates, based on the context information, a candidate diagram of microservice boundaries (microservice map) relating to the correspondence between each process included in the business process.

With this configuration, this embodiment can automatically display microservice candidate information, allowing even those with no experience to identify parts of a business process that should be converted into microservices.

The microservice design support system according to this embodiment also includes a past design information storage unit (past design information 22) that stores past microservice design information, and a similarity calculation unit (subdomain information output unit 14) that calculates the similarity between subdomain information and past microservice design information. If the similarity is equal to or greater than a threshold, the subdomain information output unit (subdomain information output unit 14) acquires subdomain information from the past microservice design information, updates the generated subdomain information based on the similarity between the acquired subdomain information and the generated subdomain information, and outputs the subdomain information.

With this configuration, in this embodiment, by updating subdomain information using past microservice design information (past design information 22), it is possible to create a more appropriate microservice boundary candidate diagram (microservice map) that reflects past microservice design information.

The present invention is not limited to the above-described embodiments, and various other applications and modifications are possible as long as they do not deviate from the gist of the present invention as set forth in the claims. For example, the above-described embodiments have been described in detail and specifically to clearly explain the present invention, and are not necessarily limited to those that include all of the components described. Furthermore, it is also possible to add, replace, or delete other components from part of the configuration of an embodiment.

Furthermore, some or all of the above-mentioned configurations, functions, processing units, etc. may be implemented in hardware, for example by designing them as integrated circuits. Broad processor devices such as FPGAs (Field Programmable Gate Arrays) and ASICs (Application Specific Integrated Circuits) may also be used as hardware.

Furthermore, each component of the microservice design support system 10 according to the above-described embodiment may be implemented on any hardware, as long as the respective hardware can send and receive information to and from each other via a network. Furthermore, the processing performed by a certain processing unit may be realized by a single piece of hardware, or may be realized by distributed processing using multiple pieces of hardware.

Furthermore, in the microservice design support system 10 of the above-described embodiment, the control lines and information lines shown are those considered necessary for explanation, and not all control lines and information lines in the product are necessarily shown. In reality, it can be assumed that almost all components are interconnected.

In addition, in this specification, processing steps describing chronological processing include not only processing that is performed chronologically in the order described, but also processing that is not necessarily performed chronologically but is performed in parallel or individually (for example, processing by objects). Furthermore, the processing order of processing steps describing chronological processing may be changed as long as it does not affect the processing results.

10...Microservice design support system, 11...User interface unit, 12...Use case input unit, 13...Ubiquitous language generation unit, 14...Subdomain information output unit, 15...Context information output unit, 16...Microservice information output unit, 17...Use case description information, 18...Industry terminology, 19...Ubiquitous language, 20...Organizational information, 21...Business information, 22...Past design information, 23...Subdomain information, 24...Context information, 25...Microservice information

Claims (5)

A microservice design support system that supports determining areas to be converted into microservices in a user's business process,
a use case input unit into which use cases related to the user's business process are input as text information;
a ubiquitous language generation unit that generates ubiquitous language related to components included in the text information of the use case input to the use case input unit;
a subdomain information output unit that groups use cases that include matching or similar elements based on the ubiquitous language and the use cases, and further subgroups the text information of the grouped use cases based on whether the information is similar in the business process, thereby generating subdomain information. a context information output unit that generates context information representing a boundary between similar contexts in the business process based on the subdomain information;
The microservice design support system according to claim 1 , further comprising: a microservice information output unit that generates a candidate diagram of a microservice boundary regarding a correspondence relationship between each process included in the business process based on the context information. a past design information storage unit for storing past microservice design information;
Further comprising a similarity calculation unit that calculates a similarity between the subdomain information and the past microservice design information,
2. The microservice design support system according to claim 1, wherein the subdomain information output unit acquires subdomain information from the past microservice design information when the similarity is equal to or greater than a threshold, updates the generated subdomain information based on the similarity between the acquired subdomain information and the generated subdomain information, and outputs the subdomain information. A microservice design support method using a microservice design support system that supports the determination of areas to be converted into microservices in a user's business process,
a process of inputting a use case related to the user's business process as text information;
A process of generating ubiquitous language related to components included in the input text information of the use case;
a process of grouping use cases including elements with similar meanings based on the ubiquitous language and the use cases, and further subgrouping the text information of the grouped use cases based on whether the information is similar in the business process, thereby generating subdomain information. The microservice design support system helps users decide which areas of their business processes to turn into microservices.
inputting a use case related to the user's business process as text information;
A step of generating ubiquitous language related to components included in the input text information of the use case;
a procedure for grouping use cases including elements with similar meanings based on the ubiquitous language and the use cases, and further subgrouping the text information of the grouped use cases based on whether the information is similar in the business process, thereby generating subdomain information;
The program to run.