Insurance middle platform construction method and device, equipment and medium

Abstract

The embodiment of the application provides an insurance middle platform construction method, device, equipment and medium, which is applied to the insurance system construction field, the domain and the sub-domain are obtained by dividing the insurance middle platform in architecture and business according to insurance business process information, and the bounded context of the sub-domain is determined according to the domain vocabulary; the domain modeling is carried out based on the sub-domain and the bounded context to obtain a domain model; a code model is constructed according to the domain model; the insurance middle platform is constructed according to the domain model and the code model; the reasonable allocation of the domain and the sub-domain is realized, the reasonable splitting of the business is realized, the boundary is described through the bounded context, the business boundary is clear, and then the insurance middle platform is simplified, the efficiency of the insurance middle platform is improved, and the multi-layer reuse capability of the insurance middle platform is provided.

Description

Technical Field

[0001] This application relates to the field of data processing, and in particular to methods, apparatus, equipment and media for constructing insurance middleware platforms. Background Technology

[0002] Current insurance systems are built upon complex insurance business processes, resulting in numerous front-end applications. Each application is a centralized monolithic application designed to handle a large amount of business logic. The insurance system employs a traditional siloed architecture, lacking any shared or consolidated capabilities. Excessive microservice decomposition leads to unclear business boundaries between applications. This results in an overly bloated and complex insurance system that is difficult to use and maintain. Summary of the Invention

[0003] The purpose of this application is to at least partially solve one of the technical problems existing in the related art.

[0004] Therefore, one objective of the embodiments of this application is to provide an insurance middleware construction method, apparatus, equipment and medium that can provide multi-layered reuse capabilities across entities, domains and channels.

[0005] To achieve the above objectives, a first aspect of this application provides a method for constructing an insurance middleware platform, characterized by comprising:

[0006] Obtain information on insurance business segments, business processes, and events in the insurance sector;

[0007] The architecture is divided into multiple domains based on the aforementioned business segment information;

[0008] The domain is divided into subdomains based on the business process information.

[0009] Extract domain terms from the insurance domain events, and determine the bounded context of the subdomain based on the domain terms;

[0010] A domain model is obtained by performing domain modeling based on the subdomain and the bounded context;

[0011] Construct a code model based on the domain model;

[0012] An insurance platform is constructed based on the domain model and the code model.

[0013] In some embodiments, extracting domain vocabulary from the insurance domain events and determining the bounded context of the subdomain based on the domain vocabulary includes:

[0014] Extract domain-specific vocabulary from the aforementioned insurance-related events;

[0015] Determine the correlation between the domain vocabulary and the functions of the subdomains;

[0016] Based on the correlation, the domain vocabulary is categorized to obtain the bounded context of the function corresponding to the subdomain.

[0017] In some embodiments, the process of performing domain modeling based on the subdomain and the bounded context to obtain a domain model includes:

[0018] Based on the subdomain, the insurance business entity and the insurance business value object are obtained;

[0019] Associate the corresponding insurance business entity with the corresponding insurance business value object;

[0020] Multiple sets of associated insurance business entities and insurance business value objects are aggregated to form aggregate information, and an aggregate root is determined based on the aggregate information;

[0021] Domain modeling is performed based on the aggregate root and the bounded context to obtain the domain model.

[0022] In some embodiments, the step of performing domain modeling based on the aggregate root and the bounded context to obtain a domain model includes:

[0023] Determine the target process information corresponding to the target business process from the aforementioned business process information;

[0024] A meta-model is obtained based on the target process information;

[0025] The meta-model is reconstructed based on the aggregate root and the bounded context to obtain the domain model corresponding to the target business process.

[0026] In some embodiments, the subdomain includes a core domain, a general domain, and a support domain; the core domain is used to provide core services, the general domain is used to provide general services for the core services, and the support domain is used to support the core services.

[0027] In some embodiments, the core domain includes a first subdomain corresponding to recruitment business, a second subdomain corresponding to training business, a third subdomain corresponding to production capacity business, a fourth subdomain corresponding to management business, and a fifth subdomain corresponding to performance business; the support domain includes a sixth subdomain corresponding to individual business.

[0028] After dividing the domain into subdomains based on the business process information, the insurance middle platform construction method further includes:

[0029] The first subdomain, the second subdomain, the third subdomain, the fourth subdomain, the fifth subdomain, and the sixth subdomain are integrated into the main process according to the agent lifecycle dimension;

[0030] The subdomains of the supporting domain other than the sixth subdomain and the subdomains of the general domain are used as auxiliary processes;

[0031] Determine the calling relationship between the main process and the auxiliary process;

[0032] The process of obtaining a domain model based on the subdomain and the bounded context includes:

[0033] A domain model is obtained by performing domain modeling based on the subdomain, the bounded context, and the calling relationship.

[0034] In some embodiments, the step of constructing the code model of the insurance middleware based on the domain model includes:

[0035] The domain vocabulary of the domain model is mapped one by one to the code objects of the code model, wherein the domain model is described based on a common domain language;

