Domain-driven component generation method, system, device and storage medium

Abstract

The embodiment of the application provides a component generation method, system, device and storage medium based on domain driving, and belongs to the technical field of artificial intelligence. The component generation method comprises the following steps: acquiring business process information and plan definition information; performing domain division according to the business process information to obtain a plurality of sub-domains, and determining a plan sub-domain in the plurality of sub-domains; identifying the business process information in the plan sub-domain according to the plan definition information to obtain a plurality of business information texts of the business process; extracting domain nouns of the plan sub-domain from each business information text; encapsulating the domain nouns under the same boundary context within the boundary of the plan sub-domain; performing domain modeling based on the encapsulated plan sub-domain to obtain a domain model, and generating a target plan component according to a code mapping relationship of the domain model. Through the target plan component generated in the embodiment of the application, the reusability of the system between cross-channels can be improved, and the difficulty of development and operation is reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of artificial intelligence, in particular to a component generation method and system based on domain driving, a device and a storage medium. BACKGROUND

[0002] A plan is a process and conclusion of analyzing and calculating how to achieve a target in a specified period in the future and decomposing the target into sub-targets. There are plans in each field in a channel platform, and the plan management process is interspersed in multiple fields. The plan management function exists in different systems in each field.

[0003] In the related art, in the process of adapting to the plan center construction in different systems, the development process is often complex and cannot be reused across systems in different channels, which increases the difficulty of development and operation. SUMMARY

[0004] The main purpose of the embodiments of the present application is to provide a component generation method and system based on domain driving, a device and a storage medium, which can improve the reuse capability across systems in different channels and reduce the difficulty of development and operation.

[0005] To achieve the above purpose, a first aspect of the embodiments of the present application provides a component generation method based on domain driving, which comprises: acquiring business process information and plan definition information; dividing a domain according to the business process information to obtain a plurality of sub-domains, and determining a plan sub-domain in the plurality of sub-domains; identifying the business process information in the plan sub-domain according to the plan definition information to obtain a plurality of business information texts of the business process; extracting domain nouns of the plan sub-domain from each of the business information texts; encapsulating the domain nouns in the same boundary context within the boundary of the plan sub-domain; performing domain modeling based on the encapsulated plan sub-domain to obtain a domain model, and generating a target plan component according to a code mapping relationship of the domain model.

[0006] In some embodiments, the identifying the business process information in the plan sub-domain according to the plan definition information to obtain a plurality of business information texts of the business process comprises: acquiring a preset plan meta-model, wherein the plan meta-model is established according to the composition relationship between sample function modules in a sample business process; identifying a function module related to a plan from the plan meta-model according to the plan definition information; mapping the function module with the business process information, and identifying a plurality of business information texts of the business process according to the mapping result.

[0007] In some embodiments, the business information texts include event information, command information, member information and input information, and the extracting the domain nouns of the plan sub-domain from each of the business information texts comprises: establishing an event map according to the association relationship among the event information, the command information, the member information and the input information; and extracting the domain nouns of the plan sub-domain from the event map.

[0008] In some embodiments, the encapsulating the domain nouns under the same boundary context within the boundary of the plan sub-domain comprises: extracting a common domain noun from the domain nouns; and encapsulating the common domain noun under the same boundary context within the boundary of the plan sub-domain.

[0009] In some embodiments, the encapsulating the domain nouns under the same boundary context within the boundary of the plan sub-domain comprises: determining a boundary context according to the plan definition information; and encapsulating the domain nouns related to the function of the plan sub-domain within the boundary of the plan sub-domain according to the boundary context.

[0010] In some embodiments, the domain division according to the business process information obtains a plurality of sub-domains, and a plan sub-domain is determined in the plurality of sub-domains, which comprises: dividing the domain according to the business process information to obtain a plurality of sub-domains; determining the function attribute in each of the sub-domains, and determining the sub-domain with a general domain function as the plan sub-domain.

[0011] In some embodiments, the generating the target plan component according to the code mapping relationship of the domain model comprises: mapping each of the domain nouns in the domain model to obtain a plurality of code objects; and generating the target plan component according to the plurality of code objects.

[0012] To achieve the above object, a second aspect of the embodiment of the present application proposes a component generation system based on domain driving, which comprises: a data acquisition module, configured to acquire business process information and plan definition information; a domain division module, configured to divide the domain according to the business process information, and determine a plan sub-domain in a plurality of sub-domains; an information identification module, configured to identify the business process information in the plan sub-domain according to the plan definition information to obtain a plurality of business information texts of the business process; a domain noun extraction module, configured to extract domain nouns of the plan sub-domain from each of the business information texts; an encapsulation module, configured to encapsulate the domain nouns under the same boundary context within the boundary of the plan sub-domain; and a component generation module, configured to perform domain modeling based on the encapsulated plan sub-domain to obtain a domain model, and generate a target plan component according to the code mapping relationship of the domain model.

[0013] To achieve the above object, a third aspect of the embodiments of the present application provides an electronic device, comprising a memory and a processor, the memory stores a computer program, and the processor implements the method of the first aspect of the embodiments when executing the computer program.

