A method, system and computer readable storage medium for boundary context recognition based on business semantic analysis

Abstract

The application relates to the field of software engineering and system architecture design, and provides a boundary context recognition method and system based on business semantic analysis and a computer readable storage medium, which comprises the following steps: performing semantic layer reasoning on an obtained business requirement document to obtain business semantic elements; the business semantic elements of the business requirement document are mapped into nodes and connecting edges according to preset mapping rules to obtain a business semantic coupling graph; a community is formed by recognizing a high-cohesion node set in the business semantic coupling graph through a graph algorithm to obtain an initial boundary context corresponding to the community; a heuristic rule is applied to perform dynamic graph operation on the initial boundary context to obtain a final boundary context; and a visual interface is generated to display the final boundary context and an interaction relationship set between different final boundary contexts. The application realizes automatic discovery of the boundary context in an early design stage based on the business requirement document, does not depend on existing codes and text similarity, and guarantees the accuracy of automatic recognition of the context.

Description

Technical Field

[0001] This application relates to the fields of software engineering and system architecture design, and in particular to a boundary context identification method, system, and computer-readable storage medium based on business semantic analysis. Background Technology

[0002] With the deepening of digital transformation, the scale and business complexity of modern complex large-scale software systems continue to increase. Microservice architecture, due to its advantages such as high scalability, independent deployment, and flexible technology stack, has become the mainstream architectural pattern for such systems. In the process of microservice architecture design, the reasonable division of service boundaries is the core challenge that determines the stability, maintainability, and business adaptability of the system. Improper boundary division will lead to a series of problems such as high coupling between services, difficulty in guaranteeing transaction consistency, and chaotic business logic.

[0003] Domain-Driven Design (DDD), as a mainstream methodology for solving complex business modeling, proposed the strategic design concept of "bounded context". Its core idea is to divide a large business domain into several highly cohesive and loosely coupled business subdomains. Each subdomain corresponds to a bounded context, and each bounded context can be directly mapped to an independent microservice unit. Therefore, the identification and division of bounded contexts is recognized as the gold standard for guiding microservice decomposition.

[0004] In practical engineering, the identification and division of boundary contexts can be achieved through the following methods: First, manually dividing the context through workshops such as event storming; this method is time-consuming and labor-intensive, and the results are highly dependent on the subjective experience of the participants, making it difficult to guarantee consistency and reusability. Second, identifying potential module boundaries by analyzing the code structure of existing systems; this method relies on existing system code and is not suitable for the early stages of system design from scratch. Third, performing natural language processing on requirements documents, using keyword co-occurrence, LDA topic modeling, or semantic vector similarity to cluster text paragraphs, attempting to use the clustering results as context boundaries; however, since high cohesion in the business domain does not simply refer to "similar text descriptions," but rather to "tight coupling of business functions and data in transactions," this method cannot capture the coupling characteristics and semantic differences of business transactions and is not suitable for domain-driven design.

[0005] Therefore, how to achieve automated or semi-automated assisted identification of boundary contexts, and characterize the coupling relationships of business transactions and the boundaries of business lifecycles, has become a key technical problem that urgently needs to be solved in the field of software engineering. Summary of the Invention

[0006] This application provides a boundary context identification method, system, and computer-readable storage medium based on business semantic analysis. It does not rely on existing code and automatically discovers boundary contexts in the early design stage based solely on business requirement documents, thus characterizing the coupling relationship of business transactions and the boundaries of the business lifecycle.

[0007] According to a first aspect of the embodiments of this application, a boundary context recognition method based on business semantic analysis is provided, the method comprising: Obtain the business requirements document; By using entity recognition, temporal extraction, and dependency parsing, semantic layer reasoning is performed on business requirement documents to obtain structured business semantic elements. According to the preset graphing rules, the business concepts of business semantic elements are mapped as nodes, and the interactions between business semantic elements are mapped as connection edges with comprehensive weights, resulting in a business semantic coupling graph. The comprehensive weights indicate the strength of logical dependencies between business semantic elements. By using graph algorithms to identify highly cohesive sets of nodes in the business semantic coupling graph to form communities, the initial boundary context of the community in the business requirement document is obtained. Based on the internal structure and external connections of the initial bounded context, heuristic rules are applied to perform dynamic graph operations on the business semantic coupling graph to correct the boundaries, resulting in the final bounded context corresponding to the community in the business requirements document after the update; among which, the heuristic rules are set based on domain-driven design modeling experience; A visualization interface is generated to display the final boundary context and the set of interaction relationships between different final boundary contexts.

[0008] Optionally, the dimensions corresponding to the structured business semantic elements include business entity dimension, business event dimension, association strength dimension, transaction consistency dimension, data flow dependency dimension, and language co-occurrence dimension.

[0009] Optionally, according to preset graphing rules, the business concepts of business semantic elements are mapped as nodes, and the interactions between business semantic elements are mapped as weighted connection edges, resulting in a business semantic coupling graph, including: Identify noun concepts with unique identifiers and lifecycles from business semantic elements and map these noun concepts to entity nodes; identify verb concepts representing domain state changes from business semantic elements and map these verb concepts to event nodes, including entity nodes and event nodes; The interaction between two business semantic elements is mapped to the connection between the corresponding two nodes; according to the weight calculation rules, the comprehensive weight is calculated based on the transaction consistency level, data flow dependency strength and language co-occurrence normalization value between the two business semantic elements, and the comprehensive weight is assigned to the connection to obtain the connection edge. Among them, the transaction consistency level is used to indicate the strength of the technical constraints for maintaining atomic consistency between two business semantic elements in the same business transaction; the data flow dependency strength is used to indicate that the output of a business activity in one business semantic element is the input of a business activity in another business semantic element; and the language co-occurrence normalization value is used to indicate the frequency and distance at which two business semantic elements appear simultaneously in the business requirements document.

[0010] Optionally, the weight calculation rules are as follows: W(e ij ) = α · T ij + β · D ij + γ · L ij ; ij Among them, e ij It is the edge connecting node i and node j, W(e ij ) represents the combined weight between node i and node j, α is the weight coefficient for the transaction consistency dimension, and T ij ∈ {0,1,2},T ij It represents the transaction consistency level, β is the weighting coefficient of the data flow dependency dimension, and D... ij ∈ [0,1], D ij It represents the strength of data dependency, γ is the weighting coefficient of the language co-occurrence dimension, and L... ij ∈ [0,1], L ij It is the language co-occurrence normalized value, and α β γ.