[0036] The code model is constructed based on the code object.

[0037] To achieve the above objectives, a second aspect of this application provides an insurance platform construction apparatus, comprising:

[0038] The information acquisition module is used to acquire information on business segments, business processes, and events in the insurance field.

[0039] The domain determination module is used to divide the architecture into multiple domains based on the business segment information;

[0040] The subdomain determination module is used to divide the domain into subdomains based on the business process information.

[0041] A context determination module is used to extract domain terms from the insurance domain events and determine the bounded context of the subdomain based on the domain terms;

[0042] A domain model construction module is used to perform domain modeling based on the subdomain and the bounded context to obtain a domain model;

[0043] A code model building module is used to build a code model based on the domain model.

[0044] The platform construction module is used to construct the insurance middleware based on the domain model and the code model.

[0045] To achieve the above objectives, a third aspect of this application provides an electronic device, which includes a memory, a processor, a program stored in the memory and executable on the processor, and a data bus for enabling communication between the processor and the memory. When the program is executed by the processor, it implements the insurance platform construction method described above.

[0046] To achieve the above objectives, a fourth aspect of the present application provides a computer-readable storage medium, characterized in that the computer-readable storage medium stores computer-executable instructions, which are used to cause a computer to execute the insurance platform construction method described above.

[0047] The insurance middle platform construction method, apparatus, equipment, and medium provided in the embodiments of this application acquire business segment information, business process information, and insurance domain events of insurance business; divide the business into multiple domains based on the business segment information; divide the domains into subdomains based on the business process information; extract domain vocabulary from the insurance domain events; determine the bounded context of the subdomain based on the domain vocabulary; perform domain modeling based on the subdomain and the bounded context to obtain a domain model; construct the code model of the insurance middle platform based on the domain model; construct the insurance middle platform based on the domain model and the code model; build a unified insurance channel platform, providing multi-layered reuse capabilities across entities, domains, and channels; achieve reasonable business decomposition through reasonable allocation of domains and subdomains; and describe the boundaries through bounded contexts, making the business boundaries clear, simplifying the insurance system, and improving the efficiency of the insurance system. Attached Figure Description

[0048] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the following description is provided with accompanying drawings of the relevant technical solutions in the embodiments of this application or the prior art. It should be understood that the accompanying drawings described below are only for the purpose of clearly illustrating some embodiments of the technical solutions of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0049] Figure 1 This is a flowchart illustrating the steps of the insurance platform construction method provided in the embodiments of this application;

[0050] Figure 2 This is a step diagram illustrating the steps involved in determining the call relationship;

[0051] Figure 3 This is a sub-step diagram of step S400;

[0052] Figure 4 This is a sub-step diagram of step S500;

[0053] Figure 5 This is a sub-step diagram of step S540;

[0054] Figure 6 This is a sub-step diagram of step S600;

[0055] Figure 7 This is a structural diagram of the insurance platform construction device provided in the embodiments of this application;

[0056] Figure 8 This is a structural diagram of the electronic device provided in the embodiments of this application. Detailed Implementation

[0057] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

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

[0059] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: 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.

[0060] In the description of this specification, the references to terms such as "one embodiment," "another embodiment," or "some embodiments," etc., indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

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

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

[0063] 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 this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0064] First, let's analyze some of the terms used in this application:

[0065] The embodiments of this application will be further described below with reference to the accompanying drawings.

[0066] The embodiments of this application provide a method, apparatus, device, and medium for constructing an insurance middle platform. This method involves: acquiring business segment information, business process information, and insurance domain events of insurance business; dividing the business into multiple domains based on the business segment information; further dividing the domains into subdomains based on the business process information; extracting domain vocabulary from insurance domain events and determining the bounded context of the subdomains based on the domain vocabulary; performing domain modeling based on the subdomains and bounded contexts to obtain a domain model; constructing a code model of the insurance middle platform based on the domain model; constructing the insurance middle platform based on the domain model and the code model; and building a unified insurance channel platform that provides multi-layered reuse capabilities across entities, domains, and channels. By rationally allocating domains and subdomains, it achieves reasonable business decomposition and describes the boundaries through bounded contexts, making business boundaries clear, simplifying the insurance system, and improving its efficiency.

[0067] The embodiments of this application will be further described below with reference to the accompanying drawings.

[0068] An embodiment of this application provides a method for constructing an insurance middleware platform.

[0069] Reference Figure 1 The method for building an insurance middle platform includes, but is not limited to, the following steps:

[0070] Step S100: Obtain business segment information, business process information, and insurance-related events for the insurance business;

[0071] Step S200: Divide the architecture into multiple domains based on the business segment information;

[0072] Step S300: Divide the domain into subdomains based on the business process information;

[0073] Step S400: Extract domain terms from insurance domain events, and determine the bounded context of subdomains based on the domain terms;

[0074] Step S500: Perform domain modeling based on subdomains and bounded contexts to obtain the domain model;

[0075] Step S600: Construct a code model based on the domain model;

[0076] Step S700: Construct the insurance middle platform based on the domain model and code model.