[0014] To achieve the above object, a fourth aspect of the embodiments of the present application provides a storage medium, which is a computer readable storage medium, and the storage medium stores a computer program, and the computer program is executed by a processor to implement the method of the first aspect of the embodiments.

[0015] The component generation method, system, device and storage medium based on domain driving provided by the present application can be applied in a component generation system based on domain driving. By executing the component generation method, the business process information can be identified through the plan definition information. After the plan sub-domain is divided according to the business process information, a plurality of business information texts in the plan sub-domain are identified, and the domain nouns of the plan sub-domain are extracted. In order to further limit the boundary, the application of the boundary context in the domain driving design is applied in the embodiments of the present application. The domain nouns under the same boundary context are encapsulated in the boundary of the plan sub-domain, and all the domain nouns irrelevant to the function of the sub-domain are excluded from the boundary context, so as to ensure the singleness of the sub-domain responsibility and the purity of the subsequent domain model. Finally, the domain model is established based on the plan sub-domain. The established domain model can be used as the input of the micro-service design. According to the code mapping relationship of the domain model, the target plan component is finally generated. Through the target plan component generated in the embodiments of the present application, the reuse ability of the system between the cross-channels can be improved, and the difficulty of development and operation is reduced. BRIEF DESCRIPTION OF DRAWINGS

[0016] Figure 1 is a flowchart of the component generation method based on domain driving provided by the embodiments of the present application;

[0017] Figure 2 is a flowchart of step S103 in Figure 1 ;

[0018] Figure 3 is a schematic diagram of the plan meta-model provided by the embodiments of the present application;

[0019] Figure 4 is a flowchart of step S104 in Figure 1 ;

[0020] Figure 5 is an event map schematic diagram of the activity volume interview plan provided by the embodiments of the present application;

[0021] Figure 6 is a flowchart of step S105 in Figure 1the flowchart of step S105 in

[0022] Figure 7 is Figure 1 the flowchart of step S105 in

[0023] Figure 8 is a schematic diagram of each sub-domain provided in the embodiments of the present application;

[0024] Figure 9 is Figure 1 the flowchart of step S102 in

[0025] Figure 10 is Figure 1 the flowchart of step S106 in

[0026] Figure 11 is a functional module schematic diagram of the domain modeling system provided in the embodiments of the present application;

[0027] Figure 12 is a hardware structure schematic diagram of the electronic device provided in the embodiments of the present application. DETAILED DESCRIPTION

[0028] In order to make the objects, technical solutions and advantages of the present application clearer, the present application is further described in detail below in combination with the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application, and are not used to limit the present application.

[0029] It should be noted that although the functional modules are divided in the device schematic diagram, and the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a manner different from the module division in the device or the order in the flowchart. The terms "first", "second", etc. in the specification and claims and the above drawings are used to distinguish similar objects, and do not necessarily describe a specific order or sequence.

[0030] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present application belongs. The terms used herein are only for the purpose of describing the embodiments of the present application, and are not intended to limit the present application.

[0031] First, the terms involved in the present application are analyzed:

[0032] Artificial intelligence (AI): is a new technical science of studying, developing theories, methods, technologies and application systems for simulating, extending and expanding human intelligence; artificial intelligence is a branch of computer science, artificial intelligence attempts to understand the essence of intelligence and produce a new intelligent machine that can react in a similar way to human intelligence. The research in this field includes robots, language recognition, image recognition, natural language processing and expert systems. Artificial intelligence can simulate the information process of human consciousness and thinking. Artificial intelligence is also the theory, method, technology and application system of using digital computer or digital computer controlled machine to simulate, extend and expand human intelligence, perceive environment, acquire knowledge and use knowledge to obtain the best results.

[0033] Domain Driven Design (DDD) is a model-driven software design method. It takes the domain as the core, analyzes the problems in the domain, and effectively solves the core complex problems in the domain by establishing a domain model. Only through continuous deep understanding of the domain can a domain model that solves the core problems of the domain be obtained. If the complexity of an application is not in the technology but in the domain itself, that is, the business in the domain is complex, the value of using domain driven design for such an application is greater.

[0034] Planning is the process and conclusion of analyzing and calculating how to achieve goals in the future specified period and decomposing goals into sub-goals. Plans can be broken down or combined, processes and results can be tracked, and plan components include purpose, quantifiable goals, time frame, plan maker, executor, execution steps, budget and contingency measures.

[0035] The middle platform is a unified omnichannel platform, also known as the channel middle platform, which is widely used in the financial industry and insurance industry. The middle platform is a "big backstage", in which all business functions can be integrated, and all data can be used in one or a set of databases to connect various businesses, solve the problem of data silos, improve performance, reduce interaction between different systems, interface conversion, and the transaction consistency of data interaction between different systems. The expensive development, network latency and overhead, and unnecessary development workload.

[0036] And each field of the channel middle platform will have plans, and the plan management process will be interspersed in multiple fields, for example, in the insurance industry, the business will intersperse the plan management process in the process of increasing staff, training, business development, activities, and performance.