[0011] Optionally, a community is formed by identifying highly cohesive node sets in the business semantic coupling graph using a graph algorithm, and the initial bounded context corresponding to the community in the business requirement document is obtained, including: A graph algorithm is used to analyze the business semantic coupling graph. The nodes in the semantic coupling graph are divided into multiple communities according to a preset partitioning standard. The initial boundary context in the business requirement document is obtained based on the community mapping in the semantic coupling graph. The graph algorithms include the Leuven community detection algorithm, the Leiden community detection algorithm, and the Guilvan-Newman community detection algorithm. The preset partitioning criteria ensure that the combined weight of the edges connecting nodes within a community is greater than a first preset value, and the combined weight of the edges connecting nodes between different communities is less than a second preset value, where the first preset value is greater than or equal to the second preset value. The initial boundary context includes the community number, the list of nodes within the community, the combined weight of the edges connecting nodes within the community, and the combined weight of the edges connecting nodes within the community to nodes outside the community.

[0012] Optional heuristic rules include hub event segmentation rules, common language ambiguity detection rules, and role perspective separation rules.

[0013] Optional, hub event segmentation rules include: Extract the business semantic elements corresponding to the target node as the target business semantic elements, and extract the business semantic elements corresponding to the adjacent nodes of the target node as the adjacent business semantic elements. When the transaction consistency level between the target business semantic element and the adjacent business semantic elements is determined to be strong, and the event state of the target business semantic element is different from the event state of the adjacent business semantic elements, the target business semantic element is determined to be a business hub event. The node corresponding to the business hub event in the business semantic coupling graph is taken as the hub node; Using the hub node as the dividing point, sever the strong connection edges between the predecessor and successor nodes of the hub node; The hub node's predecessor and successor nodes are assigned to different communities, and the hub node serves as an asynchronous message contract between the communities where the predecessor and successor nodes reside.

[0014] Optionally, the method for obtaining the set of interaction relationships between different final boundary contexts includes: based on the bridge edges between different communities in the business semantic coupling graph after the boundary correction, transforming the interaction relationships between the business semantic elements corresponding to the nodes of the bridge edges, and summarizing them into a set of interaction relationships between the final boundary contexts based on the business semantic elements in the final boundary context; wherein, the bridge edges are the connecting edges between nodes of different communities. The visualization interface is also used to display risk warnings. The triggering process for risk warnings includes: calculating key indicators and potential risk values ​​based on the comprehensive weight of the connection edges between nodes in the business semantic coupling graph after boundary correction; when a key indicator or potential risk value triggers the corresponding indicator threshold, the risk warning and connection edge are displayed on the visualization interface so that the client can generate corresponding node edge control instructions based on the risk warning, causing the server to disconnect the connection edge between the corresponding nodes according to the node edge control instructions; among them, key indicators include modularity, which is displayed on the visualization interface, and potential risk values ​​include the probability of hub event risk, the probability of language ambiguity risk, and the probability of transaction consistency imbalance risk.

[0015] According to a second aspect of the embodiments of this application, a boundary context recognition system based on business semantic analysis is provided, including a server and a client, wherein the server includes: The requirements document acquisition module communicates with the client and is used to obtain business requirements documents from the client. The requirement semantic parsing module, connected to the requirement document acquisition module, is used to perform semantic layer reasoning on business requirement documents through entity recognition, temporal extraction, and dependency parsing to obtain structured business semantic elements. The semantic graph construction module, connected to the requirement semantic parsing module, is used to map the business concepts of business semantic elements as nodes and the interactions between business semantic elements as connection edges with comprehensive weights, to obtain a business semantic coupling graph. The comprehensive weights indicate the strength of logical dependencies between business semantic elements. The context discovery module, connected to the semantic graph construction module, is used to identify highly cohesive sets of nodes in the business semantic coupling graph to form communities through graph algorithms, and to obtain the initial boundary context of the community in the business requirement document. The rule storage module is used to store heuristic rules set based on domain-driven design modeling experience; The context correction module, connected to the context discovery module and the rule storage module, is used to apply heuristic rules to perform dynamic graph operations on the business semantic coupling graph based on the internal structure and external connections of the initial boundary context in order to correct the boundary and obtain the final boundary context corresponding to the community in the business requirement document after the update. The risk indicator calculation module, connected to the context correction module, is used to calculate key indicators and potential risk values ​​based on the comprehensive weight of the connection edges between nodes in the business semantic coupling graph after boundary correction. Key indicators include modularity, and potential risk values ​​include the probability of hub event risk, the probability of language ambiguity risk, and the probability of transaction consistency imbalance risk. The visualization module, connected to the context correction module and the risk indicator calculation module, is used to generate a visualization interface that displays the final boundary context and the set of interaction relationships between different final boundary contexts, and displays the corresponding risk warning when the key indicator or potential risk value triggers the corresponding indicator threshold. The feedback module, connected to the client, is used to disconnect the connection edge between the corresponding nodes and update the final boundary context after an alarm is triggered when the potential risk value between nodes in the final boundary context reaches the indicator threshold.

[0016] According to a third aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, wherein when the computer program is executed by a processor, it implements the above-described boundary context recognition method based on business semantic analysis.

[0017] This application includes at least one of the following beneficial technical effects: 1. The process involves extracting business semantic elements through semantic layer reasoning, mapping these elements to business concepts and business associations to obtain a business semantic coupling graph, using graph algorithms to identify highly aggregated node groups with comprehensive weights of connecting edges to obtain the initial boundary context, correcting the initial boundary context using heuristic rules to obtain the final boundary context, and displaying feedback on the interactive interface. This process does not rely on existing code or text similarity, and achieves automatic discovery of boundary context based on business requirement documents, filling the gap in automated architecture assistance tools in the early stages of the software lifecycle.

[0018] 2. The domain-driven design modeling experience of domain experts is transformed into automatically executable heuristic rules. After the initial bounded context is obtained, the heuristic rules are applied for correction. Automatic correction is performed after the initial bounded context is discovered, which improves the accuracy of automatic context recognition. This approach utilizes the statistical capabilities of graph algorithms and integrates the wisdom of domain experts.