[0077] For step S100, obtain insurance business information, which includes at least business segment information, business process information, and insurance domain events. Business segment information is data related to insurance business segments, business process information is data related to insurance business processes, and insurance domain events are domain events of the insurance business.

[0078] In step S200, the architecture is divided into multiple domains based on the business segment information. It can be understood that a domain is a specific scope or area with defined business boundaries and scope; the domain is the business problem domain to be solved within those boundaries and scope. The larger the domain, the larger the business scope; the smaller the domain, the smaller the business scope.

[0079] For step S300, the domain is divided into subdomains based on the business process information.

[0080] The domain can be further divided into subdomains, each corresponding to a smaller problem domain or a smaller business scope. The core domain provides core business functions and determines the product and core competitiveness; the general domain provides general business functions for the core business, which can be used by multiple subdomains simultaneously; the support domain supports the core business. The support domain is a necessary functional subdomain, but it does not contain functions that determine the product and the company's core competitiveness, nor does it contain general functions.

[0081] Subdomains can be divided into three categories based on their importance and functional attributes: core domains, general domains, and support domains.

[0082] Specifically, the core domain includes the first subdomain corresponding to recruitment, the second subdomain corresponding to training, the third subdomain corresponding to production capacity, the fourth subdomain corresponding to management, and the fifth subdomain corresponding to performance. The third subdomain includes subdomains corresponding to production capacity-purchasing, production capacity-customer management, production capacity-planning management, production capacity-communication, production capacity-consulting, and production capacity-product management.

[0083] The supporting domains include the sixth subdomain corresponding to personal business, the seventh subdomain corresponding to business analysis platform, the eighth subdomain corresponding to strategy center, the ninth subdomain corresponding to intelligent RTC, and the tenth subdomain corresponding to evaluation system.

[0084] The general domain includes the eleventh subdomain corresponding to the planning center, the twelfth subdomain corresponding to the activity center, the thirteenth subdomain corresponding to the attendance center, the fourteenth subdomain corresponding to the practice center, the fifteenth subdomain corresponding to the task center, the sixteenth subdomain corresponding to the user center, the seventeenth subdomain corresponding to the permission center, the eighteenth subdomain corresponding to the clue center, and the nineteenth subdomain corresponding to the content center.

[0085] Reference Figure 2 The method for building an insurance middle platform also includes a step for determining call relationships, which is detailed below:

[0086] Step S301: Integrate the first subdomain, second subdomain, third subdomain, fourth subdomain, fifth subdomain and sixth subdomain into the main process according to the agent lifecycle dimension;

[0087] Step S302: Use the subdomains of the supporting domain other than the sixth subdomain and the subdomains of the general domain as auxiliary processes;

[0088] Step S303: Determine the calling relationship between the main process and the auxiliary process.

[0089] By calling each other between the main process and the auxiliary process, user and scenario analysis is completed, simplifying the problem and reducing the complexity of business understanding and system implementation.

[0090] Since the subsequent domain model is built on the basis of the subdomain, the domain model also has this calling relationship.

[0091] Reference Figure 3 For step S400, domain terms are extracted from insurance domain events, and the bounded context of subdomains is determined based on the domain terms, including but not limited to the following steps:

[0092] Step S410: Extract domain-specific vocabulary from insurance-related events;

[0093] Step S420: Determine the correlation between domain vocabulary and subdomain functions;

[0094] Step S430: Classify domain terms according to relevance to obtain the bounded context of functions of the corresponding subdomains.

[0095] Insurance domain events are domain-related events concerning insurance business. Domain events are used to achieve data consistency between various components. The ultimate recipient of a domain event can be a component within the current bounded context or another bounded context. An additional benefit of domain events is that they can record all significant modifications that occur within the software system, thus providing excellent support for program debugging and business intelligence.

[0096] By extracting domain terms from an event map formed from insurance domain events to describe the functions of subdomains, a mandatory boundary is defined for the functions of these subdomains. This ensures the singularity of function for each 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.

[0097] The relevance between domain terms and the functions of subdomains is determined, and domain terms related to the functions of the subdomain are grouped into the same bounded context to obtain the bounded context of the corresponding subdomain's functions. Specifically, when the relevance is greater than or equal to a preset relevance threshold, the domain term is grouped into the bounded context of the corresponding subdomain's functions; when the relevance is less than the preset relevance threshold, the domain term is excluded from the bounded context of the corresponding subdomain's functions.

[0098] Domain vocabulary is described by a domain-specific language, which determines the definition of bounded contexts, and thus the domain model is described based on the domain-specific language.

[0099] Models represent the commonalities within a software domain, making them suitable as the foundation for constructing such a universal language, and serving as the core framework of the language. Describing domain models using a domain-wide universal language enables seamless communication and gives the models broad applicability.

[0100] Reference Figure 4 For step S500, domain modeling is performed based on subdomains and bounded contexts to obtain a domain model, including but not limited to the following steps:

[0101] Step S510: Obtain the insurance business entity and insurance business value object based on the subdomain;