[0037] However, the applicant discovered that the project management functionality existed within different systems across various domains. The same functional modules often required redesign and development, and were constrained by business domain limitations. The lack of a unified architecture, coupled with siloed development, resulted in redundant construction, inflexible adaptation to business changes, and an inability to quickly support business model innovation or achieve cross-channel system reuse. Adopting a microservices development model, on the other hand, could lead to unclear boundaries between business functions or applications, resulting in excessive microservice decomposition or overly complex projects, creating difficulties for deployment and maintenance.

[0038] Therefore, existing technologies often fail to adapt to changes in business conditions when building planning centers within different systems. The development process is complex, and cross-channel system reuse is not possible, which increases the difficulty of development and maintenance.

[0039] Based on this, embodiments of this application provide a domain-driven component generation method, system, device, and storage medium. The component generation method can be applied to a domain-driven component generation system. By executing the component generation method, the reusability of the system across channels can be improved, and the difficulty of development and maintenance can be reduced.

[0040] The domain-driven component generation method, system, device, and storage medium provided in this application are specifically described through the following embodiments. First, the domain-driven component generation method in this application is described.

[0041] The domain-driven component generation method in this application can be illustrated through the following embodiments.

[0042] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence (AI) refers to the theories, methods, technologies, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0043] Foundational technologies for artificial intelligence generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interactive systems, and mechatronics. AI software technologies mainly encompass computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning.

[0044] The domain-driven component generation method provided in this application relates to the field of artificial intelligence technology. This method can be applied to terminals, servers, or software running on either a terminal or server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, etc.; the server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms; the software can be an application implementing the domain-driven component generation method, but is not limited to the above forms.

[0045] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0046] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. For example, when obtaining user-stored data and user cached data access requests, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards. In addition, when embodiments of this application need to obtain sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirection to a confirmation page. Only after obtaining the user's separate permission or consent is the necessary user-related data for the normal operation of embodiments of this application obtained.

[0047] Figure 1This is an optional flowchart of the domain-driven component generation method provided in the embodiments of this application. Figure 1 The method may include, but is not limited to, steps S101 to S106.

[0048] Step S101: Obtain business process information and plan definition information;

[0049] For example, the domain-driven component generation method (hereinafter referred to as the component generation method or method) in this application embodiment can be applied in a domain-driven component generation system (hereinafter referred to as the component generation system or system). In the process of executing the component generation method, business process information and plan definition information can be obtained first. The business process information includes specific information of several business processes, such as business processes such as recruitment, training, business development, activities and performance. The plan definition information is the definition of the plan in the process. The plan definition information can help define the plan in the business process.

[0050] Step S102: Divide the domains according to the business process information to obtain multiple subdomains, and determine the planning subdomains among the multiple subdomains;

[0051] In this embodiment, the domain is first divided based on business process information to obtain multiple subdomains. These subdomains can be further categorized into three types based on their importance and functional attributes: core domains, general domains, and support domains. Specifically, the core domain is the subdomain that determines the product and core competitiveness; the general domain is the subdomain that provides common functions used by multiple subdomains; and the support domain is essential, containing neither the functions that determine the product and core competitiveness nor the general functions. This embodiment obtains multiple subdomains, distinguishes their different functional attributes and importance through domain division, and designates one of these subdomains as the planning subdomain. Optionally, any subdomain can be used as the planning subdomain in this embodiment; furthermore, the general domain is used as the planning subdomain.

[0052] Step S103: Identify the business process information in the plan subdomain based on the plan definition information to obtain multiple business information texts of the business process;

[0053] Subsequently, in this embodiment, business process information within the plan subdomain can be identified based on the plan definition information to obtain multiple business information texts for the business process. The plan definition information can be derived from the channel platform methodology corresponding to the plan, which can improve the identification of plan-related information in the business process. In this embodiment, the event storming process of domain-driven design, combined with the platform design methodology, can be used to subdivide the business process or business process segment within the plan subdomain, thereby obtaining the business text information for the entire process. The business text information can represent the specific processes or objects in the business process and can be used to describe the business process. It should be noted that in this embodiment, during the event storming process, the system can obtain user input information to obtain business process information and plan definition information, and perform domain division and information identification through processor calculations.

[0054] Step S104: Extract domain nouns for the planning subdomain from each business information text.

[0055] For example, embodiments of this application can extract domain terms for the planning subdomain from various business information texts. In these embodiments, the domain terms are domain objects in Domain-Driven Design (DDD), or in other words, the domain terms correspond to domain objects in DDD. Domain objects can be described using terms in a preset language, such as "product" or "order," corresponding to entity objects. These domain objects correspond to business objects in the domain model. Each business object and domain object has common terminology, and they are mapped one-to-one. Verbs in the preset language represent an action or event, such as "product ordered" or "order paid," corresponding to domain events or commands. In these embodiments, by extracting domain terms from the planning subdomain, the business responsibilities of the planning subdomain are comprehensively considered.

[0056] Step S105 encapsulates domain names within the same boundary context within the boundary of the plan subdomain;