[0019] 3. The server issues an alert when a potential risk value between nodes in the final boundary context triggers a threshold indicator. This allows users to send node edge control commands to the server via the client. The server then disconnects the corresponding nodes and updates the final boundary context accordingly. Node edge adjustments are made iteratively based on the potential risk value trigger threshold, ensuring the accuracy of the boundary context identification in the output final boundary context. This process reduces design inconsistencies and oversights caused by human factors, and the generated visual mapping and risk alerts help software architects identify potential architectural threats early in the software lifecycle.

[0020] 4. In the process of obtaining the initial bounding context by identifying the comprehensive weight of the connected edges in the graph algorithm, a high-priority transaction consistency weight is introduced. This overcomes the defect of traditional text clustering methods that cannot identify the boundaries of business transactions, and ensures that the generated initial bounding context meets the data consistency requirements of the microservice architecture.

[0021] 5. When the final boundary context corresponding to the community is at risk, there is no need to start over. It supports cyclical correction using the context correction module and interactive fine-tuning using the feedback module. Attached Figure Description

[0022] Figure 1 This is a flowchart of the boundary context recognition method based on business semantic analysis disclosed in the first embodiment of this application; Figure 2 This is a flowchart of semantic layer reasoning using a large language model; Figure 3 yes Figure 1 Flowchart for step 13; Figure 4It is a flowchart of applying language ambiguity detection rules to perform dynamic graph operations on the business semantic coupling graph; Figure 5 This is a schematic diagram of the asynchronous message contract between the community where the hub node is located (as a preceding node) and the community where the following node is located. Figure 6 This is a diagram illustrating the initial boundary context prior to recognizing "order paid" as a pivotal event; Figure 7 This is a diagram illustrating the final boundary context after "order paid" is identified as a pivotal event; Figure 8 This is a schematic diagram of the boundary context recognition system based on business semantic analysis disclosed in the second embodiment of this application.

[0023] Explanation of reference numerals in the attached figures: 20. Server-side; 30. Client-side; 201. Requirements document acquisition module; 202. Requirements semantic parsing module; 203. Semantic graph construction module; 204. Context discovery module; 205. Rule storage module; 206. Context correction module; 207. Risk indicator calculation module; 208. Visualization module; 209. Feedback module. Detailed Implementation

[0024] The present application will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative of the application and are not intended to limit the scope of the application.

[0025] In the following description, numerous specific details are set forth for illustrative purposes in order to provide a thorough understanding of the inventive concept. As part of this specification, some of the accompanying drawings of this disclosure are block diagrams illustrating structures and devices to avoid complicating the disclosed principles. For clarity, not all features of the actual embodiment need to be described.

[0026] First implementation method: The first embodiment of this application provides a boundary context identification method based on business semantic analysis, applied in the early stages of microservice architecture design in system design, when the requirements document is completed but the code has not yet been written, to assist software architects in defining service boundaries. This boundary context identification method based on business semantic analysis is applicable to new system designs with no existing code available for analysis, microservice decomposition and refactoring when splitting a monolithic application into microservices, and event storming workshops that replace or assist manual event storming in quickly generating initial candidate contexts.

[0027] The following details the implementation of a boundary context recognition method based on business semantic analysis in this embodiment. The following implementation details are provided for ease of understanding and are not essential to this embodiment or solution. The specific process of this embodiment is as follows: Figure 1 As shown, it includes the following steps: Step 11: Obtain the business requirements document.

[0028] Specifically, requirements documents are a standard input product of software engineering; any formal software development project will inevitably generate requirements documents. The business requirements documents in this step support both semi-structured and structured requirements documents. Methods for obtaining business requirements documents include at least one of the following: manual uploading and importing from local documents, automatic retrieval via third-party requirements platform API, real-time online interactive input, retrieval from the enterprise knowledge base, fusion collection of scattered requirements from multiple sources, and standardized completion assisted by a large model.

[0029] In one example, a company plans to develop a comprehensive e-commerce platform that includes the following business functions: user registration and login, member management, product browsing, product search, product recommendation, shopping cart, order management, payment settlement, inventory management, logistics and distribution, after-sales service (including returns and exchanges, complaints), coupons, points, and promotions.

[0030] Input the business requirements document, which includes user stories and use case descriptions, into the system, for example: [User Registration] As a new user, I would like to complete the registration process in order to use the platform's services; [Product Browsing] As a buyer, I want to browse products to understand their details; [Place an order] As a buyer, I want to place an order in order to receive the goods; [Payment Order] As the buyer, I wish to pay for the order in order to complete the transaction; [Deduct Inventory] As a system, once an order is successfully paid, the inventory needs to be deducted atomically. [Creating Logistics] As a system, after an order is successfully paid, a logistics order needs to be created simultaneously...

[0031] Step 12: Through entity recognition, temporal extraction, and dependency parsing, semantic layer reasoning is performed on the business requirements document to obtain structured business semantic elements.

[0032] Specifically, structured business semantic elements are represented by multi-dimensional business semantic elements. The dimensions corresponding to structured business semantic elements include business entity dimension, business event dimension, association strength dimension, transaction consistency dimension, data flow dependency dimension, and language co-occurrence dimension.

[0033] The business semantic elements of the business entity dimension include noun concepts with unique identifiers and lifecycles (such as "order" and "user"); the business semantic elements of the business event dimension include verb concepts that cause changes in business state, usually expressed in the past tense (such as "payment completed"); the business semantic elements of the association strength dimension include the strength of coupling between business entities, between business entities and business events, and between business events; the business semantic elements of the transaction consistency dimension include determining whether two operations must meet the ACID strong consistency requirements, which is the highest priority dimension, where A stands for Atomicity, C for Consistency, I for Isolation, and D for Durability; the business semantic elements of the data flow dependency dimension include describing the logical sequence of inputs and outputs between business activities; and the business semantic elements of the language co-occurrence dimension include the frequency and physical distance of statistical terms appearing in business requirement documents.

[0034] In one example, the system receives input business requirement documents (such as user stories, use case descriptions, etc.), performs semantic layer reasoning using a Large Language Model (LLM), and then performs entity recognition, event extraction, and dependency parsing to output structured business semantic elements.