[0102] Step S520: Associate the corresponding insurance business entity and insurance business value object;

[0103] Step S530: Aggregate multiple sets of associated insurance business entities and insurance business value objects to form aggregate information, and determine the aggregate root based on the aggregate information;

[0104] Step S540: Perform domain modeling based on the aggregate root and bounded context to obtain the domain model.

[0105] In step S510, insurance business entities and insurance business value objects are obtained based on the subdomain. The insurance business entity is a domain concept within the insurance business domain that requires unique identification. By setting a unique identifier for the insurance business entity, unique identity authentication can be achieved. The entity is persisted to the database after creation and retrieved only when needed. Entities should not be given too many attributes or behaviors; instead, relationships should be sought to discover other entities or value objects, and attributes or behaviors should be transferred to these related entities or value objects. Furthermore, since not every object in the domain needs a unique identifier—that is, it doesn't matter which object it is, only what it is—when all attribute values ​​of two insurance business-related objects are the same, they are considered the same object and treated as an insurance business value object. Value objects do not have unique identifiers; this is the biggest difference between value objects and entities. Furthermore, value objects are considered the same object by comparing all their properties; if they are identical, they are considered the same value object. However, when distinguishing between the same entity, we only check if the entity's unique identifier is the same, regardless of whether the entity's properties are the same. Another significant characteristic of value objects is their immutability; all properties are read-only. Because properties are read-only, they can be safely shared. When sharing value objects, there are generally two approaches: copying and sharing. The specific method used depends on the actual situation. Value objects should be designed to be as simple as possible, avoiding the creation of numerous references to other objects.

[0106] For step S520, the corresponding insurance business entity and insurance business value object are associated.

[0107] For step S530, multiple sets of associated insurance business entities and insurance business value objects are aggregated to form aggregate information, and the aggregate root is determined based on the aggregate information.

[0108] Understanding this, each aggregate has an aggregate root and an aggregate boundary. The aggregate boundary defines the entities or value objects within the aggregate, while the aggregate root is a specific entity within the aggregate. Objects within an aggregate can reference each other, but accessing objects within the aggregate from outside the aggregate requires navigating through the aggregate root. Direct access to objects within the aggregate cannot bypass the aggregate root; in other words, the aggregate root is the only element from outside that can maintain a reference to it. The unique identifiers of entities within the aggregate other than the root are local identifiers, meaning they only need to remain unique within the aggregate, as they always belong to that aggregate. The aggregate root is responsible for interacting with other external objects and maintaining its internal business rules. Objects within an aggregate can maintain references to other aggregate roots. Deleting an aggregate root requires simultaneously deleting all related objects within that aggregate, as they all belong to the same aggregate and form a complete concept.

[0109] When analyzing from an insurance business perspective, if the relationships between multiple related insurance business entities and insurance business value objects are cohesive, they can be considered as a whole and placed within an aggregate. Cohesiveness means that these objects must maintain a fixed rule; this fixed rule refers to a consistency rule that must remain unchanged when data changes. When modifying an aggregate, it should be ensured at the transaction level that all objects within the entire aggregate satisfy this fixed rule. Aggregates should ideally not be too large; otherwise, even if the integrity of the aggregate's business rules can be maintained at the transaction level, it may still lead to performance issues.

[0110] Reference Figure 5 For step S540, domain modeling is performed based on the aggregate root and bounded context to obtain the domain model, including but not limited to the following steps:

[0111] Step S541: Determine the target process information of the corresponding target business process from the business process information;

[0112] Step S542: Obtain the meta-model based on the target process information;

[0113] Step S543: Reconstruct the meta-model based on the aggregate root and bounded context to obtain the domain model corresponding to the target business process.

[0114] For step S541, the business process information contains process information of multiple business processes. One of the multiple business processes is determined as the target business process, and the business process information corresponding to the target business process is determined as the target process information.

[0115] For step S542, a meta-model is obtained based on the target process information. For example, the meta-model for training includes business domains, business processes, constraints, objectives, sub-objectives, subjects, relationships, objects, and adaptation rules; subjects are associated with organizers, teachers, and students; relationships are associated with teaching content and learning methods; and objects are associated with resources; subjects, relationships, and objects constitute business objects; objectives are decomposed into sub-objectives; and the process of continuously adapting knowledge and skills, business objects, and the market to continuously achieve objectives is called training.

[0116] For step S543, the metamodel is reconstructed based on the aggregate root and bounded context to obtain the domain model corresponding to the target business process. For example, the business domain, business process, constraints, objectives, sub-objectives, subjects, relationships, objects, and adaptation rules are described based on the aggregate root and bounded context. The business process is described as an insurance product sales process, the resources are described as sales courses and training venues, and the topic is described as insurance agents, etc.

[0117] Reference Figure 6 For step S600, the code model of the insurance middle platform is constructed based on the domain model, including but not limited to the following steps:

[0118] Step S610: Map the domain vocabulary of the domain model to the code objects of the code model one by one, wherein the domain model is described based on a common domain language;

