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

Abstract

To realize design support without personal attributes in microservices design.SOLUTION: A microservices design support system is provided with a use case input unit 12 for inputting a use case related to a user's business process as textual information; a ubiquitous language generation unit 13 for generating a ubiquitous language related to a constituent element included in the textual information of the use case inputted to the use case input unit and a subdomain information output unit 14 for grouping use cases including matching or similar elements based on the ubiquitous language and the use case, further subgrouping the textual information of the grouped use cases based on whether the textual information is similar in the business process, and generating subdomain information.SELECTED DRAWING: Figure 2

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, when migrating a monolithic system into a new microservice-based system, allocates the necessary resources to each microservice that is divided from the system (see Patent Document 1).

In order to improve business efficiency and productivity at companies, there is a demand to identify business processes that contribute particularly to business efficiency, and to turn the identified parts into microservices so that development can continue flexibly and quickly. 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.

JP 2022-168796 A

In order to turn 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 contribute particularly to business efficiency. However, when a customer's business processes are complex, or when the customer himself does not know which business processes should be turned into microservices to improve business efficiency, it is not easy to identify the business processes to be turned into microservices.

In addition, business process reorganization is generally carried out by customers who are familiar with the business and experienced engineers, and takes a lot of time. Therefore, in order to realize microservices in a short 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 not dependent on individual skills.

In order to solve the above problem, one aspect of the present invention is a microservice design support system that supports the determination of areas to be turned into microservices in a user's business process, 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 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 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.

According to at least one aspect of the present invention, it is possible to realize design support for microservices that is free from dependency on individuals.
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 technique. 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. 1 is a flowchart showing 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. 2 is a diagram showing a specific example of classification of use case descriptions according to an embodiment of the present invention. 1 is a flowchart illustrating an example of a procedure for past design information analysis processing according to an embodiment of the present invention. 11 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. 13 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 showing an example of a database of sub-domain 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. 13 is a diagram showing an example of a display of a use case description input according to an embodiment of the present invention. FIG. 2 is a diagram showing a display example of a ubiquitous language according to an embodiment of the present invention. FIG. 13 is a diagram showing an example of display of sub-domain information according to an embodiment of the present invention. FIG. 13 is a diagram showing an example of a display for editing subdomain information according to an embodiment of the present invention. FIG. 13 is a diagram showing an example of display of attribute information of sub-domain information according to an embodiment of the present invention. FIG. 13 is a diagram showing an example of display of context information according to an embodiment of the present invention. FIG. 11 is a diagram illustrating a display example of a context map according to an embodiment of the present invention. FIG. 11 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.

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

[Outline of the microservice design support system according to the present embodiment and the 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 is a diagram showing an overview of a microservice design support system according to one embodiment of the present invention and the 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 in the upper part 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) that is 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 into subdomains and context boundaries based on use cases. A use case describes what operations and responses are (should be) performed starting from a specific state when a user or other entity uses a business system to use some 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 their independence. In addition, as described below, by also presenting subdomain candidates based on past design information (see past design information 22 in FIG. 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.
FIG. 2 is a block diagram illustrating an example of a 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. These various pieces of information are stored in the form of a database, a table, or the like in a storage device 233 in FIG. 23, which will be described later.

The user interface unit 11 presents to the user, by displaying a screen or the like, items that prompt the user to input, items that prompt the user to confirm, items that prompt the user to edit, and the like at each step of microservice design. Specifically, the user interface unit 11 displays various screens for inputting use cases, confirming and editing ubiquitous language, inputting organizational information and business information, confirming and editing subdomain information, confirming and editing context information, and confirming microservice information. The user interface unit 11 is realized using the display device 236 and input device 235 in FIG. 23 described later.

The use case input unit 12 accepts text information (use case description) of use cases related to business 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 performing morphological analysis of the use case description 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, finalizes 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 result (ubiquitous language 19) of the use case description information 17 by the ubiquitous language generation unit 13, organization 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, and 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, and confirms and stores the context information in the context information 24.

The microservice information output unit 16 generates microservice candidate information by analyzing the context information 24. Then, the microservice information output unit 16 presents the microservice candidate information to the user via the user interface unit 11, accepts confirmation and editing operations 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, the ubiquitous language generation unit 13, the subdomain information output unit 14, the context information output unit 15, and the 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 a procedure for a 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 input 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 accepting an input from the user at the user interface unit 11, or the microservice design support system 10 may present a plurality of 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 component. The information contained in the classified sentence component is the specific content of the parts of speech (examples of elements of use case description) such as nouns and verbs contained in the component. If a part of speech with the same content is contained in the industry terminology 18, the part of speech is assigned a higher priority than other parts of speech that are not contained 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, the target part of speech is either included in the industry terminology 18 or not, so there are two levels of priority: 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 based on a preset 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 the processing, and 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 technology and dictionaries can be used for the synonym analysis, and for example, WordNet or Word2Vec may be used. 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 as to how much similarity is required to determine a word as a synonym. 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 equal to or greater than the threshold value.

Next, in step S308, the ubiquitous language generation unit 13 generates ubiquitous language candidates based on the analyzed parts of speech and the synonym groups of those parts of speech. At this time, the ubiquitous language generation unit 13 sorts the parts of speech in order of priority according to the priority specified in step S305. In the case of synonym groups, a group that contains 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 FIG. 16 described later). Furthermore, the user may edit the ubiquitous language via the user interface unit 11, or edit by consolidating synonymous groups into one part of speech. The ubiquitous language generation unit 13 accepts the selection and editing operation of the ubiquitous language candidate by the user via the user interface unit 11.

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