[0035] The process of semantic-level reasoning using Large Language Models (LLM), such as Figure 2 As shown, the process includes: Step 121: Preprocess the business requirement documents: Clean up the format of the input business requirement documents (user stories, use case descriptions, requirement specifications, etc.), removing redundant information such as headers, footers, comments, and garbled symbols; segment sentences according to sentence boundaries and aggregate paragraphs according to business scenarios; convert semi-structured data such as tables and lists into coherent natural language text to eliminate the interference of format noise on LLM semantic reasoning; format according to semantic annotation specifications. Semantic annotation specifications prohibit free text descriptions and unify entity names, business time classification standards, and dependency syntax mapping rules.

[0036] Step 122, Entity Recognition: Based on global business semantics, LLM performs end-to-end entity mining, classification, normalization and attribute binding on business requirement documents, identifies and labels core entities in business requirement documents, merges synonymous entities, removes non-business entities, and obtains core business entities.

[0037] Step 123, Event Extraction: The LLM scans the business requirements document, identifies event trigger words that represent changes in business behavior or status, and extracts event parameters based on the frequency of occurrence and the time type defined in the business scenario.

[0038] Step 124, Dependency Parsing: LLM captures the core events, triggering conditions, state transitions, execution results, and relationships between events in the business requirements document to obtain the business behavior chain. Based on the temporal and causal relationships corresponding to the event types in the business behavior chain, the syntactic dependency relationships in the business behavior chain are mapped to business semantic relationships, realizing the transformation from syntactic structure to business association.

[0039] Step 125, Global Aggregation and Encapsulation: Globally aggregate the aforementioned output business entities, business events, and semantic relationships. Construct an initial semantic association set with entities and events as nodes and semantic relationships as edges. LLM performs global verification to resolve conflicts, complete implicit information, and eliminate redundancy. According to the preset data format, encapsulate and generate a structured business semantic element package (i.e., structured business semantic elements).

[0040] This step abandons the traditional NLP pipeline toolchain and uses the LLM large model to uniformly complete entity, event, and syntactic analysis, resulting in stronger semantic consistency; it directly outputs DDD-aligned business elements, adapts to boundary context division requirements, and ensures business semantic priority; the structured output does not require post-processing parsing and can be directly used to build business semantic coupling graphs.

[0041] Step 13: According to the preset graphing rules, map the business concepts of the business semantic elements to nodes, and map the interactions between the business semantic elements to connection edges with comprehensive weights, to obtain the business semantic coupling graph.

[0042] Specifically, the composition rules are pre-defined and cannot be changed during the actual execution of this method. (See reference) Figure 3 As shown, step 13 includes: Step 131: Extract business concepts that indicate business entities and business events from the business semantic elements of the business requirements document; Step 132: Map the business concepts to nodes in the business semantic coupling graph; Step 133: Extract the interaction relationships between different business semantic elements in the business requirements document; Step 134: Map the interaction relationship between different business semantic elements to the connection edge between corresponding nodes in the business semantic coupling graph. The comprehensive weight of the connection edge is used to indicate the logical dependency strength between the corresponding two business semantic elements. Step 135: Based on the nodes and the connection edges between nodes in the business semantic coupling graph, obtain the business semantic coupling graph corresponding to the business requirement document.

[0043] In one example, step 132, mapping business concepts to nodes, includes: identifying noun concepts with unique identifiers and lifecycles from business semantic elements and mapping these noun concepts to entity nodes; and identifying verb concepts representing domain state changes from business semantic elements and mapping these verb concepts to event nodes. Nodes include entity nodes and event nodes.

[0044] Mapping the interactions between business semantic elements to connection edges with comprehensive weights includes: mapping the interactions between two business semantic elements to the connection between the corresponding two nodes; and assigning comprehensive weights to the connection edges, wherein the comprehensive weights indicate the logical dependency strength between business semantic elements, i.e., the logical dependency strength between node i and node j.

[0045] In one example, the overall weight is configured directly based on the logical dependency strength between business semantic elements. If the business logic requires strong transactional consistency between two business semantic elements (e.g., ACID atomic operations, which must both succeed or fail simultaneously), then a high overall weight is assigned to the connection between the nodes of the corresponding business semantic elements, prompting them to be grouped into the same bounded context during clustering. If the business association between two business semantic elements does not require strong ACID transactional guarantees, and the business allows for eventual consistency and supports asynchronous processing, it indicates that the business coupling between the two is low. In this case, a low overall weight is assigned to the connection between the nodes of the corresponding business semantic elements, providing the core topology determination basis for the community discovery algorithm to identify the boundary of the bounded context.

[0046] In another example, the comprehensive weight is calculated according to the weight calculation rules, based on the transaction consistency level, data flow dependency strength, and language co-occurrence normalization value between the two business semantic elements.

[0047] The weight calculation rule is: W(e) ij ) = α · T ij + β · D ij + γ · L ij .

[0048] Among them, e ij The edge connecting node i and node j, W(e ij ) is the combined weight of the edge connecting node i and node j. α is the weighting coefficient for the transaction consistency dimension, and T ij ∈ {0,1,2},T ij β is the transaction consistency level, which indicates the strength of the technical constraints that maintain atomic consistency between two business semantic elements within the same business transaction. β is the weighting coefficient for the data flow dependency dimension, and D... ij ∈ [0,1], D ijγ is the data dependency strength, which indicates that the output of a business activity in one business semantic element is the input of a business activity in another business semantic element. L is the weighting coefficient for the language co-occurrence dimension. ij ∈ [0,1], L ij This is the language co-occurrence normalization value, which indicates the frequency and distance at which two business semantic elements appear simultaneously in a business requirements document. The weighting coefficients α, β, and γ are all pre-set and cannot be changed during actual operation. .

[0049] Step 14: Use graph algorithms to identify highly cohesive node sets in the business semantic coupling graph to form communities, and obtain the initial boundary context of the community in the business requirement document.