[0119] Step S620: Construct a code model based on the code object.

[0120] A domain model described by a common domain language was established as input for microservice design, and the code model of microservice design is derived from the domain model. Applying a unified common domain language throughout the entire code model application and construction process is essential to ensure the correct mapping and transfer of domain vocabulary between the domain model and code objects in the code model, thereby guaranteeing consistency between business requirements and system implementation.

[0121] For step S700, an insurance middle platform is constructed based on the domain model and code model.

[0122] Specifically, an insurance middle platform is a middle-platform system applied to insurance business. The system connecting the front-end and back-end systems is called the middle platform system. The middle platform system extracts common "modules / services" from the back-end system—those related to technology, business, and organization—from the original fixed projects and makes them autonomous services available to the front-end system.

[0123] If the domain model and the code model are consistent, the insurance platform built based on these two models can handle the system scale and software complexity issues of large projects. The code model is built upon the domain model, ensuring that it originates from and serves the insurance business.

[0124] An embodiment of this application provides an insurance middleware construction device.

[0125] Reference Figure 7 The insurance platform construction device includes an information acquisition module 110, a domain determination module 120, a subdomain determination module 130, a context determination module 140, a domain model construction module 150, a code model construction module 160, and a platform construction module 170.

[0126] The information acquisition module 110 is used to acquire business segment information, business process information, and insurance domain events of the insurance business; the domain determination module 120 is used to divide the architecture into multiple domains based on the business segment information; the subdomain determination module 130 is used to divide the domain into subdomains based on the business process information; the context determination module 140 is used to extract domain terms from insurance domain events and determine the bounded context of the subdomains based on the domain terms; the domain model construction module 150 is used to perform domain modeling based on the subdomains and bounded contexts to obtain the domain model; the code model construction module 160 is used to construct the code model based on the domain model; and the platform construction module 170 is used to construct the insurance middle platform based on the domain model and the code model.

[0127] For the information acquisition module 110, insurance business information is acquired. This information includes at least business segment information, business process information, and insurance-related events. Business segment information is data related to insurance business segments, business process information is data related to insurance business processes, and insurance-related events are events specific to the insurance business.

[0128] For the domain determination module 120, the architecture is divided into multiple domains based on business segment information. It can be understood that a domain is a specific scope or area with defined business boundaries and scope; it is the business problem domain to be solved within those boundaries and scope. The larger the domain, the larger the business scope; the smaller the domain, the smaller the business scope.

[0129] For the subdomain determination module 130, the domain is divided into subdomains based on the business process information.

[0130] The domain can be further divided into subdomains, each corresponding to a smaller problem domain or a smaller business scope. The core domain provides core business functions and determines the product and core competitiveness; the general domain provides general business functions for the core business, which can be used by multiple subdomains simultaneously; the support domain supports the core business. The support domain is a necessary functional subdomain, but it does not contain functions that determine the product and the company's core competitiveness, nor does it contain general functions.

[0131] Subdomains can be divided into three categories based on their importance and functional attributes: core domains, general domains, and support domains.

[0132] Specifically, the core domain includes the first subdomain corresponding to recruitment, the second subdomain corresponding to training, the third subdomain corresponding to production capacity, the fourth subdomain corresponding to management, and the fifth subdomain corresponding to performance. The third subdomain includes subdomains corresponding to production capacity-purchasing, production capacity-customer management, production capacity-planning management, production capacity-communication, production capacity-consulting, and production capacity-product management.

[0133] The supporting domains include the sixth subdomain corresponding to personal business, the seventh subdomain corresponding to business analysis platform, the eighth subdomain corresponding to strategy center, the ninth subdomain corresponding to intelligent RTC, and the tenth subdomain corresponding to evaluation system.

[0134] The general domain includes the eleventh subdomain corresponding to the planning center, the twelfth subdomain corresponding to the activity center, the thirteenth subdomain corresponding to the attendance center, the fourteenth subdomain corresponding to the practice center, the fifteenth subdomain corresponding to the task center, the sixteenth subdomain corresponding to the user center, the seventeenth subdomain corresponding to the permission center, the eighteenth subdomain corresponding to the clue center, and the nineteenth subdomain corresponding to the content center.

[0135] The insurance middle platform construction device also determines the calling relationship between subdomains, as follows: the first, second, third, fourth, fifth, and sixth subdomains are integrated into the main process according to the agent lifecycle dimension; the other subdomains of the supporting domain (excluding the sixth subdomain) and the subdomains of the general domain are used as auxiliary processes; and the calling relationship between the main process and the auxiliary processes is determined.

[0136] By calling each other between the main process and the auxiliary process, user and scenario analysis is completed, simplifying the problem and reducing the complexity of business understanding and system implementation.

[0137] Since the subsequent domain model is built on the basis of the subdomain, the domain model also has this calling relationship.

[0138] For the context determination module 140, domain terms are extracted from insurance domain events; the correlation between domain terms and functions of subdomains is determined; and the domain terms are classified according to the correlation to obtain the bounded context of the functions of the corresponding subdomains.