[0057] For example, in this embodiment of the application, the business responsibilities of the implementation plan subdomain are comprehensively considered. It is necessary to determine the plan subdomain, or the responsibility boundary among multiple subdomains. In this embodiment of the application, all domain terms related to the implementation of the plan subdomain are placed in the same boundary context and encapsulated within the boundary of the plan subdomain, while all domain terms unrelated to the function of the plan subdomain are placed outside the context boundary of the plan subdomain.

[0058] It should be noted that in this application's embodiments, domain objects are described using domain nouns. Nouns, or languages, all have their semantic context. To avoid ambiguity in different contexts for the same concept or semantics, Domain-Driven Design (DDD) proposes the concept of Bounded Context in its strategic design to determine the domain boundary where the semantics reside. Bounded Context can be broken down into two words: Bounded and Context. The Bounded Context is the boundary of the domain, while the Context is the semantic environment. Through the Bounded Context of a domain, communication can be conducted using a unified language within a unified domain boundary. This boundary may become the final boundary of the microservice design.

[0059] Step S106: Based on the encapsulated plan subdomain, perform domain modeling to obtain the domain model, and generate the target plan component according to the code mapping relationship of the domain model.

[0060] For example, in this application embodiment, domain modeling can be performed based on the encapsulated plan subdomain to obtain a domain model. The domain model is a domain-driven model, and the established domain model can realize the implementation of microservices. Therefore, the system in this application embodiment can generate target plan components according to the code mapping relationship of the domain model. The target plan component can be a code model, or a collection of multiple code files to realize code implementation, or a collection of multiple software. Through the target plan component, a plan center can be established. The established plan center can be a platform. In this application embodiment, the plan center is a channel middle platform used for plan management.

[0061] It should be noted that the component generation method in this application embodiment can identify business process information through plan definition information. After dividing the plan subdomains according to the business process information, it identifies multiple business information texts in the plan subdomains and extracts the domain names of the plan subdomains. In order to further limit the boundaries, this application embodiment applies the definition of boundary context in domain-driven design, encapsulates the domain names under the same boundary context in the boundary of the plan subdomain, and excludes all domain names that are unrelated to the function of the subdomain from the boundary context, ensuring the single responsibility of the subdomain and the purity of the subsequent domain model. Finally, a domain model is established based on the plan subdomain. The established domain model can be used as input for microservice design. The target plan component is finally generated according to the code mapping relationship of the domain model. The target plan component generated in this application embodiment can improve the reusability of the system across channels and reduce the difficulty of development and operation and maintenance.

[0062] Please see Figure 2 In some embodiments, step S103 may include, but is not limited to, steps S201 to S203:

[0063] Step S201: Obtain a preset planning meta-model, wherein the planning meta-model is established based on the compositional relationship between sample functional modules in the sample business process;

[0064] Step S202: Identify the functional modules related to the plan from the plan meta-model based on the plan definition information;

[0065] Step S203: Map the functional modules to business process information, and identify multiple business information texts of the business process based on the mapping results.

[0066] For example, in the process of subdividing business processes within a plan subdomain, the business can be decomposed based on a pre-defined plan meta-model. Specifically, in this embodiment, a plan meta-model is pre-set. A plan meta-model is a type of metamodel that defines the specifications of a model; specifically, it defines the elements that make up the model and the relationships between those elements. In this embodiment, the plan meta-model defines the relationships between the various elements within the plan. The plan meta-model is established based on the compositional relationships between sample functional modules in the business process template.

[0067] The planning metamodel can be pre-built in the system based on the business processes input by the user, for example, referring to... Figure 3 As shown, in the business process sample provided in this application embodiment, the corresponding business domain is composed of multiple sample functional modules. It can be understood that the system can obtain user input information to obtain the sample business process and sample functional modules. The sample functional modules are the processes within the corresponding business. Figure 3 The meta-model of the business process defined in this embodiment includes multiple concepts to describe functional modules, such as constraints, objectives, subjects, relationships, and objects. Constraints can have several templates; the business process can be decomposed to obtain objectives, sub-objectives, etc., and further, sub-objectives can have leaf objectives, which can be composed of multiple objective values; subjects can be composed of planning subjects; relationships can be divided into various relationships such as planning, monitoring, and intervention, representing the relationships between various business processes during the planning management process; plans can be obtained based on the corresponding relationships between objects, and plans include activities and risks. Activities are associated with leaf objectives, and risks are associated with templates under several constraints.

[0068] Based on the five main concepts of the above meta-model (including constraints, objectives, subjects, relationships, and objects) to characterize functional modules, and based on the business processes related to plan management in the core domain of the channel platform connected to the planning center, a meta-model for plan formulation, execution, monitoring, and intervention can be formed.