[0050] Specifically, after obtaining the business semantic coupling graph corresponding to the business requirement document in step 13, the community detection algorithm (hereinafter referred to as graph algorithm) in graph theory is used to analyze the business semantic coupling graph. According to the preset division criteria, "when the comprehensive weight of the connecting edge is greater than a first preset value, the two nodes corresponding to the connecting edge are determined to be assigned to the same community; when the comprehensive weight of the connecting edge is less than or equal to a second preset value, the two nodes corresponding to the connecting edge are determined to be assigned to different communities, and the first preset value is greater than or equal to the second preset value," the nodes in the semantic coupling graph are divided into multiple communities, and the communities in the semantic coupling graph are mapped to the initial boundary context in the business requirement document. The preset division criteria ensure that there are many connecting edges between nodes within a community and the comprehensive weight of the connecting edges is high, indicating close connections within the community; and that there are few connecting edges between nodes within a community and nodes outside the community and the comprehensive weight of the connecting edges is low, indicating sparse connections between communities. Each community in the business semantic coupling graph includes a community number, a list of nodes within the community, the comprehensive weight of the connecting edges between nodes within the community, and the comprehensive weight of the connecting edges between nodes within the community and nodes outside the community. The edges connecting nodes within a community to nodes outside the community are called bridge edges of the community, and the edges connecting nodes within a community are called internal edges of the community.

[0051] In one example, graph algorithms include community detection algorithms such as the Louvain algorithm, the Leiden algorithm, and the Girvan-Newman algorithm.

[0052] The Leuven community detection algorithm is a bottom-up agglomerative greedy algorithm with maximizing modularity Q as its core objective. It employs a two-stage iterative approach of local modularity optimization and network-level aggregation, exhibiting complexity but making it the preferred algorithm for ultra-large-scale business semantic graphs. The Leiden community detection algorithm adds a community refinement stage to the Leuven algorithm, ensuring efficiency while improving partitioning accuracy and community connectivity. The Guilvan-Newman community detection algorithm is a top-down splitting algorithm that traverses all connecting edges in the business semantic coupling graph. It calculates edge betweenness based on the comprehensive weight of the connecting edges to identify bridge edges connecting different communities, gradually removing these bridge edges to achieve community partitioning. It is suitable for high-precision boundary mining in small to medium-sized business semantic graphs.

[0053] In one example, the first preset value and the second preset value are equal. If the combined weight of the connecting edges between nodes is greater than or equal to the first preset value, the two nodes are classified into different communities; if the combined weight of the connecting edges between nodes is less than the first preset value, the two nodes are classified into the same community.

[0054] In another example, the first preset value is greater than the second preset value. If the combined weight of the connecting edges between nodes is greater than or equal to the first preset value, the two nodes are classified into different communities. If the combined weight of the connecting edges between nodes is greater than or equal to the second preset value but less than the first preset value, the combined weight and the corresponding business semantic elements of the two nodes are displayed, allowing users to determine the community classification result of the two nodes by sending commands through the client. If the combined weight of the connecting edges between nodes is less than the second preset value, the two nodes are classified into the same community. It is worth mentioning that when the combined weight of the connecting edges between nodes is greater than or equal to the second preset value but less than the first preset value, the community classification of the two nodes can also be determined by other set determination methods. The method of displaying the combined weight and the corresponding business semantic elements of the two nodes can be either directly displayed through a visual interface or the content to be displayed can be directly sent to the client for users to view.

[0055] In one example, before the community detection algorithm runs, all strong-weighted edges are frozen, preventing them from being split, and context partitioning is only allowed on weak-weighted edges. After the community detection algorithm runs, initial bounded contexts (i.e., communities) are obtained. If the number of strong transactional connected components within a community reaches a certain standard, automatic rollback or re-aggregation occurs. The community detection algorithm is run again on the results of the automatic rollback or re-aggregation, implementing the loop in step 14, until the number of strong transactional connected components in all communities falls below the standard. Strong transactional connected components represent two business semantic elements that are logically inseparable. Strong transactional connected components can be determined by whether the comprehensive weight of the connecting edges is a high value.

[0056] It is important to emphasize that the initial bounded context output by the community discovery algorithm in step 14 is only the initial community partitioning result, not the final result. These initial bounded contexts are aggregated based on statistical features and have not yet been validated using domain-driven design principles.

[0057] Step 15: Based on the internal structure and external connections of the initial boundary context, apply heuristic rules to perform dynamic graph operations on the business semantic coupling graph to correct the boundary, and obtain the final boundary context corresponding to the updated community in the business requirements document.

[0058] Specifically, the internal structure of the initial boundary context indicates the internal edges of the corresponding community (i.e., the connecting edges between nodes within the community), and the external connections of the initial boundary context indicate the bridge edges of the corresponding community (i.e., the connecting edges between nodes within and outside the community). Heuristic rules are machine-executable rules derived from Domain-Driven Design (DDD) modeling experience. Applying heuristic rules to perform dynamic graph operations on the business semantic coupling graph changes the community partitioning results in the business semantic coupling graph, yielding the updated final boundary contexts for each community.

[0059] In one example, domain-driven design modeling experience is transformed into machine-executable rules. This process includes: extracting experience related to transaction consistency, business phases, responsible parties, aggregation and cohesion, and semantic uniqueness from the domain-driven design modeling experience; de-subjectivizing fuzzy experience and transforming it into structured features; and encapsulating and mapping these structured features into machine-executable conditional judgment rules, weight calculation rules, and topological constraint rules. This process can be performed on the server side, where the machine-executable rules are then applied as heuristic rules during the execution of step 15. Alternatively, this process can be performed off-server, where the off-server side transmits the machine-executable rules as heuristic rules to the server side, which then invokes them during the execution of step 15.

[0060] In one example, the heuristic rules include a hub event segmentation rule, a universal language ambiguity detection rule, and a role perspective separation rule. These rules are logically collaborative and dynamically triggered, rather than completely isolated.

[0061] refer to Figure 4 As shown, the methods for applying hub event segmentation rules to perform dynamic graph operations on the business semantic coupling graph to correct the boundaries include: Step 141: Identify the hub events of the initial boundary context in the hub nodes corresponding to the business semantic coupling graph; Step 142: Using the hub node as the split point, cut off the strong connection edge between the hub node's predecessor node (also known as the predecessor business process node cluster) and the hub node's successor node (also known as the successor business process node cluster). Step 143: Assign the predecessor and successor nodes of the hub node to different communities, while retaining the asynchronous message contract between the hub node and the communities of its predecessor and successor nodes. (See reference) Figure 5 As shown, in step 141, the strong connection between the predecessor node a and the successor node c of the hub node b is broken. The predecessor node a of the hub node b is assigned to community A, and the successor node c of the hub node b is assigned to community C. The hub node b is abstracted as a domain event node. The hub node b serves as an asynchronous message contract between community A and community C, and the message structure, business semantics, and triggering conditions for cross-context interaction between community A and community C are standardized.