[0139] Insurance domain events are domain-related events concerning insurance business. Domain events are used to achieve data consistency between various components. The ultimate recipient of a domain event can be a component within the current bounded context or another bounded context. An additional benefit of domain events is that they can record all significant modifications that occur within the software system, thus providing excellent support for program debugging and business intelligence.

[0140] By extracting domain terms from an event map formed from insurance domain events to describe the functions of subdomains, a mandatory boundary is defined for the functions of these subdomains. This ensures the singularity of function for each 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.

[0141] The relevance between domain terms and the functions of subdomains is determined, and domain terms related to the functions of the subdomain are grouped into the same bounded context to obtain the bounded context of the corresponding subdomain's functions. Specifically, when the relevance is greater than or equal to a preset relevance threshold, the domain term is grouped into the bounded context of the corresponding subdomain's functions; when the relevance is less than the preset relevance threshold, the domain term is excluded from the bounded context of the corresponding subdomain's functions.

[0142] Domain vocabulary is described by a domain-specific language, which determines the definition of bounded contexts, and thus the domain model is described based on the domain-specific language.

[0143] Models represent the commonalities within a software domain, making them suitable as the foundation for constructing such a universal language, and serving as the core framework of the language. Describing domain models using a domain-wide universal language enables seamless communication and gives the models broad applicability.

[0144] For the domain model construction module 150, insurance business entities and insurance business value objects are obtained based on the subdomains; the corresponding insurance business entities and insurance business value objects are associated; multiple sets of associated insurance business entities and insurance business value objects are aggregated to form aggregate information, and the aggregate root is determined based on the aggregate information; domain modeling is performed based on the aggregate root and the bounded context to obtain the domain model.

[0145] Specifically, insurance business entities and insurance business value objects are obtained based on the subdomain. The insurance business entity is a domain concept within the insurance business domain that requires unique identification. By setting a unique identifier for the insurance business entity, unique identity authentication can be achieved. Entities are persisted to the database after creation and retrieved only when needed. Entities should not be given too many attributes or behaviors; instead, relationships should be sought to discover other entities or value objects, and attributes or behaviors should be transferred to these related entities or value objects. Furthermore, since not every object in the domain needs a unique identifier—that is, it doesn't matter which object it is, only what it is—when all attribute values ​​of two insurance business-related objects are the same, they are considered the same object and are treated as insurance business value objects. Value objects do not have unique identifiers; this is the biggest difference between value objects and entities. Furthermore, value objects are considered the same object by comparing all their properties; if they are identical, they are considered the same value object. However, when distinguishing between the same entity, we only check if the entity's unique identifier is the same, regardless of whether the entity's properties are the same. Another significant characteristic of value objects is their immutability; all properties are read-only. Because properties are read-only, they can be safely shared. When sharing value objects, there are generally two approaches: copying and sharing. The specific method used depends on the actual situation. Value objects should be designed to be as simple as possible, avoiding the creation of numerous references to other objects.

[0146] Associate the corresponding insurance business entities and insurance business value objects.

[0147] Multiple related insurance business entities and insurance business value objects are aggregated to form aggregate information, and the aggregate root is determined based on the aggregate information.

[0148] Understanding this, each aggregate has an aggregate root and an aggregate boundary. The aggregate boundary defines the entities or value objects within the aggregate, while the aggregate root is a specific entity within the aggregate. Objects within an aggregate can reference each other, but accessing objects within the aggregate from outside the aggregate requires navigating through the aggregate root. Direct access to objects within the aggregate cannot bypass the aggregate root; in other words, the aggregate root is the only element from outside that can maintain a reference to it. The unique identifiers of entities within the aggregate other than the root are local identifiers, meaning they only need to remain unique within the aggregate, as they always belong to that aggregate. The aggregate root is responsible for interacting with other external objects and maintaining its internal business rules. Objects within an aggregate can maintain references to other aggregate roots. Deleting an aggregate root requires simultaneously deleting all related objects within that aggregate, as they all belong to the same aggregate and form a complete concept.

[0149] When analyzing from an insurance business perspective, if the relationships between multiple related insurance business entities and insurance business value objects are cohesive, they can be considered as a whole and placed within an aggregate. Cohesiveness means that these objects must maintain a fixed rule; this fixed rule refers to a consistency rule that must remain unchanged when data changes. When modifying an aggregate, it should be ensured at the transaction level that all objects within the entire aggregate satisfy this fixed rule. Aggregates should ideally not be too large; otherwise, even if the integrity of the aggregate's business rules can be maintained at the transaction level, it may still lead to performance issues.

[0150] Determine the target process information of the corresponding target business process from the business process information; obtain the meta-model based on the target process information; reconstruct the meta-model based on the aggregate root and bounded context to obtain the domain model of the corresponding target business process.

[0151] Furthermore, the business process information contains process information of multiple business processes. One of the multiple business processes is identified as the target business process, and the business process information corresponding to the target business process is identified as the target process information.