[0069] For example, in this embodiment, common functional modules related to the plan are identified from the plan meta-model based on the plan definition information, including plan formulation, plan issuance, plan tracking, and monitoring and early warning. The functional modules and business processes are mapped one by one, and the business processes are disassembled from a comprehensive perspective. The functional modules of the product design are examined to see if they conform to the concepts in the plan meta-model and cover the entire business process. Based on the mapping results, the various business information of the business process is identified. Through the setting of the plan meta-model, the basic common language in the plan is defined, which can be used to describe the problems and solutions in the plan. This embodiment can provide a flexibly configurable and rapidly responsive middle platform support to improve the efficiency of domain modeling.

[0070] For example, business information text includes event information, command information, member information, and input information. Event information represents events in the entire process, command information represents commands in the entire process, member information mainly represents the main entity status in the planning management process, and input information mainly represents the reading model in the planning process.

[0071] Please see Figure 4 In some embodiments, step S104 may include, but is not limited to, steps S301 to S302:

[0072] Step S301: Establish an event map based on the relationships between event information, command information, member information, and input information;

[0073] Step S302: Extract the domain names of the planned subdomain from the event map.

[0074] For example, in this embodiment of the application, according to the plan definition information and business process information, through the event storming process of domain-driven design and combined with the design methodology of the channel middle platform, the business processes in the plan subdomain can be subdivided, thereby identifying the events, commands, members (subjects), and inputs (reading models) in the entire process, describing the business meaning and rules simply, clearly, and accurately, and forming an event map. In this embodiment of the application, by forming an event map, visualization operation can be realized, so that users can quickly understand the business domain and extract the domain terms of the plan subdomain from the event map to complete the scenario analysis.

[0075] For example, please see Figure 5 This is an event map provided in one embodiment. Figure 5The event map for the activity-based face-to-face visit plan includes the following: boxes containing "System" and "Agent" represent member information; boxes with blank content and "Personal Contact List, System Push List" represent input information; boxes containing "Issuing Monthly Face-to-Face Visit Target Values," "Selecting Potential Customers," "Creating Face-to-Face Visit Plans," "Generating Face-to-Face Visit QR Codes," and "Recording Face-to-Face Visit Counts" represent command information; and boxes containing "Monthly Face-to-Face Visit Target Values ​​Issued," "Potential Customers Selected," "Face-to-Face Visit Plans Created," "Face-to-Face Visit QR Codes Generated," "Face-to-Face Visit Counts Recorded," and "Face-to-Face Visits Failed" represent event information. These event, command, member, and input information represent the flow within a plan. In the event map, the previous plan management process will flow to the next process, hence the name "map."

[0076] Please see Figure 6 In some embodiments, step S105 may include, but is not limited to, steps S401 to S402:

[0077] Step S401: Extract common domain terms from domain terms;

[0078] Step S402 encapsulates the generic domain terms under the same boundary context within the boundary of the planned subdomain.

[0079] For example, in this embodiment of the application, all common domain terms in the planning subdomain can be extracted from the event map, uniformly named, and formed into common business terms for the project team. Common domain terms are obtained. Then, the responsibility boundaries of the planning subdomain are determined by comprehensively considering the business responsibilities of implementing the planning subdomain. All common domain terms related to implementing the functions of the planning subdomain are placed within the same bounded context boundary, while all domain terms unrelated to the functions of the planning subdomain are excluded from the context boundary.

[0080] It's important to note that generic domain terminology is a domain terminology described by a common language. This common language is a set of agreed-upon specifications and rules. During event storming, the language that can simply, clearly, and accurately describe business meanings and rules is the generic language. The generic language includes terminology and use case scenarios and can be directly reflected in the code. Nouns in the generic language can name domain objects, such as "product" or "order," corresponding to entity objects; while verbs represent an action or event, such as "product ordered" or "order paid," corresponding to domain events or commands.

[0081] Please see Figure 7 In some embodiments, step S105 may include, but is not limited to, steps S501 to S502:

[0082] Step S501: Determine the boundary context based on the plan definition information;

[0083] Step S502: Based on the boundary context, encapsulate the domain terms related to the functions of the planning subdomain within the boundary of the planning subdomain.

[0084] For example, the boundary context can be determined based on the plan definition information. The plan definition information describes what a plan is; therefore, the boundary of the plan subdomain can be further described through the plan definition information, thus obtaining the boundary context. In this embodiment, since domain terms also have their contextual environment, to avoid ambiguity of the same concept or semantics in different contextual environments, the concept of bounded context is proposed in domain-driven design to determine the domain boundary where the semantics reside. In this embodiment, the boundary context is used to encapsulate the common language and domain objects, providing a contextual environment to ensure that some terms and business-related objects within the domain have a precise meaning. Therefore, this boundary defines the scope of application of the domain model and clarifies the content of the plan center in the domain model.

[0085] Reference Figure 8 The diagram shown illustrates the various subdomains provided in this embodiment. By defining the boundaries of the boundary context, domain terms related to the functions of the planning subdomain can be encapsulated within the boundaries of the planning subdomain. The planning subdomain corresponds to... Figure 8 The planning management context (general domain) in the system.

[0086] It should be noted that the bounded context in this application embodiment is a mandatory boundary, which can guarantee the single responsibility of the subdomain and the purity of the subsequent domain model. In other words, the bounded context determines the boundaries of microservice decomposition and design, laying the foundation for domain modeling.