[0062] The process of identifying the business hub event in the initial boundary context at the corresponding hub node in the business semantic coupling graph includes: extracting the business semantic elements corresponding to the target node as the target business semantic elements; extracting the business semantic elements corresponding to the adjacent nodes of the target node as adjacent business semantic elements; determining the target business semantic element as a business hub event when the transaction consistency level between the target business semantic element and the adjacent business semantic elements is determined to be strong, and the event state of the target business semantic element is different from the event state of the adjacent business semantic elements; and identifying the node corresponding to the business hub event in the business semantic coupling graph as the hub node. A strong connection edge refers to a connection edge between nodes with a comprehensive weight greater than or equal to a third preset value, which is pre-set and cannot be changed during method execution.

[0063] The method of applying language ambiguity detection rules to perform dynamic graph operations on the business semantic coupling graph to correct the boundaries includes: identifying ambiguous language terms with different meanings in different contexts in the initial boundary context; business semantic elements containing ambiguous language terms are called ambiguous semantic elements; the nodes corresponding to the ambiguous semantic elements in the business semantic coupling graph are called ambiguous nodes; splitting the ambiguous nodes into at least two independent nodes; assigning different independent nodes to different communities; and classifying the ambiguous language terms in the business semantic elements corresponding to each independent node into the same contextual meaning.

[0064] The method of applying role perspective separation rules to perform dynamic graph operations on the business semantic coupling graph to correct the boundary includes: keeping the two initial boundary contexts independent when the main operator roles of the two initial boundary contexts are different and their responsibilities conflict.

[0065] In one example, dynamic graph operations on the business semantic coupling graph include cutting edges, splitting node clusters, and merging node clusters. When a heuristic rule determines that two nodes should not be in the same community (e.g., a hub node is identified), the connection between the two nodes is forcibly disconnected. When a heuristic rule determines that a node should be split (e.g., the meaning of "product" differs in different contexts), the node is split into multiple independent nodes (one independent node corresponds to one meaning of "product" in different contexts), and the boundary context is redefined. When a heuristic rule determines that there are extremely strong business transaction consistency requirements between different node clusters, these node clusters are merged into a single node.

[0066] Corresponding to the example in step 11, the final boundary context obtained in step 15 is: [User Account Context] User, Account, Login, Registration, Authentication; [Product Catalog Context] Products, SKUs, Categories, Tags, Search, Recommendations; [Transaction Context] Orders, shopping cart, payment, coupons, points; [Inventory Fulfillment Context] Inventory, warehousing, logistics order, logistics tracking;

Customer Service Context

[0067] The "Order Paid" event was identified as a hub event, and the event was segmented according to the hub event segmentation rules. Figure 6 The initial bounding context is used to perform dynamic graph operations to correct the boundary, resulting in... Figure 7 The final bounding context shown is the node corresponding to the hub event, which serves as an asynchronous message contract between the two final bounding contexts: the "transaction context" and the "inventory fulfillment context".

[0068] The ambiguous term "customer" was identified, which has different meanings in the context of account login and customer service. The nodes corresponding to the business semantic elements containing "customer" were split according to their contextual meanings into nodes corresponding to the business semantic elements containing "customer" in the context of account login and nodes corresponding to the business semantic elements containing "customer" in the context of customer service. These two nodes were then assigned to two communities, which correspond to the two final boundary contexts of "user account context" and "customer service context".

[0069] Step 16: Generate a visualization interface that displays the final boundary context, risk warnings, and the set of interactions between different final boundary contexts.

[0070] Specifically, the method for obtaining the set of interaction relationships between different final boundary contexts includes: transforming the interaction relationships between the business semantic elements corresponding to the nodes of the bridge edge into the bridge edge based on the bridge edge between different communities in the business semantic coupling graph after the boundary correction (i.e., the bridge edge between different communities after step 15); and summarizing the business semantic elements in the final boundary context into the set of interaction relationships between the final boundary contexts.

[0071] Based on the comprehensive weight of the connecting edges between nodes in the business semantic coupling graph after boundary correction, key indicators and potential risk values ​​are calculated; when a key indicator or potential risk value triggers the corresponding indicator threshold, a risk warning is displayed on the visualization interface.

[0072] Key metrics include modularity Q, which measures both overall cohesion and coupling. Q ranges from -1 to 1; a larger Q indicates higher overall cohesion, lower coupling, and a more reasonable boundary context division. The formula for calculating Q is... Where Q represents the modularity, The sum of the weights of all connecting edges in the business semantic coupling graph, where C represents the current community. For the collection of all communities, The sum of the weights of the internal edges of community C. This represents the sum of the combined weights of the internal edges and bridge edges in community C.

[0073] The potential risk value includes the probability of a hub event, the probability of linguistic ambiguity, and the probability of transaction consistency imbalance. The hub event probability is the probability of a hub node emerging within the community; the linguistic ambiguity probability is the probability of an ambiguous node appearing within the community; and the transaction consistency risk probability is the probability of transaction consistency problems arising when two strong transaction nodes are split into different contexts. The potential risk value is a machine-executable risk score calculated from business semantic features, transaction constraints, and topological relationships.

[0074] The steps described above are only for clarity. In practice, they can be combined into one step or some steps can be broken down into multiple steps. As long as they involve the same logical relationship, they are all within the scope of protection of this patent. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, as long as they do not change the core design of the algorithm and process, are also within the scope of protection of this patent.

[0075] Second implementation method: The second embodiment of this application provides a boundary context recognition system based on business semantic analysis. The boundary context recognition system based on business semantic analysis includes a server and a client. The server and client can be two interconnected physical devices, and the communication connection can be wired data transmission or wireless network communication. Alternatively, the server and client can reside in the same device, which is functionally divided into two areas: one area acts as the server, and the other as the client, with data transfer supported between the two areas.