[0152] The meta-model is derived from the target process information. For example, the meta-model for training includes business domains, business processes, constraints, objectives, sub-objectives, subjects, relationships, objects, and adaptation rules. Subjects are associated with organizers, teachers, and students; relationships are associated with teaching content and learning methods; and objects are associated with resources. Subjects, relationships, and objects constitute business objects. Objectives are decomposed into sub-objectives. The process of continuously adapting knowledge and skills, business objects, and the market to achieve the objectives is called training.

[0153] The metamodel is reconstructed based on the aggregate root and bounded context to obtain the domain model corresponding to the target business process. For example, the business domain, business process, constraints, objectives, sub-objectives, subjects, relationships, objects, and adaptation rules are described based on the aggregate root and bounded context. The business process is described as an insurance product sales process, the resources are described as sales courses and training venues, and the topic is described as insurance agents, etc.

[0154] For the code model building module 160, the domain vocabulary of the domain model is mapped one by one to the code objects of the code model, where the domain model is described based on the domain common language; the code model is built based on the code objects.

[0155] A domain model described by a common domain language was established as input for microservice design, and the code model of microservice design is derived from the domain model. Applying a unified common domain language throughout the entire code model application and construction process is essential to ensure the correct mapping and transfer of domain vocabulary between the domain model and code objects in the code model, thereby guaranteeing consistency between business requirements and system implementation.

[0156] For platform building module 170, an insurance middle platform is built based on the domain model and code model.

[0157] Specifically, an insurance middle platform is a middle-platform system applied to insurance business. The system connecting the front-end and back-end systems is called the middle platform system. The middle platform system extracts common "modules / services" from the back-end system—those related to technology, business, and organization—from the original fixed projects and makes them autonomous services available to the front-end system.

[0158] If the domain model and the code model are consistent, the insurance platform built based on these two models can handle the system scale and software complexity issues of large projects. The code model is built upon the domain model, ensuring that it originates from and serves the insurance business.

[0159] Embodiments of this application also provide an electronic device. (Refer to...) Figure 8 The electronic device includes a memory 220, a processor 210, a program stored on the memory 220 and executable on the processor 210, and a data bus 230 for enabling communication between the processor 210 and the memory 220. When the program is executed by the processor 210, the above-mentioned insurance platform construction method is implemented.

[0160] The aforementioned electronic devices acquire business segment information, business process information, and insurance domain events related to insurance business; they then divide the architecture into multiple domains based on the business segment information; based on the business process information, they further divide the domains into subdomains; they extract domain vocabulary from insurance domain events and determine the bounded context of the subdomains based on the domain vocabulary; they perform domain modeling based on the subdomains and bounded contexts to obtain a domain model; they construct the code model of the insurance middle platform based on the domain model; they construct the insurance middle platform based on the domain model and the code model; and they build a unified insurance channel platform, providing multi-layered reuse capabilities across entities, domains, and channels. By rationally allocating domains and subdomains, they achieve reasonable business decomposition and describe the boundaries through bounded contexts, making business boundaries clear, simplifying the insurance system, and improving its efficiency.

[0161] This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0162] In general, for the hardware structure of electronic devices, the processor 210 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits to execute relevant programs in order to implement the technical solutions provided in the embodiments of this application.

[0163] The memory 220 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 220 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 220 and is called and executed by the processor 210 to execute the data monitoring method of the embodiments of this application.

[0164] Input / output interfaces are used to implement information input and output.

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

[0166] Bus 230 transmits information between various components of the device (e.g., processor 210, memory 220, input / output interface, and communication interface). Processor 210, memory 220, input / output interface, and communication interface are interconnected within the device via bus 230.

[0167] Embodiments of this application also provide a computer-readable storage medium storing computer-executable instructions for causing a computer to execute the above-described insurance platform construction method.

[0168] The aforementioned computer-readable storage medium acquires business segment information, business process information, and insurance domain events related to insurance business; it then divides the business segment information into multiple domains based on the architectural partitioning; it further divides the domains into subdomains based on the business process information; it extracts domain vocabulary from insurance domain events and determines the bounded context of the subdomains based on the domain vocabulary; it performs domain modeling based on the subdomains and bounded contexts to obtain a domain model; it constructs the code model of the insurance middle platform based on the domain model; it builds the insurance middle platform based on the domain model and the code model; and it establishes a unified insurance channel platform, providing multi-layered reuse capabilities across entities, domains, and channels. By rationally allocating domains and subdomains, it achieves reasonable business decomposition and describes the boundaries through bounded contexts, making business boundaries clear, simplifying the insurance system, and improving its efficiency.

[0169] It will be understood by those skilled in the art that all or some of the steps and systems in the methods disclosed above can be implemented as software, firmware, hardware, and suitable combinations thereof. Some or all of the physical components can be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, which can include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is well known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium. In the foregoing description of this specification, references to terms such as "one embodiment," "another embodiment," or "some embodiments," etc., indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of this application. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

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

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

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

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

[0174] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus 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 through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0175] Although embodiments of this application have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of this application, the scope of which is defined by the claims and their equivalents.