[0087] Please see Figure 9 In some embodiments, step S102 may include, but is not limited to, steps S601 to S602:

[0088] Step S601: Divide the domains according to the business process information to obtain multiple subdomains;

[0089] Step S602: Determine the functional attributes in each subdomain, and determine the subdomain with the functional attribute of general domain function as the planning subdomain.

[0090] For example, such as Figure 8 As shown, in this embodiment of the application, multiple subdomains can be obtained through domain division. Finally, domain terms can be encapsulated in the corresponding subdomains based on the boundary context. Specifically, in this embodiment of the application, a core domain, a general domain, and a supporting domain can be obtained. The core domain may include... Figure 8The subdomains corresponding to the recruitment plan management context, training management context, and performance management context obtained from the division are defined. The general domain is the subdomain corresponding to the plan management context. In this embodiment, the plan subdomain is the general domain, which is the subdomain corresponding to the plan management context. Figure 8 The subdomains corresponding to the face-to-face management context, approval management context, financial management context, and performance management context are the supporting domains.

[0091] It should be noted that, Figure 8 The subdomain corresponding to the planning management context includes the domain name of face-to-face interview plan, which includes the activity volume face-to-face interview plan in the above embodiment.

[0092] Therefore, the target plan component finally generated in this application embodiment can generate a general domain plan center in domain-driven design.

[0093] Please see Figure 10 In some embodiments, step S106 may include, but is not limited to, steps S701 to S702:

[0094] Step S701: Obtain multiple code objects by mapping each domain term in the domain model;

[0095] Step S702: Generate a target plan component based on multiple code objects.

[0096] For example, in this embodiment of the application, code implementation can be achieved. Specifically, in this embodiment of the application, multiple code objects can be obtained based on the code mapping relationship, according to each domain term in the domain model. A target plan component is generated based on the multiple code objects. The target plan component can be a code model, or it can be a component generated based on the code model generated from the code objects. When designing the code model, domain objects should be established, that is, a one-to-one mapping between domain terms and code objects, so as to ensure the consistency between the domain model and the code model and achieve the unification of business language and code language.

[0097] It is understood that the domain model of the common language established in this application embodiment will serve as the input for microservice design, and the code model of the microservice will be derived from the domain model. The code objects of the code model will be mapped one-to-one with the domain terms in the domain model. Only by unifying the common language and correctly transmitting and mapping it throughout the entire application construction process can the consistency between business requirements and system implementation be ensured.

[0098] It should be noted that in this embodiment of the application, a target plan component is generated by executing the component generation method and using the domain-driven design methodology. A plan center can be built based on the target plan component. In this embodiment of the application, the business domain is subdivided according to certain rules, the problems to be solved are limited to specific boundaries, fine-grained analysis is performed on the plan subdomains, shared capabilities in the plan business process are identified, and these shared capabilities are precipitated into general capabilities.

[0099] For example, the planning center ultimately obtained through the method in this application embodiment has achieved a service reuse rate of 28.13%, achieving the goal of cost reduction and efficiency improvement. On the other hand, by accumulating and refining business and IT knowledge, it facilitates mutual understanding between business and IT personnel, better knowledge transfer, and improved work cooperation and system satisfaction. It provides three-layer reuse capabilities across entities, domains, and channels for all channels, achieving a middle platform effect of "one-time development, multiple benefits".

[0100] Please see Figure 11 This application also provides a domain-driven component generation system that can implement the above-described domain-driven component generation method. The component generation system includes:

[0101] Data acquisition module 1101 is used to acquire business process information and plan definition information;

[0102] Domain segmentation module 1102 is used to segment domains based on business process information and determine the planning subdomain among multiple subdomains;

[0103] The information recognition module 1103 is used to recognize the business process information in the plan subdomain according to the plan definition information, and obtain multiple business information texts of the business process.

[0104] The domain noun extraction module 1104 is used to extract domain nouns of the planning subdomain from various business information texts;

[0105] Encapsulation module 1105 is used to encapsulate domain names under the same boundary context within the boundary of the plan subdomain;

[0106] The component generation module 1106 is used to obtain a domain model by performing domain modeling based on the encapsulated plan subdomain, and to generate the target plan component according to the code mapping relationship of the domain model.

[0107] For example, in the component generation system of this application embodiment, during the execution of the component generation method, business process information and plan definition information can be obtained first. The business process information includes specific information of several business processes, such as business processes such as recruitment, training, business development, activities and performance. The plan definition information is the definition of the plan in the process. The plan definition information can help define the plan in the business process.

[0108] In this embodiment, the domain is first divided based on business process information to obtain multiple subdomains. These subdomains can be further categorized into three types based on their importance and functional attributes: core domains, general domains, and support domains. Specifically, the core domain is the subdomain that determines the product and core competitiveness; the general domain is the subdomain that provides common functions used by multiple subdomains; and the support domain is essential, containing neither the functions that determine the product and core competitiveness nor the general functions. This embodiment obtains multiple subdomains, distinguishes their different functional attributes and importance through domain division, and designates one of these subdomains as the planning subdomain. Optionally, any subdomain can be used as the planning subdomain in this embodiment; furthermore, the general domain is used as the planning subdomain.

