Domain model verification method and device and processor
By annotating verification annotations in the domain model and calling verification logic uniformly, the problems of code verbose, inconsistency and repetition in traditional methods are solved, simplification and optimization of domain model verification are achieved, and the maintainability and development efficiency of code are improved. .
Patent Information
- Application Number
- CN202411341867.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-24
- Publication Date
- 2025-01-10
AI Technical Summary
Traditional domain model verification methods require manual writing of large amounts of verification code, resulting in code verbose, inconsistency and repetition, increasing development complexity and error risks.
By pre-noting verification annotations in the domain model and calling unified verification logic based on these annotations, identifying and applying applicable verification components or tool logic, reducing manual code writing to ensure consistency and maintainability of verification logic.
It realizes maintainability and consistency of code, reduces duplicate code, simplifies the verification process, improves development efficiency, and closely links verification logic with business rules, making it easier to adjust and expand.
Smart Images
Figure CN119293471A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the technical field of domain model verification, and in particular to a domain model verification method, device and processor. Background Art
[0002] In the traditional domain model validation implementation, a large amount of validation code is usually required to be manually written to ensure the validity and integrity of the data, which leads to the following problems: First, manually written validation logic usually needs to handle multiple validation conditions for each field or attribute, including format validation, length restriction, range check, etc. Each validation condition requires the writing of special code logic, such as using if...else statements or writing complex conditional judgments, which not only increases the development workload, but also makes the code lengthy and difficult to maintain. Secondly, this manual writing method often lacks uniformity. Since each developer may use different coding styles and methods when implementing validation logic, the validation logic may be inconsistent throughout the application. This inconsistency not only increases the complexity of domain model validation, but may also introduce errors that are difficult to find. For example, a field needs to verify whether its length meets the requirements in one place, while a different format check may be required in another place. If these validation logics are not managed uniformly, it may cause conflicts in business logic and inconsistent data. In addition, manually written validation code can easily lead to code duplication. The same validation logic may appear in multiple places, and each time it needs to be rewritten and maintained, increasing the redundancy of the code and the risk of errors. When modifying a validation rule, developers need to update it in multiple places, which may easily lead to inconsistencies in validation logic and potential vulnerabilities.
[0003] Therefore, how to reduce the manual writing of domain model verification code to avoid the duplication and inconsistency of verification code, thereby simplifying and optimizing the verification process of the domain model, is a technical problem that technical personnel in this field urgently need to solve. Summary of the invention
[0004] Based on the above problems, the present application provides a domain model verification method, device and processor, the purpose of which is to reduce the manual writing of domain model verification code to avoid duplication and inconsistency of verification code, thereby simplifying and optimizing the domain model verification process.
[0005] The embodiments of the present application disclose the following technical solutions:
[0006] A method for verifying a domain model, the method comprising:
[0007] Identify whether the target domain model satisfies a verification condition; the verification condition is used to indicate that the target domain model is a domain model to be logically verified;
[0008] If the target domain model satisfies the verification condition, identifying the verification annotations pre-annotated on the target domain model; the verification annotations are pre-annotated based on the business requirements of the target domain model;
[0009] Calling the validation logic corresponding to the target domain model based on the validation annotation; the validation logic is a unified validation logic;
[0010] The target domain model is logically verified based on the verification logic.
[0011] In a possible implementation, calling the validation logic corresponding to the target domain model based on the validation annotation includes:
[0012] Determine the type of the verification annotation; the type of the verification annotation includes a simple annotation type or a complex annotation type;
[0013] If the type of the validation annotation is a complex annotation type, calling the validation component corresponding to the target domain model based on the validation annotation;
[0014] The verification logic in the verification component is determined as the verification logic corresponding to the target domain model.
[0015] In a possible implementation, the construction process of the verification component includes:
[0016] Acquire various domain models and domain model attributes of the various domain models;
[0017] Based on the domain model attributes, the domain models are classified into types, and the domain models with the same domain model attributes are classified into the same category to obtain multiple groups of domain model groups;
[0018] A unified complex validation logic is defined for each domain model group respectively; the number of conditions and / or the number of rules of the complex validation logic is greater than a quantity threshold;
[0019] The complex verification logics are respectively encapsulated by the specification module to obtain a plurality of verification components; there is a one-to-one correspondence between the verification components and the domain model groups;
[0020] Annotate each verification component with an encapsulation annotation respectively, and edit a corresponding verification annotation for each encapsulation annotation; there is a one-to-one correspondence between the encapsulation annotation and the verification annotation; the verification annotation corresponding to the encapsulation annotation is annotated on the corresponding domain model based on the business requirements of the domain model; the type of the verification annotation corresponding to the encapsulation annotation is a complex annotation type.
[0021] In a possible implementation, calling the validation component corresponding to the target domain model based on the validation annotation includes:
[0022] Based on the verification annotation, determining an encapsulation annotation having a one-to-one correspondence with the verification annotation as a target encapsulation annotation;
[0023] A verification component corresponding to the target domain model is determined based on the target encapsulation annotation.
[0024] In a possible implementation, calling the validation logic corresponding to the target domain model based on the validation annotation further includes:
[0025] If the type of the validation annotation is a simple type, the validation logic is called from the validation tool class based on the validation annotation, and the validation logic is used as the validation logic corresponding to the target domain model; the number of conditions and / or the number of rules of the simple validation logic is less than the quantity threshold.
[0026] In a possible implementation, the process of defining the verification logic in the verification tool class includes:
[0027] Get all the unified basic validation logic in the Java validation framework;
[0028] A verification annotation is respectively marked for each basic verification logic; there is a one-to-one correspondence between the verification annotation of the basic verification logic and the basic verification logic; the verification annotation of the basic verification logic is marked on the corresponding domain model based on the business requirements of the domain model;
[0029] The various basic verification logics marked with the verification annotations are stored in the verification tool class.
[0030] In a possible implementation, the step of identifying whether the target domain model satisfies a verification condition includes:
[0031] Identify whether the target domain model inherits the domain model validation base class; and / or,
[0032] Identify whether the target domain model is annotated with a validation activation annotation.
[0033] In a possible implementation, the method further includes:
[0034] If the target domain model does not meet the verification conditions, a corresponding verification exception reminder is thrown through the verification tool class.
[0035] A domain model verification device, the device comprising:
[0036] A first identification unit is used to identify whether the target domain model meets the verification condition; the verification condition is used to indicate that the target domain model is a domain model to be logically verified;
[0037] A second identification unit, if the target domain model satisfies the verification condition, is used to identify the verification annotations pre-annotated on the target domain model; the verification annotations are pre-annotated based on the business requirements of the target domain model;
[0038] A calling unit, used to call the verification logic corresponding to the target domain model based on the verification annotation; the verification logic is a unified verification logic;
[0039] A logic verification unit is used to perform logic verification on the target domain model based on the verification logic.
[0040] A processor for running a computer program, wherein when the program is run, the verification method of the domain model as described above is executed
[0041] Compared with the prior art, this application has the following beneficial effects:
[0042] The present application provides a domain model verification method, device and processor. Specifically, when executing the domain model verification method provided by the embodiment of the present application, first identify whether the target domain model meets the verification conditions, and the verification conditions are used to indicate that the target domain model is a domain model to be logically verified. If the target domain model meets the above verification conditions, then it is necessary to identify the verification annotations pre-annotated on the target domain model. The verification annotations are pre-annotated based on the business requirements of the target domain model. Then, based on the identified verification annotations, the verification logic corresponding to the target domain model is called. The verification logic called is a unified verification logic. By using a unified verification logic, it can be ensured that the same type of verification operations adopt consistent standards and processes, thereby improving the consistency and maintainability of the code. Finally, the target domain model is logically verified based on the verification logic called.
[0043] This application avoids spreading a large number of if...else statements in the code to handle different verification situations by pre-marking verification annotations in the domain model and uniformly calling these logics in the verification method. This allows the verification logic to be managed in one place, enhancing the maintainability of the code. At the same time, using unified verification logic, similar verification requirements can be summarized in one place to achieve reuse and reduce code duplication.
[0044] In addition, by identifying validation conditions and annotations, the corresponding validation logic is automatically called, which simplifies the validation implementation process. Developers do not need to manually write validation code every time, but can automate the process through definition and annotation. By closely integrating validation annotations with business requirements and concentrating them in validation methods, the code logic can be made clearer. Developers can quickly understand the validation requirements of the domain model by looking at the annotations instead of searching for complex if...else structures in the code.
[0045] In addition, through the configuration of annotations and verification conditions, logical verification can be easily adjusted and expanded without modifying a large amount of code. Adding or modifying verification logic only needs to be done in annotations or verification conditions without modifying implementation details.
[0046] Finally, pre-annotated validation annotations are based on business requirements, which ensures that the validation logic directly reflects the business rules. BRIEF DESCRIPTION OF THE DRAWINGS
[0047] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.
[0048] Figure 1 A schematic diagram of an exemplary application scenario provided for an embodiment of the present application;
[0049] Figure 2 A flowchart of an implementation method for verifying a domain model provided in an embodiment of the present application;
[0050] Figure 3 A flowchart of an implementation method of a method for calling verification logic based on verification annotations provided in an embodiment of the present application;
[0051] Figure 4 A flowchart of an implementation method of a method for constructing a verification component provided in an embodiment of the present application;
[0052] Figure 5 A flowchart of an implementation method of a method for defining verification logic in a verification tool class provided in an embodiment of the present application;
[0053] Figure 6 A schematic diagram of the structure of a domain model verification device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0054] In order to make the above-mentioned objects, features and advantages of the present application more obvious and easy to understand, the embodiments of the present application are further described in detail below in conjunction with the accompanying drawings and specific implementation methods.
[0055] The upper-level service class refers to a layer of service between the domain model (such as data entity class) and the business logic, which is responsible for coordinating and processing operations related to the domain model, including data validation.
[0056] As mentioned above, in the traditional domain model validation implementation, it is usually necessary to manually write a large amount of validation code to ensure the validity and integrity of the data, which leads to some problems. First, manually writing validation code is too cumbersome and time-consuming. Developers need to verify each attribute one by one and write corresponding if...else statements or methods to execute various validation logics, which increases the complexity and maintenance cost of the code. Secondly, since each developer may have different implementation styles and ideas, the implementation of the validation code lacks uniformity, and the validation logic may be inconsistent or repeatedly written. In addition, manually writing a large amount of validation code also has the risk of introducing errors. If the developer omits or incorrectly implements certain validation logic, it will lead to data inconsistency or security vulnerabilities. In addition, as the scale of the domain model grows and requirements change, it becomes difficult and error-prone to manually maintain and update these validation codes.
[0057] Based on this, the embodiment of the present application provides a domain model verification method, device and processor. First, the verification process checks whether the target domain model meets specific verification conditions, which guide the execution of related verification logic. If the target domain model meets these verification conditions, it is necessary to find the verification annotations pre-attached to the domain model, which are pre-defined according to business requirements. Then, the verification logic corresponding to the target domain model is called according to these verification annotations. All called verification logics are operated according to unified standards and processes, ensuring the consistency and manageability of the verification operation. Finally, by executing these verification logics, the target domain model is logically verified. The present application effectively manages verification rules and enhances code maintainability by pre-marking verification annotations in the domain model and uniformly calling verification logic to avoid cumbersome if...else statements; adopts unified verification logic to summarize similar requirements and reduce duplicate code; automatically identifies verification conditions and calls corresponding logic to simplify the verification process and improve development efficiency; realizes clear code logic by combining annotations with business requirements, which facilitates developers to understand verification requirements and reduce search costs; pre-marked verification annotations based on business requirements ensure that verification logic is closely associated with business rules.
[0058] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.
[0059] See also Figure 1 , which is a framework diagram of an exemplary application scenario provided in an embodiment of the present application.
[0060] Identify whether the target domain model satisfies the validation conditions that indicate that the target domain model needs to be logically validated. There are two types of validation conditions: one is that the target domain model inherits the domain model validation base class, and the other is that the target domain model is annotated with a validation activation annotation. The domain model validation base class is the DomainModelValidate base class, which is a base class for implementing domain model validation. The target domain model can be any domain model. The validation activation annotation can be an annotation such as @DomainValidate.
[0061] If the target domain model inherits the domain model validation base class, or the target domain model is annotated with validation activation annotations, it means that the target domain model meets the validation conditions. At this time, the logical validation process of the domain model is activated. First, the validation annotations on the target domain model that are pre-annotated based on the business requirements of the target domain model can be identified. The business requirements of the target domain model refer to the requirements for modeling and defining data and functions in a specific business domain. This includes the relationships, attributes, rules, and operation requirements between business entities, aiming to meet the requirements of business processes and logic.
[0062] If the validation annotation type is a complex annotation type, then the validation component corresponding to the target domain model is called based on the validation annotation, and the validation logic in the validation component is determined as the validation logic corresponding to the target domain model. If the validation annotation type is a simple annotation type, then the validation logic is called from the validation tool class based on the validation annotation, and the validation logic is used as the validation logic corresponding to the target domain model. To distinguish whether the validation logic of the domain model is a complex annotation type or a simple annotation type, it can be judged by but not limited to the following aspects: the number of conditions of the validation logic, the number of rules of the validation logic, the data dependency of the validation logic, the algorithm used by the validation logic, or the complexity of the validation logic, etc.
[0063] Then, based on the validation logic in the validation component or the validation logic in the validation tool class, the target domain model is logically validated.
[0064] Those skilled in the art will understand that Figure 1 The framework diagram shown is only an example in which the embodiments of the present application can be implemented. The scope of application of the embodiments of the present application is not limited in any aspect by the framework.
[0065] To facilitate understanding of the present application, a domain model verification method provided in an embodiment of the present application is described below with reference to the accompanying drawings.
[0066] See also Figure 2 As shown in FIG. 1 , this figure is a flow chart of a domain model verification method provided in an embodiment of the present application, such as Figure 2 As shown, the method may include S201-S204:
[0067] S201: Identify whether the target domain model meets the verification conditions.
[0068] In order to execute the validation logic of the domain model, it is first necessary to determine whether the target domain model meets the pre-defined validation conditions. Once it is confirmed that the target domain model meets the validation conditions, logical validation will be performed next, that is, the pre-set validation logic and rules are applied to the data in the target domain model to ensure the correctness of the data and meet business requirements.
[0069] The target domain model can be any domain model. The domain model can be a visual representation of concepts in a certain domain or objects (or targets) in practical applications. It can be an abstraction of how business roles and business entities should be connected and collaborated to perform corresponding business.
[0070] In a possible implementation, there are two ways to identify whether the target domain model meets the verification conditions:
[0071] First, identify whether the target domain model inherits the domain model validation base class.
[0072] The domain model validation base class is the DomainModelValidate base class. The DomainModelValidate base class is a base class for implementing domain model validation. In software development, domain models represent business entities or concepts. When operating and processing these domain models, it is necessary to ensure the integrity and validity of their data. The DomainModelValidate base class provides a set of common methods and functions for verifying whether the data of the domain model meets the expected rules and standards. By inheriting and extending this base class, specific validation logic can be customized for different domain models, thereby improving the reusability and maintainability of the code.
[0073] Before activating the logical validation process of the domain model, you can check whether the target domain model inherits this base class. If the target domain model inherits this validation base class, it has the validation mechanism and functions provided by the base class. This means that the domain model already has the infrastructure for performing logical validation, such as the necessary validation methods and data structures, and the logical validation process of the domain model can be activated at this time.
[0074] In a possible implementation, whether the target domain model inherits the DomainModelValidate base class can be identified by checking through the reflection mechanism or specific tools provided by the programming language. This can be achieved through but not limited to the following methods:
[0075] Reflection mechanism: In a programming language that supports reflection, you can use reflection to check the inheritance relationship of the target domain model. By obtaining the class information of the target domain model, you can check whether its parent class (base class) is the DomainModelValidate base class.
[0076] Static code analysis tools: Using static code analysis tools such as SonarQube, Programming Mistake Detector (PMD), etc. can help check inheritance relationships in source code. These tools can scan the code base and identify which classes inherit a specified base class.
[0077] Manual check: Search for the definition of the target domain model in the code and check its class declaration to determine whether it inherits the DomainModelValidate base class. This approach is suitable for smaller code bases or when there is a clear understanding of a specific domain model.
[0078] Through the above method, you can determine which domain models inherit the DomainModelValidate base class.
[0079] Second, identify whether the target domain model is annotated with validation activation annotations.
[0080] Identifying whether the target domain model is annotated with a validation activation annotation (the validation activation annotation may be an annotation such as @DomainValidate) means checking the source code of the target domain model to determine whether there is an annotation such as @DomainValidate in its definition. This annotation is usually used to indicate that the domain model needs to undergo a specific validation process. If the target domain model is identified as annotated with a validation activation annotation, it means that the target domain model meets the validation conditions, and the logical validation process of the domain model can be activated.
[0081] In this possible implementation, in order to identify whether the target domain model is annotated with a validation activation annotation, the validation activation annotation may be identified by, but not limited to, the following methods:
[0082] Check the annotations on the class or field: traverse the domain model class and its fields to see if there are annotations such as @DomainValidate. These annotations may contain validation rules or tags that trigger validation;
[0083] Use reflection tools: In programming languages such as Java, you can use reflection to dynamically check the annotations of classes and fields. For example, in Java, you can use the Class.getAnnotations() or Field.getAnnotations() method to get annotation information.
[0084] It should be noted that the logical verification process of the domain model can be activated if at least one of the above two verification methods is passed.
[0085] In a possible implementation, the method further includes:
[0086] If the target domain model does not meet the verification condition, a corresponding verification exception reminder is thrown through the verification tool class to terminate the calling work of the target domain model.
[0087] If the domain model does not meet the validation conditions, the validation tool class will throw an exception (such as ValidationException), which usually contains detailed error information, explaining the reason for the validation failure. The thrown exception will interrupt the current processing flow, thereby preventing the execution of subsequent operations. For example, if a user inputs data that does not meet the requirements, the validation exception will prevent the data from being further processed or stored.
[0088] The validation tool class is the Validates tool class, which provides various validation methods to help developers perform data verification and validation. Such a tool class usually contains a series of common data validation functions such as checking whether it is empty, whether it conforms to a specific format, and whether it meets the length requirements.
[0089] S202: If the target domain model satisfies the verification condition, identifying the verification annotations pre-annotated on the target domain model.
[0090] If the target domain model meets the validation conditions, we need to find the validation annotations pre-added to the domain model. These validation annotations are pre-defined and added based on the business requirements of the target domain model to indicate the specific validation operations and rules that need to be performed during the validation process. This approach can ensure that the validation process complies with specific business logic and requirements, and improve the accuracy and consistency of data validation.
[0091] The business requirements of the target domain model refer to the requirements and rules for the data domain model in a specific business scenario. This includes aspects such as business logic, data integrity, and validation rules. When designing the target domain model, the validation conditions and rules that need to be met are defined based on the business requirements. Therefore, the validation annotations that are pre-annotated based on the business requirements of the target domain model are annotations added to meet the data validation rules required by these specific business scenarios.
[0092] In a possible implementation, business requirements include but are not limited to the following:
[0093] Data integrity: Data integrity ensures that the data in the domain model conforms to the business logic. For example, the email field in the user domain model must be a valid email address, and the password must meet certain complexity requirements;
[0094] Business rules: Business rules refer to requirements or conditions in a specific business scenario, which are used to ensure that business processes and data meet actual needs and logic. These rules are directly related to business activities and business logic. For example, a business rule may stipulate that "the order amount must be greater than zero." This rule ensures that the order amount in the system is logically valid, and orders with negative or zero amounts are not allowed;
[0095] Validity of user input: Verify that the data entered by the user complies with the expected format and range. For example, a phone number should be in a valid format that complies with national standards;
[0096] Performance requirements: Verify the performance requirements of the domain model under specific operations. For example, the system may require that the response time of each request does not exceed a certain time limit;
[0097] Sequence of business processes: Ensure that domain models are processed in the correct order within a specific business process. For example, when processing an order, the order items must be created first and then the order itself.
[0098] S203: Calling the validation logic corresponding to the target domain model based on the validation annotation.
[0099] Calling the validation logic corresponding to the target domain model based on the validation annotation means that when executing the validation process, the system will trigger the corresponding validation operation according to the validation annotation defined in the domain model. These validation annotations are metadata added to the domain model class or its attributes to specify validation rules or conditions. Specifically, validation annotations can define which fields need to be validated, what the validation conditions are, and how to handle validation failures.
[0100] For example, if a domain model class contains a validation annotation named @NotNull, the system will automatically recognize the annotation and call the corresponding validation logic when processing the domain model instance. This validation logic is a predefined unified validation rule that is used to ensure that the data in the domain model meets specific business requirements or rules. This unified validation logic can simplify the code structure, improve code reusability, and ensure that the validation process in the application is more consistent and maintainable.
[0101] See also Figure 3 , Figure 3 A flowchart of an implementation method of a method for calling verification logic based on a verification annotation provided in an embodiment of the present application. Accordingly, calling the verification logic corresponding to the target domain model based on the verification annotation can be implemented through steps A1-A3:
[0102] A1: Determine the type of the verification annotation.
[0103] Determining the type of validation annotations refers to identifying and classifying the specific categories of validation annotations applied to the domain model. These annotations can be divided into simple annotation types and complex annotation types. Simple annotation types usually contain basic validation rules, such as checking whether a field is empty or conforms to a specific format, which directly and clearly specify the validation conditions. Complex annotation types involve more complex validation logic, such as combining multiple conditions, performing cross-field validation, or performing custom validation logic. By determining the type of annotation, the system can accurately process and execute the corresponding validation rules, thereby ensuring the data validity and consistency of the domain model.
[0104] For example, a simple annotation type:
[0105] ① Data format verification: Verify whether the data format of the field meets specific requirements, such as date format, email format, etc. For example, @Pattern(regexp="\\d{4}-\\d{2}-\\d{2}").
[0106] ② Data range verification: Verify whether the value range of the field is within the specified range. For example, @Min(value=18).
[0107] ③ Non-empty validation: Verify whether the field is empty. For example, @NotNull.
[0108] Complex annotation types:
[0109] ① Cross-field validation: It is necessary to compare the relationship between multiple fields. For example, the custom annotation @AgeAndBirthdateValid ensures that the age and date of birth match.
[0110] ② Custom logic verification: complex calculations or business logic verification are required. For example, the custom annotation @CreditLimitReached checks whether the credit limit is exceeded based on the user's credit limit and consumption.
[0111] ③Combined condition verification: multiple conditions must be met at the same time. For example, @AllTrue({@Size(min=5),@Pattern(regexp="[a-zA-Z0-9]+")}), verify the length and format at the same time.
[0112] Simple annotations usually deal with a single field or simple conditions, while complex annotations involve cross-field validation, custom logic, or multiple condition combinations.
[0113] A2: If the type of the validation annotation is a complex annotation type, the validation component corresponding to the target domain model is called based on the validation annotation.
[0114] If the type of the validation annotation is a complex annotation type, the system will call the corresponding validation component based on this complex annotation to validate the target domain model.
[0115] See also Figure 4 , Figure 4 This is a flowchart of an implementation method of a verification component construction method provided in an embodiment of the present application. The specific verification component construction process can be implemented through steps B1-B5:
[0116] B1: Acquire various domain models and domain model attributes of the various domain models.
[0117] To build the verification component of the domain model, we first need to collect and identify all different domain models and extract their respective characteristics and attribute information.
[0118] In a possible implementation, the domain model attributes of the domain model may include but are not limited to business requirements, data structures, and validation rules. The domain model attributes of the domain model describe the requirements of the business rules, data structures, and validation logic that the domain model needs to meet in a specific domain.
[0119] B2: Classify the domain models based on the domain model attributes, classify the domain models with the same domain model attributes into the same category, and obtain multiple groups of domain model groups.
[0120] Based on the domain model attributes, the domain models are classified into the same category with the same domain model attributes. The domain models with similar characteristics are classified into the same group. This makes it more efficient and unified to process the same type of domain models, and facilitates the subsequent verification logic definition and component construction.
[0121] Specifically, to achieve the classification of domain models based on domain model attributes, classify similar domain models into the same category and obtain multiple domain model groups, the following steps are usually required:
[0122] First, collect and analyze the attribute information of each domain model, including fields, data types, constraints, etc.;
[0123] Then, according to the attribute characteristics of different domain models, determine which domain models have the same or similar attribute structures;
[0124] Finally, domain models with the same attribute structure are divided into one category to form multiple domain model groups.
[0125] The domain models in each domain model group have similar attributes, which allows for better management and processing of these domain models so that unified validation logic can be defined for them and corresponding validation components can be created.
[0126] For example, assume there are three domain models: domain model 1, domain model 2, and domain model 3. Each domain model has different properties:
[0127] The attributes of domain model 1 include: domain model 1name, email, password;
[0128] The attributes of domain model 2 include: domain model 1 name, email, role;
[0129] The attributes of domain model 3 include: domain model 1name, email;
[0130] Based on the domain model attributes, the classification criteria can be defined as follows:
[0131] Group 1: contains domain models whose attributes include domain model 1name and email (such as domain model 1, domain model 2, domain model 3);
[0132] Group 2: Domain model with an additional attribute password (like domain model 1);
[0133] Group 3: Domain model with additional attribute role (like domain model 2).
[0134] Ultimately, the domain model will be divided into the following groups:
[0135] Group 1: Domain Model 1, Domain Model 2, Domain Model 3;
[0136] Group 2: Domain Model 1;
[0137] Group 3: Domain Model 2.
[0138] In this way, by classifying the attributes of domain models, these domain models can be better organized and managed, facilitating subsequent processing and operations.
[0139] B3: Define unified and complex validation logic for each domain model group.
[0140] Develop a common set of complex validation rules and logic for domain models with similar attribute characteristics in the same group. These validation rules may include multiple conditions, constraints, and business rules to ensure the integrity, accuracy, and compliance with specific business requirements of the data. Doing so can improve code reusability, simplify maintenance, and ensure that the data validation process in the system is more consistent and reliable.
[0141] In a possible implementation, to distinguish whether the validation logic of the domain model is complex or simple, it can be distinguished by several aspects, including but not limited to the number of conditions of the validation logic, the number of rules of the validation logic, the data dependency of the validation logic, the algorithm used by the validation logic, or the complexity of the validation logic.
[0142] Specifically, (1) the number of conditions and / or the number of rules of the validation logic are distinguished:
[0143] Simple validation logic usually involves fewer conditions and rules, such as checking whether a field is empty, whether the length meets the requirements, etc. That is to say, the number of conditions and / or rules of simple validation logic is less than a certain threshold;
[0144] Complex validation logic may need to consider the combination of multiple conditions and rules, requiring more data processing and comparison, that is, the number of conditions and / or the number of rules of complex validation logic is greater than a certain threshold.
[0145] (2) Differentiate by verifying the data dependencies of the logic:
[0146] Simple validation logic is usually independent of other data items and only requires simple validation of the current data;
[0147] Complex validation logic may be required to perform validation based on the relationships and dependencies between different data items.
[0148] (3) Differentiate by the algorithm used by the verification logic or the complexity of the verification logic:
[0149] Simple validation logic may only involve basic comparison operations or format validation, and the logic is relatively straightforward.
[0150] Complex validation logic may require the execution of more complex algorithms or business rules and may require validation across multiple data points.
[0151] In addition, the error handling and feedback of the validation logic can also be distinguished:
[0152] Simple validation logic usually only needs to return a simple validation result, such as true or false.
[0153] Complex validation logic may require more detailed error messages or validation reports to help users understand why validation failed.
[0154] By considering the above aspects, you can evaluate whether the validation logic for validating the domain model is simple or complex.
[0155] In one possible implementation, to define unified complex validation logic for each domain model group, you can follow these steps:
[0156] Gather requirements: First understand the business requirements and data validation rules to determine the validation logic that needs to be implemented.
[0157] Identify the commonalities of domain model attributes: Analyze the domain models in each domain model group to find out their common attributes and validation rules.
[0158] Define validation rules: Based on common attributes, formulate consistent validation rules and conditions that apply to all domain models in the group. This may include rules on data format, value range, association, etc.
[0159] Coding validation logic: Based on the defined validation rules, write the corresponding validation logic code to ensure that the logic can accurately verify whether the data of each domain model meets the rule requirements.
[0160] Testing and optimization: Test the defined validation logic and optimize it based on the feedback to ensure the validation process is accurate.
[0161] Through the above steps, a unified set of complex validation logic can be established, which is suitable for grouping domain models of specific types or with similar characteristics, thereby improving the efficiency and consistency of data validation.
[0162] B4: Encapsulating each of the complex verification logics through a specification module to obtain multiple verification components.
[0163] After defining unified and complex validation logic, each complex validation logic can be encapsulated through the specification module to obtain multiple validation components, each of which has a one-to-one correspondence with the domain model group. This means that an independent validation component is created for the complex validation logic defined in each domain model group, so that each component can independently handle the data validation requirements of the domain model in the group. This one-to-one correspondence ensures a close connection between the validation component and the corresponding domain model group, improving the flexibility and scalability of data validation in the system.
[0164] The specification module is a set of specifications or standards used in software engineering to define, describe and verify system requirements or functions. These specifications can cover aspects such as system behavior, performance, and interfaces, and help ensure correctness, consistency, and reliability during software development.
[0165] B5: Mark each verification component with a package annotation, and edit the corresponding verification annotation for each package annotation.
[0166] Mark each validation component with an encapsulation annotation and edit the corresponding validation annotation to ensure a one-to-one correspondence between the encapsulation annotation and the validation annotation. This is done to mark the required validation annotations on the corresponding domain model based on the business requirements of the domain model, and to classify the types of these validation annotations into complex annotation types. In this way, a clear mapping relationship can be established for the complex validation logic and rules defined for each domain model group, making the data validation process more standardized and more maintainable.
[0167] In a possible implementation, calling the validation component corresponding to the target domain model based on the validation annotation includes:
[0168] Based on the verification annotation, an encapsulation annotation having a one-to-one correspondence with the verification annotation is determined as a target encapsulation annotation. Then, based on the target encapsulation annotation, a verification component corresponding to the target domain model is determined.
[0169] By confirming that the encapsulation annotations that have a one-to-one correspondence with the verification annotations are used as the target encapsulation annotations, the system can effectively manage and organize the verification logic. Subsequently, the verification components corresponding to the target domain model are determined according to the target encapsulation annotations. This method helps the system structure and encapsulate different types of verification requirements and finally form corresponding verification components, thereby achieving a more flexible and efficient verification process and ensuring the accuracy and integrity of the domain model data.
[0170] A3: Determine the verification logic in the verification component as the verification logic corresponding to the target domain model.
[0171] After the verification component corresponding to the target domain model is called, the verification logic encapsulated in the verification component can be determined as the verification logic corresponding to the target domain model, so that the target domain model can perform logic verification based on this verification logic.
[0172] In one possible implementation, if the type of the validation annotation is a simple type, the validation logic is called from the validation tool class based on the validation annotation, and the validation logic is used as the validation logic corresponding to the target domain model; the number of conditions and / or the number of rules of the simple validation logic is less than the quantity threshold.
[0173] When the type of the validation annotation is a simple type, the system will call the corresponding validation logic from the validation tool class based on these simple validation annotations, and use the validation logic as the validation logic corresponding to the target domain model. This type of validation logic usually contains a small number of conditions and rules, which is lower than the preset threshold. In this way, the system can handle relatively simple validation requirements, maintain the clarity and efficiency of the validation logic, and ensure the validity and consistency of the target domain model data.
[0174] It should be noted that the type of validation annotation is a simple type, which is similar to @NotNull, @NotBlank, and @Length. The @NotNull annotation indicates that the value of the attribute cannot be null. The @NotBlank annotation indicates that the attribute of the string type cannot be empty and the length must be greater than 0 after removing spaces. The @Length annotation is used to specify the length range of the string attribute, including the minimum length and maximum length.
[0175] See also Figure 5 , Figure 5 This is a flowchart of an implementation method of a method for defining verification logic in a verification tool class provided in an embodiment of the present application, which can be specifically implemented through steps C1-C3:
[0176] C1: Get all the unified basic validation logic in the Java validation framework.
[0177] Obtaining all unified basic validation logic in the Java validation framework means collecting and integrating the standard validation rules and logic provided by the validation framework. These basic validation logics include common data validation, format validation, range restriction and other functions. By using these validation logics, the validity and integrity of the data can be ensured. This step helps to build a general and reliable data validation tool library, providing unified basic operation support for the validation of different domain models.
[0178] Among them, the Java validation framework is the Java Validation framework. The Java Validation framework is a tool for simplifying data validation and verification, which can help developers easily implement effective data validation.
[0179] C2: Annotate each basic validation logic with validation annotations.
[0180] Annotating each basic validation logic with validation annotations means adding clear marks to each validation rule, and these annotations correspond to the corresponding validation logic. These annotations are applied to the corresponding domain model according to the business requirements of the domain model, thereby achieving accurate validation of each domain model.
[0181] In a possible implementation, the basic validation logic and its corresponding validation annotations may include but are not limited to:
[0182] ① Not Null Validation: Not Null Validation is used to check whether the attribute value is null, validation annotation: @NotNull.
[0183] ②String length verification (Size): used to check whether the length of the string is within the specified range, verification annotation: @Size.
[0184] ③Email verification (Email): used to check whether the attribute value conforms to the email address format, verification annotation: @Email.
[0185] ④Regular expression validation (Pattern): used to check whether the attribute value conforms to the specified regular expression, validation annotation: @Pattern.
[0186] ⑤Numeric range verification (Min, Max): used to check whether the numeric type attribute is within the specified minimum and maximum value range, verification annotation: @Min, @Max.
[0187] ⑥Future date verification (Future): used to check whether the date attribute is a future date, verification annotation: @Future.
[0188] ⑦ Past date verification (Past): used to check whether the date attribute is a past date, verification annotation: @Past.
[0189] ⑧Validity verification (Valid): used to indicate that nested objects need recursive verification, verification annotation: @Valid.
[0190] These basic validation logics provide common data validation requirements and are defined declaratively through corresponding validation annotations. When an application uses the Java validation framework to perform data validation, these unified basic validation logics automatically trigger the corresponding validator to perform validation operations based on the specific validation annotations. This unified validation mechanism simplifies the implementation, management, and maintenance of data validation, and helps ensure the validity and integrity of data.
[0191] C3: storing each basic verification logic marked with the verification annotation in the verification tool class.
[0192] Storing each basic validation logic annotated with validation annotations in the validation tool class means integrating the annotated validation rules into a unified tool class. This makes it easier for the system to call these validation logics when data validation is required, improves the reusability and maintainability of the code, and ensures the consistency and standardization of the entire validation process. This approach makes the management of validation logic more convenient and helps simplify the implementation and maintenance of the validation process.
[0193] S204: Performing logic verification on the target domain model based on the verification logic.
[0194] Logically verifying the target domain model based on the verification logic means using pre-defined verification rules, conditions and logic to verify the data of the target domain model. This process can ensure that the target domain model meets the expected requirements and specifications, help the system maintain the accuracy of the target domain model, and improve the reliability of the target domain model.
[0195] It should also be noted that the various validation components that encapsulate complex validation logic and the validation tool classes that store basic validation logic are highly cohesive within the domain model. The validation components and tool classes cohesive within the domain model are closely integrated with the domain model and can be called in real time when data validation is required to ensure that data is validated and processed immediately. At the same time, by cohesively integrating validation logic within the domain model, it is possible to avoid the validation logic being incorrectly applied to other modules or data sets, reducing the possibility of erroneous results.
[0196] Based on the description of S201-S204, the embodiment of the present application first identifies the validation conditions of the target domain model to determine whether it meets the specific validation requirements. Subsequently, the validation annotations pre-marked on the target domain model are searched and identified, and these annotations are added to the domain model in advance according to business requirements. Then, by calling the corresponding validation logic of the target domain model, these logics are uniformly designed to ensure that the same type of validation behavior adopts consistent standards and processes, thereby improving the consistency and maintainability of the code. Finally, the target domain model is logically validated based on the call validation logic. In the traditional domain model validation method of the present application, developers may need to write a large number of if...else statements for different validation rules to check different conditions. Compared with the traditional domain model validation method, the present application can concentrate all validation rules in one place by using predefined validation annotations and unified validation logic, and execute these rules through a unified validation mechanism. In this way, developers only need to focus on defining validation annotations and validation logic, without adding complex conditional judgments everywhere in the code. At the same time, since the validation logic is unified and centrally managed, the maintainability of the code is improved. If the validation rules need to be modified, developers only need to change the definition of the annotation or the validation logic without having to modify a large number of if...else statements. This makes updating the validation logic simpler and more consistent. In addition, using unified validation logic, similar validation requirements can be summarized in one place to achieve reuse and reduce code duplication.
[0197] Based on the domain model verification method provided by the above method embodiment, the embodiment of the present application also provides a domain model verification device, which will be described below in conjunction with the accompanying drawings.
[0198] See also Figure 6 As shown in FIG. 1 , this figure is a schematic diagram of the structure of a domain model verification device provided in an embodiment of the present application. Figure 6 As shown, the verification device of the domain model includes:
[0199] A first identification unit 601 is used to identify whether the target domain model meets the verification condition; the verification condition is used to indicate that the target domain model is a domain model to be logically verified;
[0200] A second identification unit 602 is used to identify the verification annotations pre-annotated on the target domain model if the target domain model meets the verification condition; the verification annotations are pre-annotated based on the business requirements of the target domain model;
[0201] A calling unit 603 is used to call the verification logic corresponding to the target domain model based on the verification annotation; the verification logic is a unified verification logic;
[0202] The logic verification unit 604 is used to perform logic verification on the target domain model based on the verification logic.
[0203] In a possible implementation, the calling unit 603 specifically includes:
[0204] A verification annotation type determination unit, used to determine the type of the verification annotation; the type of the verification annotation includes a simple annotation type or a complex annotation type;
[0205] A verification component calling unit, for calling the verification component corresponding to the target domain model based on the verification annotation if the type of the verification annotation is a complex annotation type;
[0206] The first verification logic determination unit is used to determine the verification logic in the verification component as the verification logic corresponding to the target domain model.
[0207] In a possible implementation manner, the device further includes:
[0208] A first acquisition unit, used to acquire various domain models and domain model attributes of the various domain models;
[0209] A domain model classification unit, used to classify the domain models based on the domain model attributes, classify the domain models with the same domain model attributes into the same category, and obtain multiple groups of domain model groups;
[0210] A complex verification logic definition unit, used to define unified complex verification logic for each domain model group; the number of conditions and / or the number of rules of the complex verification logic is greater than a quantity threshold;
[0211] A logic encapsulation unit, used to encapsulate each of the complex verification logics through a specification module to obtain a plurality of verification components; there is a one-to-one correspondence between the verification components and the domain model groups;
[0212] The package annotation marking unit is used to mark the package annotations of each verification component respectively;
[0213] A validation annotation editing unit is used to edit the corresponding validation annotation for each of the encapsulation annotations; there is a one-to-one correspondence between the encapsulation annotation and the validation annotation; the validation annotation corresponding to the encapsulation annotation is annotated on the corresponding domain model based on the business requirements of the domain model; the type of the validation annotation corresponding to the encapsulation annotation is a complex annotation type.
[0214] In a possible implementation, the verification component calling unit specifically includes:
[0215] a target encapsulation annotation determining unit, configured to determine, based on the verification annotation, an encapsulation annotation having a one-to-one correspondence with the verification annotation as a target encapsulation annotation;
[0216] A verification component determination unit is used to determine the verification component corresponding to the target domain model based on the target encapsulation annotation.
[0217] In a possible implementation, the calling unit 603 further includes:
[0218] A verification logic calling unit, for calling verification logic from a verification tool class based on the verification annotation if the type of the verification annotation is a simple type;
[0219] A setting unit is used to use the verification logic called from the verification tool class based on the verification annotation as the verification logic corresponding to the target domain model; the number of conditions and / or the number of rules of the simple verification logic is less than a quantity threshold.
[0220] In a possible implementation manner, the device further includes:
[0221] The second acquisition unit is used to acquire all unified basic verification logics in the Java verification framework;
[0222] A verification annotation marking unit, used to mark verification annotations for each basic verification logic respectively; there is a one-to-one correspondence between the verification annotations of the basic verification logic and the basic verification logic; the verification annotations of the basic verification logic are marked on the corresponding domain model based on the business requirements of the domain model;
[0223] The storage unit is used to store the various basic verification logics marked with the verification annotations in the verification tool class.
[0224] In a possible implementation, the first identification unit 601 specifically includes:
[0225] A domain model validation base class identification unit, used to identify whether the target domain model inherits the domain model validation base class;
[0226] The verification activation annotation identification unit is used to identify whether the target domain model is annotated with a verification activation annotation.
[0227] In a possible implementation manner, the device further includes:
[0228] The verification exception reminder unit is used to throw a corresponding verification exception reminder through the verification tool class if the target domain model does not meet the verification conditions.
[0229] In addition, an embodiment of the present application further provides a processor for running a computer program, which executes the domain model verification method as described above when the program is running.
[0230] The embodiment of the present application provides a verification of a domain model, first using a first identification unit 601 to identify whether the target domain model meets the verification conditions, and the verification conditions indicate that the target domain model needs to be logically verified. If the target domain model meets the verification conditions, the second identification unit 602 is used to identify the verification annotations that are pre-annotated on the target domain model based on the business requirements of the target domain model. Then the calling unit 603 calls the unified verification logic corresponding to the target domain model based on the verification annotations, so that the logic verification unit 604 performs logic verification on the target domain model based on the verification logic.
[0231] This application proposes a method of pre-marking validation annotations in the domain model and uniformly calling these logics in the validation method to avoid the extensive use of if...else statements in the code to handle various validation situations. This method achieves the induction and reuse of validation requirements by unifying the validation logic, reducing the duplication of the code. At the same time, by identifying the validation conditions and annotations, the corresponding validation logic is automatically called, which simplifies the validation implementation process. Developers do not need to manually write validation code, but can achieve automated processing through definition and annotation. This method closely integrates the validation logic with business requirements, makes the code structure clearer, and developers can quickly understand the validation requirements by viewing the annotations. In addition, the adjustment and expansion of the validation logic also becomes more convenient. Only the annotations or conditions need to be modified without major changes to the code implementation, thereby maintaining the consistency of the validation logic with the business rules.
[0232] It should be noted that each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. The device embodiment described above is merely schematic, in which the unit described as a separate component may or may not be physically separated, and the component prompted as a unit may or may not be a physical unit, that is, it may be located in one place, or it may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without paying creative work.
[0233] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.
Claims
1. A domain model verification method, characterized in that: The method comprises: Identify whether the target domain model satisfies a verification condition; the verification condition is used to indicate that the target domain model is a domain model to be logically verified; If the target domain model satisfies the verification condition, identifying the verification annotations pre-annotated on the target domain model; the verification annotations are pre-annotated based on the business requirements of the target domain model; Calling the validation logic corresponding to the target domain model based on the validation annotation; the validation logic is a unified validation logic; The target domain model is logically verified based on the verification logic.
2. The method according to claim 1, characterized in that The calling of the validation logic corresponding to the target domain model based on the validation annotation includes: Determine the type of the verification annotation; the type of the verification annotation includes a simple annotation type or a complex annotation type; If the type of the validation annotation is a complex annotation type, calling the validation component corresponding to the target domain model based on the validation annotation; The verification logic in the verification component is determined as the verification logic corresponding to the target domain model.
3. The method according to claim 2, characterized in that The construction process of the verification component includes: Acquire various domain models and domain model attributes of the various domain models; Based on the domain model attributes, the domain models are classified into types, and the domain models with the same domain model attributes are classified into the same category to obtain multiple groups of domain model groups; A unified complex validation logic is defined for each domain model group respectively; the number of conditions and / or the number of rules of the complex validation logic is greater than a quantity threshold; The complex verification logics are respectively encapsulated by the specification module to obtain a plurality of verification components; there is a one-to-one correspondence between the verification components and the domain model groups; Annotate each verification component with an encapsulation annotation respectively, and edit a corresponding verification annotation for each encapsulation annotation; there is a one-to-one correspondence between the encapsulation annotation and the verification annotation; the verification annotation corresponding to the encapsulation annotation is annotated on the corresponding domain model based on the business requirements of the domain model; the type of the verification annotation corresponding to the encapsulation annotation is a complex annotation type.
4. The method according to claim 2, characterized in that: The calling of the validation component corresponding to the target domain model based on the validation annotation includes: Based on the verification annotation, determining an encapsulation annotation having a one-to-one correspondence with the verification annotation as a target encapsulation annotation; A verification component corresponding to the target domain model is determined based on the target encapsulation annotation.
5. The method according to claim 2, characterized in that: The calling of the validation logic corresponding to the target domain model based on the validation annotation also includes: If the type of the validation annotation is a simple type, the validation logic is called from the validation tool class based on the validation annotation, and the validation logic is used as the validation logic corresponding to the target domain model; the number of conditions and / or the number of rules of the simple validation logic is less than the quantity threshold.
6. The method according to claim 5, characterized in that The definition process of the verification logic in the verification tool class includes: Get all the unified basic validation logic in the Java validation framework; A verification annotation is respectively marked for each basic verification logic; there is a one-to-one correspondence between the verification annotation of the basic verification logic and the basic verification logic; the verification annotation of the basic verification logic is marked on the corresponding domain model based on the business requirements of the domain model; The various basic verification logics marked with the verification annotations are stored in the verification tool class.
7. The method according to claim 1, characterized in that The step of identifying whether the target domain model satisfies the verification condition includes: Identify whether the target domain model inherits the domain model validation base class; and / or, Identify whether the target domain model is annotated with a validation activation annotation.
8. The method according to claim 1, characterized in that The method further comprises: If the target domain model does not meet the verification conditions, a corresponding verification exception reminder is thrown through the verification tool class.
9. A domain model verification device, characterized in that: The device comprises: A first identification unit is used to identify whether the target domain model meets the verification condition; the verification condition is used to indicate that the target domain model is a domain model to be logically verified; A second identification unit, if the target domain model satisfies the verification condition, is used to identify the verification annotations pre-annotated on the target domain model; the verification annotations are pre-annotated based on the business requirements of the target domain model; A calling unit, used to call the verification logic corresponding to the target domain model based on the verification annotation; the verification logic is a unified verification logic; A logic verification unit is used to perform logic verification on the target domain model based on the verification logic.
10. A processor, characterized in that: Used to run a computer program, which, when running, executes the domain model verification method according to any one of claims 1 to 8.