[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 of the subdomain information generating process. The subdomain information generating process 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 executes a subdomain classification process by analyzing the use case description. Details of the subdomain classification process will be explained using the flowchart in FIG. 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 for other companies, other business divisions, etc. that were previously carried out by the designer or design company. 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 later). 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 categorization process]
Next, the subdomain classification process (subroutine of S402) in the microservice design support system 10 will be described with reference to FIG.
FIG. 5 is a flowchart showing an example of a procedure for a 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 groups 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 that match the object or a synonym of the object in the use case description to be processed (i.e., the use case description from which the object and predicate pair has been extracted). Furthermore, the subdomain information output unit 14 performs a synonym analysis of the predicate in the obtained use case description to obtain synonyms of the predicate, and obtains use case descriptions that match the predicate in the use case description to be processed or that match its synonyms.

The subdomain information output unit 14 obtains the semantic distance between the objects of the use case description and the semantic distance between the predicates of the use case description by synonym analysis, and records the average value of these as the similarity. If the subdomain information output unit 14 determines that a corresponding use case description exists as a result of the analysis process (YES judgment in S505), the process proceeds to step S506. A corresponding use case description is a use case description in which both the object and the predicate satisfy the above condition (match themselves or a synonym). On the other hand, if the subdomain information output unit 14 determines that a corresponding use case description does not exist (NO judgment 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 character string combining the object and predicate of the use case description to be processed, or a character 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 character string that combines the object and predicate of the use case description to be processed, or a character string numbered in the order in which the groups are 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 ends, 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.

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". In addition, use case description (d) is "The person in charge can check the progress of the contract", use case description (e) is "The insurance person in charge can view the insurance product", and use case description (f) is "The policyholder can check the contract details".

In FIG. 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 FIG. 6 (2), use case descriptions with the same subject are classified, and use case descriptions with similar nouns in the subject are grouped by synonym analysis (corresponding to S501). As a result, use case descriptions (a)-(c) and (f) are classified into group G1, and use case descriptions (d) and (e) are classified into group G2.

In FIG. 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 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, and subdomain candidate information is created.

[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 past design information 22 (see FIG. 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 FIG. 8. The information currently being processed is the ubiquitous language, industry/business type information, and organization information acquired in steps S801 to S803 in FIG. 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), the process proceeds to step S704. If the subdomain information output unit 14 determines that the similarity is less than the threshold (NO in S703), the process ends the past design information analysis process.

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

In step S704, the subdomain information output unit 14 acquires subdomain information 113 of past design information 22 (multiple 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 by morphological analysis, and acquires synonyms of the parts of speech included in each component by thesaurus 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 them into subject, predicate, and object by morphological analysis, and acquires synonyms of each part of speech by thesaurus analysis.

Then, the subdomain information output unit 14 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 of the comparison targets match, or their synonyms match, the subdomain information output unit 14 generates information in which the corresponding use case descriptions are assigned to each subdomain of the past design information 22 as new subdomain candidate information. When the processing of this step is completed, the past design information analysis processing is completed, and the process proceeds to step S404.

[Similarity calculation process for past design information]
Next, the similarity calculation process (subroutine of S702) for past design information in the microservice design support system 10 will be described with reference to FIG.
FIG. 8 is a flowchart showing an example of a procedure for calculating a similarity between previous design information and 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 may be 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 executes a loop process for each piece of information from steps S801, S802, and S803.

In step S805, the subdomain information output unit 14 calculates the similarity between each of the above information and the past design information 22. That is, it acquires the ubiquitous language, industry/business type information, and organization information of the past 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 based on 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, and if so, a score of 1 may be assigned, and if not, a score of 0 may be assigned. The degree of match of organization information may be calculated as the similarity based on what percentage of all previous design information matches, or the degree of match of organization information may be calculated only if the industry/business type information matches. The sum 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 there is any information among the above information for which the degree of coincidence with the past design information 22 has not yet been calculated, and if unprocessed information remains, the process returns to step S804 and continues the loop process. When the process of this step ends, the similarity calculation process for the past design information ends, and the process proceeds to step S703.

[Context information output process]
Next, the context information output process in the microservice design support system 10 will be described with reference to FIG.
9 is a flowchart illustrating an example of a procedure for a 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 be sorted according to whether each subdomain belongs to a "core subdomain," a "general 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 integrate or divide the context information via the user interface unit 11. The context information output unit 15 accepts an editing operation 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 an operation by the user to create and edit a connection relationship between contexts (see FIG. 21 described later) via the user interface unit 11, and generates the connection relationship 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 is completed.

[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 a procedure for a 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, when the attribute information of a context is a core subdomain (for example, "assessment" in FIG. 19 described later), the 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 an editing operation of 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 is completed.

[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 set (stored) in association with each other.

The business type/industry information 111 may be set to a character string indicating the business type/industry to which this design information was applied, such as "life insurance," or may be set to a character string that serves as an identifier for an external business type/industry dictionary (e.g., "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 (for example, a name, an 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 FIG. 12.

The 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 FIG. 13.

Microservice information 115 is set with one or more pieces of microservice information included in the design information, and is stored in the format of microservice information 25 shown in FIG. 14. In FIG. 11, a circle is displayed for the information of 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 FIG. 11, "Life Insurance" is set in the business type/industry information 111, and "Company A Sales Department" is set in the organization information 112. "Product Viewing", "Reception", and "Assessment" are set in the subdomain information 113. Similarly, "Product Viewing", "Reception", and "Assessment" are also set in the context information 114. Furthermore, in the microservice information 115, "Assessment" from the context information 114 is specified.

[Subdomain Information]
Next, the contents of the sub-domain 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.

In the subdomain information 23, a subdomain 121, a related use case description 122, a related ubiquitous language 123, a similarity 124, and attribute information 125 are set (stored) in association with each other.

A subdomain 121 is set with one character string indicating the subdomain. Multiple subdomains are set for a 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 the subdomain information 23 being created for each type of subdomain 121. Information in the subdomain information 23 is registered for each subdomain.

In the use case description 122, a use case description associated with the information of the subdomain 121 is set by the analysis of the subdomain information output unit 14.

In the ubiquitous language 123, a ubiquitous language associated with the information of the subdomain 121 is set 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 past design information 22, calculated in the similarity calculation process (S702 in FIG. 7) of the subdomain information output unit 14.

The attribute information 125 contains attribute information that the user has set for the related subdomain via the user interface unit 11. In this embodiment, the subdomains provided are "core subdomain," "general subdomain," and "support subdomain" (see FIG. 19 described later).

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

For example, in FIG. 12, "assessment" is set in subdomain 121, and "insurance company reviews documents", "insurance company examines health status", and "insurance company examines income status" are set in use case description 122. "Documents", "inspection", and "examination" are set in ubiquitous language 123. Furthermore, "0.80" is set in similarity 124, and "core subdomain" is set in attribute information 125. Note that the information stored in FIGS. 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.

In the context information 24, 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 are set (stored) in association with each other.

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 a subdomain associated with 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.
Description of the use case description 122, the ubiquitous language 123, the similarity 124, and the attribute information 125 will be omitted.

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

In the microservice information 25, a microservice 141, a related context 131, a related subdomain 121, a related use case description 122, a related ubiquitous language 123, a similarity 124, and attribute information 125 are set (stored) in association with each other.

Each microservice 141 has one character string set that indicates 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 sub-domain 121, one or more character strings indicating a sub-domain associated with the information of the context 131 by the context information output unit 15 are set.
Description of the use case description 122, the ubiquitous language 123, the similarity 124, and the attribute information 125 will be omitted.

[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 156 for use case description, 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 confirming and editing the ubiquitous language as shown in FIG.
When the "Sub-domain" button 153 is pressed, the user interface unit 11 displays an interface screen 170 for confirming and editing sub-domain information as shown in FIG.
When the "bounded context" button 154 is pressed, the user interface unit 11 displays an interface screen 200 for confirming 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 "?" to display an explanation of the category.

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

The category (e) is “Personnel.” “A customer uses this system” is input as the use case description in the category (e).
Category (f) is "Process." The use case description "The insurance company (common to all departments) provides various notifications to policyholders" is input to category (f).
Category (g) is “Physical Evidence.” The use case description “The insurance company (new contract) sends the insurance policy to the right holder” is input to category (g).

The use case description can be entered in multiple lines in one input field 156. After entering the use case descriptions for all categories in the input fields 156, pressing the "OK" button at the bottom sends the use case description to the use case input unit 12 and transitions to the example of the ubiquitous language display in Figure 16.

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

In the interface screen 160, a list of candidate ubiquitous languages generated by the ubiquitous language generation unit 13 is displayed in a 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 a "Move" button 163 in the center of the screen. To cancel a term 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 a "Back" button 164 to cancel the move.

For example, the following are registered as ubiquitous language candidates: "customer," "policyholder," "insurance business operator (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 the left-hand column 161 have been moved to the ubiquitous language column on the right-hand side 162.

Furthermore, when the user presses the "Edit" button 165, an editing window is displayed, allowing the user to change the name of the ubiquitous language or add a new one. After selecting and editing all ubiquitous languages, the user can press the "OK" button at the bottom to send the ubiquitous language to the ubiquitous language generation unit 13, and transition to the example display of subdomain information in Figure 17.

[Example of subdomain information display]
Next, examples of displaying sub-domain 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 confirming 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 a file of organizational information 171 and a file of business information 172 to which this use case description is related. The organizational information 171 may be the names of departments, teams, etc. related to the use case description, and may be passed in text format, or in a spreadsheet file format. The business information 172 may be the names of departments and roles related to the use case description, and may be passed in text format, or in a spreadsheet file format.

In the subdomain information display area 173, the subdomain information candidates are displayed in a switchable tab display, and multiple subdomain information candidates can be switched and displayed. In FIG. 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 sub-domain candidate information is displayed: "Access (browser/smartphone)," "Authentication/authorization," "Contract information management," "System operation," "Product registration," "Product viewing," "Application," "Inspection," "Appraisal," "Insurance premium payment," "Policy shipping," "Insurance claim application," "Review," "Insurance payment," "Progress management (policyholder/business)," and "Notification."

[Example of editing subdomain information]
FIG. 18 is a diagram showing an example of a display for editing subdomain information.
18, the user can draw arrows showing connections between subdomains according to the flow of work 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 displaying attribute information for subdomain information]
FIG. 19 is a diagram showing a display example of attribute information of sub-domain 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 is edited to belong to one of a support subdomain 191, a core subdomain 192, and a general-purpose subdomain 193. For example, each subdomain is easily distinguished from other subdomains by changing the display color or line type for the support subdomain 191, the core subdomain 192, and the general-purpose subdomain 193.

After the user has finished editing the subdomain information, by pressing the "OK" button at the bottom, the currently displayed subdomain candidate information is sent to the subdomain information output unit 14, and the display transitions to the example of context information 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 is a diagram showing a display example of the user interface unit 11 for confirming and editing context information.

In FIG. 20, an interface screen 200 is shown as an example of the display of context information. 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 attribute information in the form of subdomains of the support subdomain 191 (product viewing, etc.), the middle row displays attribute information in the form of subdomains of the core subdomain 192 (assessment), and the lower row displays attribute information in the form of subdomains of the general-purpose subdomain 193 (insurance payment, etc.).

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

After the user has finished editing the context information, by pressing the "OK" button at the bottom, the context information is sent to the context information output unit 15, and the display transitions to the example context map of FIG. 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 FIG. 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 editing of the context information in FIG. 20 is 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 open 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 the contexts. Furthermore, the user can add strings representing the connection method between the 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, by pressing the "OK" button at the bottom, the context map is sent to the microservice information output unit 16, and the display transitions to the example of microservice information 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 microservice candidate information (microservice candidate 1 in the figure) is highlighted on a context map created by the user. The microservice candidate information displays the microservice candidate information created by the microservice information output unit 16. The display of the microservice candidate information shows an example in which the corresponding context is surrounded by a line (e.g., a border 221) that highlights the corresponding context. As another display method, the corresponding context may be changed in color or blinked.

[Hardware configuration of the microservice design support system]
FIG. 23 is a diagram illustrating an example of a hardware configuration of the microservice design support system 10.
The microservice design support system 10 includes, as hardware, a calculator 230. The calculator 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 FIG. 2.

The processor 231 reads the data stored in the storage device 233 into the main memory 232, and executes the processing of the software program using the main memory 232. The processor 231 executes the software program to realize 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 FIG. 2.

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 input by a user through a keyboard, mouse, etc. The information input 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 of this embodiment is a microservice design support system that supports the user in deciding 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) to a 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 a 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 the present embodiment having the above configuration, it is possible to systematize the organization of steps (generation of sub-domain information) included in a business process based on input information (text information of use cases) related to the business process (business domain) of a customer, and to support the creation of microservices. In other words, it is possible to realize design support for microservices that does not depend on individuals.
This has the effect of stabilizing design quality without relying on the intuition or experience of a skilled worker.

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 a candidate diagram (microservice map) of microservice boundaries relating to the corresponding relationships of each process included in the business process based on the context information.

With this configuration, in this embodiment, microservice candidate information can be automatically displayed, so that even those with no experience can identify the parts of a business process that should be turned into microservices.

The microservice design support system according to this embodiment further 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 the subdomain information and the 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 the 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 the past microservice design information.

The present invention is not limited to the above-described embodiment, and various other applications and modifications are possible without departing from the gist of the present invention as described in the claims. For example, the above-described embodiment describes the configuration in detail and specifically in order to explain the present invention in an easy-to-understand manner, and is not necessarily limited to having all of the components described. In addition, it is also possible to add, replace, or delete other components from part of the configuration of the embodiment.

Furthermore, the above-mentioned configurations, functions, processing units, etc. may be realized in part or in whole in hardware, for example by designing them as integrated circuits. As the hardware, a broad processor device such as an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit) may be used.

Furthermore, each component of the microservice design support system 10 according to the above-described embodiment may be implemented in any hardware as long as each piece of 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.

In addition, in the microservice design support system 10 of the above-mentioned embodiment, the control lines and information lines are those that are considered necessary for explanation, and not all control lines and information lines are necessarily shown in the product. In reality, it can be considered that almost all components are connected to each other.

In addition, in this specification, the 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 the 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 section, 12...Use case input section, 13...Ubiquitous language generation section, 14...Subdomain information output section, 15...Context information output section, 16...Microservice information output section, 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 the determination of areas to be converted into microservices in a user's business process,
a use case input unit into which a use case related to the user's business process is input as text information;
a ubiquitous language generation unit that generates a ubiquitous language related to a component included in the text information of the use case input to the use case input unit;
and a subdomain information output unit that groups use cases including matching or similar elements based on the ubiquitous language and the use cases, and further subgroups 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 sub-domain 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;
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 text information of the grouped use cases based on whether the information is similar in the business process, thereby generating subdomain information. A microservice design support system that helps users decide which areas of their business processes to turn into microservices has a computer equipped with
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 step of grouping use cases including elements having 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 be executed.

Images