[0109] Subsequently, in this embodiment, business process information within the plan subdomain can be identified based on the plan definition information to obtain multiple business information texts for the business process. The plan definition information can be derived from the channel platform methodology corresponding to the plan, which can improve the identification of plan-related information in the business process. In this embodiment, the event storming process of domain-driven design, combined with the platform design methodology, can be used to subdivide the business process or business process segment within the plan subdomain, thereby obtaining the business text information for the entire process. The business text information can represent the specific processes or objects in the business process and can be used to describe the business process. It should be noted that in this embodiment, during the event storming process, the system can obtain user input information to obtain business process information and plan definition information, and perform domain division and information identification through processor calculations.

[0110] For example, embodiments of this application can extract domain terms for the planning subdomain from various business information texts. In these embodiments, the domain terms are domain objects in Domain-Driven Design (DDD), or in other words, the domain terms correspond to domain objects in DDD. Domain objects can be described using terms in a preset language, such as "product" or "order," corresponding to entity objects. These domain objects correspond to business objects in the domain model. Each business object and domain object has common terminology, and they are mapped one-to-one. Verbs in the preset language represent an action or event, such as "product ordered" or "order paid," corresponding to domain events or commands. In these embodiments, by extracting domain terms from the planning subdomain, the business responsibilities of the planning subdomain are comprehensively considered.

[0111] For example, in this embodiment of the application, the business responsibilities of the implementation plan subdomain are comprehensively considered. It is necessary to determine the plan subdomain, or the responsibility boundary among multiple subdomains. In this embodiment of the application, all domain terms related to the implementation of the plan subdomain are placed in the same boundary context and encapsulated within the boundary of the plan subdomain, while all domain terms unrelated to the function of the plan subdomain are placed outside the context boundary of the plan subdomain.

[0112] It should be noted that in this application's embodiments, domain objects are described using domain nouns. Nouns, or languages, all have their semantic context. To avoid ambiguity in different contexts for the same concept or semantics, Domain-Driven Design (DDD) proposes the concept of Bounded Context in its strategic design to determine the domain boundary where the semantics reside. Bounded Context can be broken down into two words: Bounded and Context. The Bounded Context is the boundary of the domain, while the Context is the semantic environment. Through the Bounded Context of a domain, communication can be conducted using a unified language within a unified domain boundary. This boundary may become the final boundary of the microservice design.

[0113] For example, in this application embodiment, domain modeling can be performed based on the encapsulated plan subdomain to obtain a domain model. The domain model is a domain-driven model, and the established domain model can realize the implementation of microservices. Therefore, the system in this application embodiment can generate target plan components according to the code mapping relationship of the domain model. The target plan component can be a code model, or a collection of multiple code files to realize code implementation, or a collection of multiple software. Through the target plan component, a plan center can be established. The established plan center can be a platform. In this application embodiment, the plan center is a channel middle platform used for plan management.

[0114] It should be noted that the component generation system of this application embodiment can identify business process information through plan definition information when executing the component generation method. After dividing the plan subdomains according to the business process information, it identifies multiple business information texts in the plan subdomains and extracts the domain names of the plan subdomains. In order to further limit the boundaries, this application embodiment applies the definition of boundary context in domain-driven design, encapsulates the domain names under the same boundary context in the boundary of the plan subdomain, and excludes all domain names that are unrelated to the function of the subdomain from the boundary context, ensuring the single responsibility of the subdomain and the purity of the subsequent domain model. Finally, a domain model is established based on the plan subdomain. The established domain model can be used as input for microservice design. The target plan component is finally generated according to the code mapping relationship of the domain model. The target plan component generated in this application embodiment can improve the reusability of the system across channels and reduce the difficulty of development and operation and maintenance.

[0115] The specific implementation of this domain modeling system is basically the same as the specific embodiment of the domain-driven component generation method described above, and will not be repeated here. Subject to meeting the requirements of the embodiments of this application, the domain modeling system may also be equipped with other functional modules to implement the domain-driven component generation method described above.

[0116] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aforementioned domain-driven component generation method or cache retrieval method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0117] Please see Figure 12 , Figure 12 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes:

[0118] The processor 1201 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0119] The memory 1202 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 1202 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1202 and is called and executed by the processor 1201 using the domain-driven component generation method of the embodiments of this application.

[0120] The input / output interface 1203 is used to implement information input and output;

[0121] The communication interface 1204 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0122] Bus 1205 transmits information between various components of the device (e.g., processor 1201, memory 1202, input / output interface 1203, and communication interface 1204);

[0123] The processor 1201, memory 1202, input / output interface 1203 and communication interface 1204 are connected to each other within the device via bus 1205.

[0124] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described domain-driven component generation method.