[0076] Boundary context recognition systems based on business semantic analysis, such as Figure 8 As shown, it includes a server 20 and a client 30. The server 20 includes: The requirement document acquisition module 201 communicates with the client 30 and is used to acquire business requirement documents from the client 30. The requirement document acquisition module 201 supports receiving business requirement documents sent from the client 30. These documents can be edited by the user on the client 30 and sent to the server 20, or they can be obtained by the client 30 from a third-party database. The requirement document acquisition module 201 also supports directly acquiring business requirement documents; users can directly input business requirement documents into the server 20 after logging in.

[0077] The requirement semantic parsing module 202, connected to the requirement document acquisition module 201, is used to perform semantic layer reasoning on the business requirement document through entity recognition, time extraction and dependency parsing to obtain structured business semantic elements.

[0078] The semantic graph construction module 203, connected to the requirement semantic parsing module, is used to map the business concepts of business semantic elements as nodes and the interactions between business semantic elements as connection edges with comprehensive weights, thus obtaining a business semantic coupling graph. The comprehensive weights indicate the strength of logical dependencies between business semantic elements.

[0079] The context discovery module 204, connected to the semantic graph construction module 203, is used to identify highly cohesive node sets in the business semantic coupling graph using graph algorithms. Based on these highly cohesive node sets, communities are formed, and the initial boundary context corresponding to each community in the business requirement document is obtained. Graph algorithms include the Leuven community discovery algorithm, the Leiden community discovery algorithm, and the Guilvan-Newman community discovery algorithm.

[0080] The rule storage module 205 is used to store heuristic rules set based on domain-driven design modeling experience. Heuristic rules include hub event segmentation rules, common language ambiguity detection rules, and role perspective separation rules.

[0081] The context correction module 206, connected to the context discovery module 204 and the rule storage module 205, is used to apply heuristic rules to perform dynamic graph operations on the business semantic coupling graph to correct the boundary based on the internal structure and external connections of the initial boundary context, so as to obtain the final boundary context corresponding to the community in the business requirement document after the update.

[0082] The risk indicator calculation module 207, connected to the context correction module 206, is used to calculate key indicators and potential risk values ​​based on the comprehensive weights of the connecting edges between nodes in the business semantic coupling graph after boundary correction. Key indicators include modularity, and potential risk values ​​include the probability of hub event risk, the probability of language ambiguity risk, and the probability of transaction consistency imbalance risk.

[0083] The visualization module 208, connected to the context correction module 206 and the risk indicator calculation module 207, generates a visualization interface to display the final boundary context and the set of interaction relationships between different final boundary contexts. It displays corresponding risk warnings when key indicators or potential risk values ​​trigger their respective indicator thresholds. After the server 20 displays risk warnings through the visualization interface, it can directly return to the context correction module 206 for iterative correction until key indicators and potential risk values ​​no longer trigger indicator thresholds. Alternatively, it can directly enter the feedback module 209, which, based on user-defined node edge control commands, disconnects the connection edges between corresponding nodes to achieve interactive fine-tuning of the final boundary context until key indicators and potential risk values ​​no longer trigger indicator thresholds. When a risk exists in the community's corresponding final boundary context, it does not need to restart; it supports iterative correction using the context correction module 206 and interactive fine-tuning using the feedback module 209.

[0084] Feedback module 209, connected to client 30, is used to disconnect the connection edge between corresponding nodes and update the final boundary context after an alarm is triggered when a potential risk value between nodes in the final boundary context reaches an indicator threshold. The node edge control command can originate from client 30 or be manually entered by the user upon logging into the server.

[0085] Other implementation details and working methods of the boundary context recognition system based on business semantic analysis disclosed in this application are the same as or similar to the boundary context recognition method based on business semantic analysis described above, and will not be repeated here.

[0086] Third implementation method: The third embodiment of this application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described boundary context recognition method based on business semantic analysis.

[0087] The third embodiment of this application also provides an electronic device, including a memory and a processor, wherein the memory is used to store a computer program and the processor is used to execute the computer program to implement the above-described boundary context recognition method based on business semantic analysis.

[0088] For details regarding computer-readable storage media and electronic devices, please refer to the aforementioned detailed introduction to the boundary context recognition method based on business semantic analysis; further details will not be repeated here.

[0089] The above are all preferred embodiments of this application and are not intended to limit the scope of protection of this application. Therefore, all equivalent changes made in accordance with the structure, shape and principle of this application should be covered within the scope of protection of this application.

Claims

1. A boundary context recognition method based on business semantic analysis, characterized in that, The methods include: Obtain the business requirements document; By using entity recognition, temporal extraction, and dependency parsing, semantic layer reasoning is performed on the business requirement document to obtain structured business semantic elements. According to the preset graphing rules, the business concepts of the business semantic elements are mapped as nodes, and the interactions between the business semantic elements are mapped as connection edges with comprehensive weights, thus obtaining a business semantic coupling graph. The comprehensive weights indicate the strength of logical dependencies between the business semantic elements. The graph algorithm is used to identify highly cohesive node sets in the business semantic coupling graph to form communities, and the initial boundary context of the community in the business requirement document is obtained. Based on the internal structure and external connections of the initial bounded context, heuristic rules are applied to perform dynamic graph operations on the business semantic coupling graph to correct the boundaries, thereby obtaining the final bounded context corresponding to the community in the business requirement document after the update; wherein, the heuristic rules are set based on domain-driven design modeling experience; A visualization interface is generated to display the final boundary context and the set of interaction relationships between different final boundary contexts.

2. The method according to claim 1, characterized in that, The dimensions corresponding to the structured business semantic elements include business entity dimension, business event dimension, association strength dimension, transaction consistency dimension, data flow dependency dimension, and language co-occurrence dimension.

3. The method according to claim 1, characterized in that, The process of mapping the business concepts of the business semantic elements to nodes according to preset graphing rules, and mapping the interactions between the business semantic elements to weighted connection edges, to obtain a business semantic coupling graph includes: The business semantic elements are used to identify noun concepts with unique identifiers and lifecycles, and these noun concepts are mapped to entity nodes; the business semantic elements are also used to identify verb concepts representing domain state changes, and these verb concepts are mapped to event nodes, where the nodes include the entity nodes and the event nodes. The interaction between two business semantic elements is mapped to the connection between two corresponding nodes; according to the weight calculation rules, the comprehensive weight is calculated based on the transaction consistency level, data flow dependency strength and language co-occurrence normalization value between the two business semantic elements, and the comprehensive weight is assigned to the connection to obtain the connection edge; The transaction consistency level is used to indicate the strength of the technical constraints for maintaining atomic consistency between two business semantic elements in the same business transaction. The data flow dependency strength is used to indicate that the output of a business activity in one business semantic element is the input of a business activity in another business semantic element. The language co-occurrence normalization value is used to indicate the frequency and distance at which two business semantic elements appear simultaneously in the business requirement document.