[0176] The above is a detailed description of the preferred embodiments of this application, but this application is not limited to the embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application, and these equivalent modifications or substitutions are all included within the scope defined by the claims of this application.

Claims

1. A method for constructing an insurance middleware platform, characterized in that, include: Obtain information on insurance business segments, business processes, and events in the insurance sector; The architecture is divided into multiple domains based on the aforementioned business segment information; The domain is divided into subdomains based on the business process information. Extract domain terms from the insurance domain events, and determine the bounded context of the subdomain based on the domain terms; A domain model is obtained by performing domain modeling based on the subdomain and the bounded context; Construct a code model based on the domain model; Construct an insurance middleware platform based on the domain model and the code model; The step of extracting domain vocabulary from the insurance domain events and determining the bounded context of the subdomain based on the domain vocabulary includes: Extract domain-specific vocabulary from the aforementioned insurance-related events; Determine the correlation between the domain vocabulary and the functions of the subdomains; Based on the correlation, the domain vocabulary is categorized to obtain the bounded context of the functions corresponding to the subdomain; The process of performing domain modeling based on the subdomain and the bounded context to obtain a domain model includes: Based on the subdomain, the insurance business entity and the insurance business value object are obtained; Associate the corresponding insurance business entity with the corresponding insurance business value object; Multiple sets of associated insurance business entities and insurance business value objects are aggregated to form aggregate information, and an aggregate root is determined based on the aggregate information; Domain modeling is performed based on the aggregate root and the bounded context to obtain the domain model.

2. The insurance middleware construction method according to claim 1, characterized in that, The process of performing domain modeling based on the aggregate root and the bounded context to obtain a domain model includes: Determine the target process information corresponding to the target business process from the aforementioned business process information; A meta-model is obtained based on the target process information; The meta-model is reconstructed based on the aggregate root and the bounded context to obtain the domain model corresponding to the target business process.

3. The insurance middleware construction method according to claim 1, characterized in that, The subdomains include a core domain, a general domain, and a support domain; the core domain is used to provide core services, the general domain is used to provide general services for the core services, and the support domain is used to support the core services.

4. The insurance middleware construction method according to claim 3, characterized in that, The core domain includes a first subdomain corresponding to recruitment, a second subdomain corresponding to training, a third subdomain corresponding to productivity, a fourth subdomain corresponding to management, and a fifth subdomain corresponding to performance; the support domain includes a sixth subdomain corresponding to individual business. After dividing the domain into subdomains based on the business process information, the insurance middle platform construction method further includes: The first subdomain, the second subdomain, the third subdomain, the fourth subdomain, the fifth subdomain, and the sixth subdomain are integrated into the main process according to the agent lifecycle dimension; The subdomains of the supporting domain other than the sixth subdomain and the subdomains of the general domain are used as auxiliary processes; Determine the calling relationship between the main process and the auxiliary process; The process of obtaining a domain model based on the subdomain and the bounded context includes: A domain model is obtained by performing domain modeling based on the subdomain, the bounded context, and the calling relationship.

5. The insurance middleware construction method according to claim 1, characterized in that, The step of constructing a code model based on the domain model includes: The domain vocabulary of the domain model is mapped one by one to the code objects of the code model, wherein the domain model is described based on a common domain language; The code model is constructed based on the code object.

6. An insurance platform construction device, characterized in that, include: The information acquisition module is used to acquire information on business segments, business processes, and events in the insurance field. The domain determination module is used to divide the architecture into multiple domains based on the business segment information; The subdomain determination module is used to divide the domain into subdomains based on the business process information. A context determination module is used to extract domain terms from the insurance domain events and determine the bounded context of the subdomain based on the domain terms; A domain model construction module is used to perform domain modeling based on the subdomain and the bounded context to obtain a domain model; A code model building module is used to build a code model based on the domain model. The platform construction module is used to construct the insurance middleware based on the domain model and the code model; The step of extracting domain vocabulary from the insurance domain events and determining the bounded context of the subdomain based on the domain vocabulary includes: Extract domain-specific vocabulary from the aforementioned insurance-related events; Determine the correlation between the domain vocabulary and the functions of the subdomains; Based on the correlation, the domain vocabulary is categorized to obtain the bounded context of the functions corresponding to the subdomain; The process of performing domain modeling based on the subdomain and the bounded context to obtain a domain model includes: Based on the subdomain, the insurance business entity and the insurance business value object are obtained; Associate the corresponding insurance business entity with the corresponding insurance business value object; Multiple sets of associated insurance business entities and insurance business value objects are aggregated to form aggregate information, and an aggregate root is determined based on the aggregate information; Domain modeling is performed based on the aggregate root and the bounded context to obtain the domain model.

7. An electronic device, characterized in that, The electronic device includes a memory, a processor, a program stored in the memory and executable on the processor, and a data bus for enabling communication between the processor and the memory. When the program is executed by the processor, it implements the insurance platform construction method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions for causing a computer to perform the insurance platform construction method as described in any one of claims 1 to 5.

Images