[0125] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0126] The domain-driven component generation method, system, device, and storage medium provided in this application embodiment can identify business process information through plan definition information. After dividing the plan subdomains according to the business process information, it identifies multiple business information texts in the plan subdomains and extracts the domain names of the plan subdomains. To further limit the boundaries, this application embodiment applies the definition of boundary context in domain-driven design, encapsulating domain names under the same boundary context within the boundary of the plan subdomain, while excluding all domain names unrelated to the function of the subdomain from the boundary context, ensuring the single responsibility of the subdomain and the purity of the subsequent domain model. Finally, a domain model is established based on the plan subdomain. The established domain model can be used as input for microservice design. The target plan component is finally generated according to the code mapping relationship of the domain model. The target plan component generated in this application embodiment can improve the reusability of the system across channels and reduce the difficulty of development and operation and maintenance.

[0127] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0128] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0129] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0130] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0131] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0132] It should be understood that in this application, "at least one (item)" means one or more, and "more than one" means two or more. "And / or" is used to describe the association of related objects, indicating that three relationships can exist. For example, "A and / or B" can represent: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0133] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0134] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0135] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0136] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0137] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A domain-driven component generation method, characterized in that, The method includes: Obtain business process information and plan definition information; Based on the business process information, the domain is divided into multiple subdomains, and a planning subdomain is determined among the multiple subdomains; Based on the plan definition information, the business process information in the plan subdomain is identified to obtain multiple business information texts of the business process; Extract the domain nouns of the plan subdomain from each of the aforementioned business information texts; The domain nouns that are in the same bounded context will be encapsulated within the boundaries of the planned subdomain; Based on the encapsulated plan subdomain, a domain model is obtained by performing domain modeling, and a target plan component is generated according to the code mapping relationship of the domain model. The step of identifying the business process information in the plan subdomain based on the plan definition information to obtain multiple business information texts of the business process includes: Obtain a preset plan meta-model, wherein the plan meta-model is established based on the compositional relationship between sample functional modules in the sample business process; Based on the plan definition information, identify the plan-related functional modules from the plan metamodel; The functional modules are mapped to the business process information, and multiple business information texts of the business process are identified based on the mapping results. The business information text includes event information, command information, member information, and input information. Extracting domain nouns for the plan subdomain from each of the business information texts includes: An event map is established based on the relationships between the event information, the command information, the member information, and the input information; Extract the domain names of the planned subdomain from the event map.

2. The domain-driven component generation method according to claim 1, characterized in that, The domain nouns that will be encapsulated within the boundaries of the planned subdomain under the same boundary context include: Extract common, generic domain terms from the domain terms; The general domain nouns that are in the same bounded context will be encapsulated within the boundaries of the planned subdomain.

3. The domain-driven component generation method according to claim 1, characterized in that, The domain nouns that will be encapsulated within the boundaries of the planned subdomain under the same boundary context include: Determine the boundary context based on the plan definition information; Based on the boundary context, the domain terms related to the functions of the planned subdomain are encapsulated within the boundaries of the planned subdomain.

4. The domain-driven component generation method according to claim 1, characterized in that, The step of dividing the domain based on the business process information to obtain multiple subdomains, and determining the planning subdomain among the multiple subdomains, includes: Based on the business process information, the domain is divided to obtain multiple subdomains; Determine the functional attributes in each of the subdomains, and identify the subdomains whose functional attributes are general domain functions as planning subdomains.

5. The domain-driven component generation method according to claim 1, characterized in that, The step of generating the target plan component based on the code mapping relationship of the domain model includes: Multiple code objects are obtained by mapping each domain term in the domain model; Generate a target plan component based on multiple code objects.

6. A domain-driven component generation system, characterized in that, The system includes: The data acquisition module is used to acquire business process information and plan definition information; The domain segmentation module is used to segment the domains according to the business process information to obtain multiple subdomains, and to determine the planning subdomain among the multiple subdomains; The information recognition module is used to recognize the business process information in the plan subdomain according to the plan definition information, and obtain multiple business information texts of the business process; The domain noun extraction module is used to extract domain nouns of the plan subdomain from each of the business information texts; An encapsulation module is used to encapsulate the domain nouns within the same bounded context within the boundaries of the planned subdomain; The component generation module is used to perform domain modeling based on the encapsulated plan subdomain to obtain a domain model, and generate target plan components according to the code mapping relationship of the domain model. The information recognition module is used to recognize the business process information in the plan subdomain according to the plan definition information, and obtain multiple business information texts of the business process, including: Obtain a preset plan meta-model, wherein the plan meta-model is established based on the compositional relationship between sample functional modules in the sample business process; Based on the plan definition information, identify the plan-related functional modules from the plan metamodel; The functional modules are mapped to the business process information, and multiple business information texts of the business process are identified based on the mapping results. The business information text includes event information, command information, member information, and input information. The domain terminology extraction module is used to extract domain terms for the plan subdomain from each of the business information texts, including: An event map is established based on the relationships between the event information, the command information, the member information, and the input information; Extract the domain names of the planned subdomain from the event map.

7. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the domain-driven component generation method according to any one of claims 1 to 5.

8. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the domain-driven component generation method according to any one of claims 1 to 5.

Images