4. The method according to claim 3, characterized in that, The weight calculation rule is as follows: W(e ij ) = α · T ij + β D ij + γ L ij ; Among them, e ij The edge connecting node i and node j, W(e ij ) is the combined weight of the edge connecting node i and node j, α is the weight coefficient for the transaction consistency dimension, and T ij ∈ {0,1,2},T ij It represents the transaction consistency level, β is the weighting coefficient of the data flow dependency dimension, and D... ij ∈ [0,1], D ij It represents the strength of data dependency, γ is the weighting coefficient of the language co-occurrence dimension, and L... ij ∈[0,1],L ij It is the language co-occurrence normalized value, and α β γ.

5. The method according to claim 1, characterized in that, The step of identifying highly cohesive node sets in the business semantic coupling graph using graph algorithms to form communities, and obtaining the initial boundary context corresponding to the community in the business requirement document, includes: A graph algorithm is used to analyze the business semantic coupling graph. The nodes in the semantic coupling graph are divided into multiple communities according to a preset partitioning standard. The initial boundary context in the business requirement document is obtained by mapping the communities in the semantic coupling graph. The graph algorithms include the Leuven community detection algorithm, the Leiden community detection algorithm, and the Guilvan-Newman community detection algorithm; the preset partitioning criteria ensure that the combined weight of the edges connecting nodes within a community is greater than a first preset value, and the combined weight of the edges connecting nodes between different communities is less than a second preset value, wherein the first preset value is greater than or equal to the second preset value; the initial boundary context includes the community number, the list of nodes within the community, the combined weight of the edges connecting nodes within the community, and the combined weight of the edges connecting nodes within the community and nodes outside the community.

6. The method according to claim 1, characterized in that, The heuristic rules include hub event segmentation rules, common language ambiguity detection rules, and role perspective separation rules.

7. The method according to claim 6, characterized in that, The hub event segmentation rules include: Extract the business semantic elements corresponding to the target node as the target business semantic elements, and extract the business semantic elements corresponding to the adjacent nodes of the target node as the adjacent business semantic elements. When the transaction consistency level between the target business semantic element and adjacent business semantic elements is determined to be strong, and the event state of the target business semantic element is different from the event state of adjacent business semantic elements, the target business semantic element is determined to be a business hub event. The node corresponding to the business hub event in the business semantic coupling graph is taken as the hub node; Using the hub node as the dividing point, sever the strong connection edge between the preceding and following nodes of the hub node; The hub node's predecessor and successor nodes are assigned to different communities, and the hub node serves as an asynchronous message contract between the communities where the predecessor and successor nodes reside.

8. The method according to claim 1, characterized in that, The method for obtaining the set of interaction relationships between different final boundary contexts includes: based on the bridge edges between different communities in the business semantic coupling graph after the boundary is corrected, the interaction relationships between the business semantic elements corresponding to the nodes of the bridge edges are transformed, and the interaction relationships between the final boundary contexts are summarized based on the business semantic elements in the final boundary context; wherein, the bridge edges are the connecting edges between the nodes of different communities. The visualization interface is also used to display risk warnings; the triggering process of the risk warnings includes: calculating key indicators and potential risk values ​​based on the comprehensive weight of the connection edges between nodes in the business semantic coupling graph after boundary correction; when the key indicator or the potential risk value triggers the corresponding indicator threshold, the risk warning is displayed on the visualization interface so that the client can generate corresponding node edge control instructions based on the risk warnings, causing the server to disconnect the connection edges between the corresponding nodes according to the node edge control instructions; wherein, the key indicator includes modularity, the key indicator is displayed on the visualization interface, and the potential risk value includes the probability of hub event risk, the probability of language ambiguity risk, and the probability of transaction consistency imbalance risk.

9. A boundary context recognition system based on business semantic analysis, comprising a server and a client, characterized in that, The server includes: The requirement document acquisition module is connected to the client and is used to acquire business requirement documents from the client. The requirement semantic parsing module, connected to the requirement document acquisition module, is used to perform semantic layer reasoning on the business requirement document through entity recognition, time extraction and dependency parsing to obtain structured business semantic elements. The semantic graph construction module, connected to the requirement semantic parsing module, is used to map the business concepts of the business semantic elements as nodes and the interactions between the business semantic elements as connection edges with comprehensive weights, to obtain a business semantic coupling graph. The comprehensive weights indicate the strength of logical dependencies between the business semantic elements. The context discovery module, connected to the semantic graph construction module, is used to identify high-cohesion node sets in the business semantic coupling graph to form communities through graph algorithms, and to obtain the initial boundary context of the community in the business requirement document. The rule storage module is used to store heuristic rules set based on domain-driven design modeling experience; The context correction module, connected to the context discovery module and the rule storage module, is used to apply heuristic rules to perform dynamic graph operations on the business semantic coupling graph to correct the boundary based on the internal structure and external connections of the initial boundary context, so as to obtain the final boundary context corresponding to the community in the business requirement document after the update. The risk indicator calculation module, connected to the context correction module, is used to calculate key indicators and potential risk values ​​based on the comprehensive weight of the connection edges between nodes in the business semantic coupling graph after boundary correction. The key indicators include modularity, and the potential risk values ​​include the probability of hub event risk, the probability of language ambiguity risk, and the probability of transaction consistency imbalance risk. The visualization module, connected to the context correction module and the risk indicator calculation module, is used to generate a visualization interface to display the set of interaction relationships between the final boundary context and different final boundary contexts, and to display the corresponding risk warning when the key indicator or the potential risk value triggers the corresponding indicator threshold. The feedback module, connected to the client, is used to disconnect the connection edge between the corresponding nodes and update the final boundary context after an alarm is triggered when the potential risk value between nodes in the final boundary context reaches the indicator threshold.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the boundary context recognition method based on business semantic analysis as described in any one of claims 1 to 8.

Images