Method for constructing microservice field algebraic data types based on functional programming

Abstract

The application relates to the computer technical field, in particular to a micro-service domain algebra data type construction method based on functional programming, which comprises the following steps: obtaining a variant list of a target business domain; identifying the properties of each variant in the variant list, and determining the type of each variant according to the properties of each variant; combining all the variants in the variant list based on the type of each variant to obtain an algebra data type tree, compiling the algebra data type tree, verifying the compiled algebra data type tree, and performing business processing through the verified algebra data type tree. Therefore, the problems of scattered domain object definition, high coupling degree, lack of clear boundaries and complex and lengthy verification logic in the micro-service are solved, the readability and maintainability of the code are improved, and the overall reliability and development efficiency of the micro-service system are enhanced.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method for constructing microservice domain algebra data types based on functional programming. Background Technology

[0002] With the widespread adoption of microservice architecture in enterprise applications, systems are broken down into multiple highly cohesive, loosely coupled service units, each modeled around a specific business domain. In this process, the domain object, as the core element carrying business semantics, directly impacts the maintainability, scalability, and robustness of the system.

[0003] However, in current practice, many microservices often define business objects with the same characteristics (such as user identity information) in a repetitive and scattered manner, lacking unified abstraction and boundary constraints, resulting in code redundancy, scattered logic, and difficulty in adapting to rapidly changing business needs. Summary of the Invention

[0004] This application provides a method for constructing algebraic data types for microservice domains based on functional programming. This method addresses issues such as scattered domain object definitions, high coupling, lack of clear boundaries, and complex and lengthy verification logic in microservices. By introducing functional programming concepts, it aggregates and encapsulates business attributes with common characteristics in a fine-grained manner. This not only effectively decouples the domain model but also intercepts illegal state errors that might otherwise be exposed at runtime during the compilation phase. This simplifies data transfer and verification processes, improves code readability and maintainability, and ultimately enhances the overall reliability and development efficiency of the microservice system.

[0005] The first aspect of this application provides a method for constructing algebraic data types in a microservice domain based on functional programming, including the following steps: Obtain a list of variants for the target business domain; Identify the properties of each variant in the variant list, and determine the type of each variant based on the properties of each variant; Based on the type of each variant, all variants in the variant list are combined to obtain an algebraic data type tree. The algebraic data type tree is then compiled and verified, so that business processing can be performed using the verified algebraic data type tree.

[0006] Optionally, in some embodiments, obtaining the variant list of the target business domain includes: Identify all business differences that may occur in the target business domain under a cross-microservice scenario; The variant list is generated based on all the business differences.

[0007] Optionally, in some embodiments, identifying the properties of each variant in the variant list and determining the type of each variant based on the properties of each variant includes: Based on the same business time, a first target variant that satisfies the mutually exclusive variant condition is selected from the variant list to obtain a first variant set, and a second target variant that satisfies the complete existence condition is selected from the variant list to obtain a second variant set; The type of the variants in the first variant set is determined to be of type S, and the type of the variants in the second variant set is determined to be of type P.E.

[0008] Optionally, in some embodiments, it further includes: Determine if a source code change event exists; If the aforementioned source code change event exists, a new branch will be added, and a compilation error warning will be issued if the verification of the new branch fails.

[0009] Optionally, in some embodiments, the variants in the variant list include at least one of user identifier, user name, user identity information, user email address, and email verification timestamp.

[0010] A second aspect of this application provides a microservice domain algebra data type construction apparatus based on functional programming, comprising: The acquisition module is used to obtain a list of variants for the target business domain; An identification module is used to identify the properties of each variant in the variant list and determine the type of each variant based on the properties of each variant; The verification module is used to combine all variants in the variant list based on the type of each variant to obtain an algebraic data type tree, compile the algebraic data type tree, and verify the compiled algebraic data type tree so that business processing can be performed on the verified algebraic data type tree.

[0011] Optionally, in some embodiments, the acquisition module includes: The identification unit is used to identify all business differences that may occur in the target business domain in a cross-microservice scenario; A generation unit is used to generate the variant list based on all the business difference items.

[0012] Optionally, in some embodiments, the identification module includes: The filtering unit is used to filter out a first target variant that satisfies the mutually exclusive variant condition from the variant list based on the same business time to obtain a first variant set, and to filter out a second target variant that satisfies the complete existence condition from the variant list to obtain a second variant set; The determination unit is used to determine the type of the variant in the first variant set as a sum type and the type of the variant in the second variant set as a product type.

[0013] Optionally, in some embodiments, it further includes: The judgment unit is used to determine whether a source code change event exists. The reminder unit is used to determine the new branch when the source code change event exists, and to provide a compilation exception reminder if the verification of the new branch fails.

[0014] Optionally, in some embodiments, the variants in the variant list include at least one of user identifier, user name, user identity information, user email address, and email verification timestamp.

[0015] A third aspect of this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method for constructing microservice domain algebra data types based on functional programming as described in the above embodiments.

[0016] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the method for constructing microservice domain algebra data types based on functional programming as described in the above embodiments.

[0017] Therefore, by obtaining a list of variants for the target business domain, identifying the properties of each variant, and determining the type of each variant based on its properties, all variants in the list are combined based on their types to obtain an algebraic data type tree. This algebraic data type tree is then compiled and validated before business processing is performed. This addresses the problems of scattered domain object definitions, high coupling, lack of clear boundaries, and complex and lengthy validation logic in microservices. By introducing functional programming concepts, business attributes with common characteristics are aggregated and encapsulated at a fine-grained level. This not only effectively decouples the domain model but also intercepts illegal state errors that might otherwise be exposed at runtime during the compilation stage. This simplifies data transfer and validation processes, improves code readability and maintainability, and ultimately enhances the overall reliability and development efficiency of the microservice system.

[0018] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0019] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 A schematic diagram illustrating the principle of defining domain objects for user information in related technologies; Figure 2 This is a flowchart of a method for constructing algebraic data types in a microservice domain based on functional programming, according to an embodiment of this application. Figure 3 This is a schematic diagram illustrating the principle of a method for constructing algebraic data types in a microservice domain based on functional programming, according to an embodiment of this application. Figure 4 This is an example diagram of an apparatus for constructing algebraic data types in the microservice domain based on functional programming, according to an embodiment of this application. Figure 5 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of this application. Detailed Implementation

[0020] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0021] Before introducing the method for constructing algebraic data types in microservices based on functional programming in the embodiments of this application, we will first introduce the methods in related technologies.

[0022] For example, such as Figure 1 As shown, assume the following domain rules (business definitions) for user information: user name, user identity information (ID card, passport, etc.), user email (whether the email has been registered and verified), and email verification timestamp.

[0023] The definition method in related technologies is: public class Customer { private String id; / / User name private String userName; / / User's passport number private String passport; / / User's ID number private String identityCard; / / User email address private String email; / / This field is false when the email address is not verified. private boolean isEmailVerified; / / This field contains the verification timestamp if the email address is verified; otherwise, it is an empty string. private String emailVerifiedAt;} When defining domain objects for user information, current implementations of related technologies involve creating identity information such as id, userName, passport, identityCard, and email one by one. This results in problems such as scattered domain object definitions, high coupling, lack of clear boundaries, and complex and lengthy verification logic.

[0024] To address the aforementioned issues, this application provides a method for constructing algebraic data types for microservice domains based on functional programming. This method involves obtaining a list of variants for the target business domain, identifying the properties of each variant, determining the type of each variant based on its properties, combining all variants in the list based on their types to obtain an algebraic data type tree, compiling the algebraic data type tree, and validating the compiled algebraic data type tree for business processing. This solves the problems of scattered domain object definitions, high coupling, lack of clear boundaries, and complex and lengthy validation logic in microservices. By introducing functional programming concepts, it aggregates and encapsulates business attributes with common characteristics at a fine-grained level, effectively decoupling the domain model and intercepting illegal state errors that might otherwise be exposed at runtime during the compilation stage. This simplifies data transfer and validation processes, improves code readability and maintainability, and ultimately enhances the overall reliability and development efficiency of the microservice system.

[0025] Specifically, Figure 2 This is a flowchart illustrating a method for constructing algebraic data types in a microservice domain based on functional programming, as provided in an embodiment of this application.

[0026] like Figure 2 As shown, this method for constructing algebraic data types in microservice domains based on functional programming includes the following steps: In step S101, a list of variants of the target business domain is obtained.

[0027] Optionally, in some embodiments, obtaining a variant list of the target business domain includes: identifying all business differences that may occur in the target business domain across microservice scenarios; and generating a variant list based on all business differences.

[0028] The variants in the variant list include at least one of user identifier, user name, user identity information, user email address, and email verification timestamp; the target business domain is the logical boundary defined in the microservice system around specific business capabilities (such as user management, identity authentication, etc.).

[0029] Specifically, this application identifies all possible business differences in the target business domain across various microservice interaction scenarios, namely, which fields exist, whether they are verified, and whether they carry timestamps or other semantic changes. Subsequently, a complete list of variants is constructed based on these differences. This list covers not only basic attributes (such as user ID and name) but also composite attributes with state semantics (such as verified email addresses and their verification times), thus providing input for subsequent unified modeling. Through this process, the polymorphism of business objects is explicitly expressed, avoiding implicit assumptions and hard-coded judgments.

[0030] Therefore, by acquiring and structuring a list of variants of the target business domain, the system can clearly define the legal forms of domain objects in different contexts, effectively eliminating integration errors caused by inconsistent understanding of fields.

[0031] Furthermore, to facilitate understanding by those skilled in the art, before explaining steps S102 and S103, let's first introduce the Algebraic Data Type Tree (ADT). An ADT refers to a way of combining multiple types into a new type, and these combinations possess some algebraic characteristics. We primarily use two types for modeling: product types and sum types.

[0032] Product Types: Product types are new types composed of multiple types. They represent structures that contain multiple values ​​simultaneously. Each member of a product type can have a different type, and all members are required. For example: public class TextStyle { boolean bold; Font font;} / / where public enum Font { SERIF, SANS_SERIF, MONOSPACE} The type mentioned above contains two member variables, bold and Font, which represent whether to use bold and the font used, respectively. When initializing this type, the above combination is used.

[0033]

[0034] In abstract syntax, this can be understood as: TextStyle = bold Font.

[0035] Sum Types: Sum types are new types composed of one of several types. They represent multiple possible values. Each member of a sum type can have a different type, and only one member can be chosen. In programming languages, sum types are typically represented using enumerations or union types.

[0036] For example, consider a sum type representing color: enum Color { Red, Green, Blue} The above indicates that the type contains three member variables: Red, Green, and Blue, representing red, green, and blue respectively. Different colors can be represented through this type.

[0037] In step S102, the properties of each variant in the variant list are identified, and the type of each variant is determined based on the properties of each variant.

[0038] Optionally, in some embodiments, identifying the properties of each variant in the variant list and determining the type of each variant based on the properties of each variant includes: based on the same business time, selecting a first target variant from the variant list that satisfies the condition of mutually exclusive variants to obtain a first variant set, and selecting a second target variant from the variant list that satisfies the condition of complete existence to obtain a second variant set; determining the type of the variants in the first variant set as the sum type, and determining the type of the variants in the second variant set as the product type.

[0039] Among them, the properties of variants refer to the logical characteristics exhibited by variants at the business semantics and data structure levels. These mainly include whether they are mutually exclusive with other variants (i.e., only one can exist at a time) or whether they need to coexist with other variants to constitute a complete business state; and type, used to represent one of a set of mutually exclusive options; and product type, which indicates that multiple attributes must exist simultaneously. The mutually exclusive variant condition means that at a specific business moment, several variants cannot coexist and can only appear one at a time (e.g., user identity information is either an ID card or a passport, and neither can be used as the primary identifier simultaneously); the complete existence condition means that certain variants must appear in groups to express a valid business meaning (e.g., email address and email verification timestamp must exist simultaneously to indicate a verified state).

[0040] Specifically, the system performs semantic analysis on each variant in the variant list to identify its combination rules within the business context. Firstly, based on data snapshots or business rule constraints at the same business moment, it determines which variants are mutually exclusive. For example, if a user can only use either an ID card or a passport as identification, these mutually exclusive variants are grouped into the first variant set and modeled as a product type to ensure that any valid state contains only one of these options. Secondly, it identifies variant combinations that must coexist to constitute a valid business entity. For example, if an email verification timestamp exists, the user's email address must also exist, and vice versa. These variants are grouped into the second variant set and modeled as a product type to enforce their completeness. Through this classification mechanism, the valid state space of domain objects is accurately characterized, and illegal combinations are eliminated at the model level.

[0041] In step S103, based on the type of each variant, all variants in the variant list are combined to obtain an algebraic data type tree, which is then compiled and verified to enable business processing based on the verified algebraic data type tree.

[0042] Specifically, for each determined variant type (either a sum type or a product type), the variant list is structurally aggregated according to the combination rules of algebraic data types: product type variants are combined into composite nodes with multiple fields, while sum type variants are organized into union nodes with mutually exclusive branches. Through recursive combination, a complete ADT tree is finally formed, fully characterizing all legal data forms in the target business domain. Subsequently, this ADT tree is compiled into type definition code in the target language and verified by a type system or a custom validator—including checking for missing variants, contradictory combinations, and whether exhaustive pattern matching is supported.

[0043] like Figure 3 As shown, Figure 3 The algebraic data type tree obtained by combining all variants in the variant list in this application embodiment, after compilation, is: public class Customer { private String id; / / User name private String userName; / / User certificate information private IdentityCert identityCert / / User email private Email email;} public abstract class IdentityCert { @Value public static class IdentityCard extends IdentityCert { private String cardNo; public IdentityCard(String cardNo) { this.cardNo = cardNo; } } @Value public static class Passport extends IdentityCert { private String passportNo; public Passport(String passportNo) { this.passportNo = passportNo; } } } Public abstract class Email { @Value public static class VerifiedEmailInfoextends Email { private String Email; private String emailVerifiedAt It should be noted that there seems to be a small error in the original text where "Email" in line 49 should probably be "email" for better coding style consistency. Also, the code seems to be a bit incomplete or might have some compilation issues in a real Java context. This translation is done based on the provided text as it is.public VerifiedEmailInfo (String email, String emailVerifiedAt) { this.eamil = eamil; this.emailVerifiedAt=emailVerifiedAt; } } @Value public static class UnverifiedEmailInfo extends Email { private String email; public UnverifiedEmailInfo (String email) { this.email = email; } } } Combination Figure 1 and Figure 3 As can be seen, ADT modeling has less nesting, fewer fields, fewer types, and shorter code. In fact, it... Figure 3 When the relationships between types are identified, it becomes clear that modeling in related technologies involves more multiplications, while ADT modeling involves several additions. Types with multiple multiplicative complexities allow for more possible terms and have larger sizes. Therefore, the term size of traditional modeling is larger than that of ADT modeling. Furthermore, the modeling methods in related technologies require the addition of defensive logic to manually validate and exclude illegal states in all functions or methods that consume user information before consuming data. In other words, the complexity saved when defining types is replaced by additional defensive code in all places where type consumption occurs.

[0044] Based on this, the embodiments of this application can be further optimized using ADT modeling: public abstract class IdentityCert { private IdentityCert() {} publicabstract <r>R accept(Visitor <r>visitor); public interface Visitor <r>{ R visit(IdentityCard cursor); R visit(Passport cursor); } @Value public static class IdentityCard extends IdentityCert { public IdentityCard(String cardNo) { / / Assume only 10 - digit identity card numbers are accepted if (cardNo.length() != 18) { throw new UserException("customer.cardNoWrong"); } this.cardNo = cardNo; } private String cardNo; @Override public <r>R accept(Visitor <r>visitor) { return visitor.visit(this); } } Therefore, this application uses the observer pattern to observe the definitions and types, which ensures that when a new data type is added, the relevant validation is not forgotten, and there are no more runtime exceptions because the visitor knows exactly which types exist. The validation of the data is defined in the domain model, thereby avoiding complex validation logic.

[0045] In summary, this application's embodiments achieve a precise mapping from business semantics to the type system by constructing and verifying an algebraic data type tree (ADT). On one hand, the strong typing characteristic of the ADT tree prevents any data construction that does not conform to business rules from being constructed during the compilation phase, preventing illegal states from flowing into the runtime. On the other hand, the verification mechanism ensures the integrity and consistency of the model, avoiding logical vulnerabilities caused by human oversight. During the business processing phase, developers can safely deconstruct object states using functional features such as pattern matching, significantly simplifying condition judgment and verification logic, and improving code readability and maintainability.

[0046] Optionally, in some embodiments, the method further includes: determining whether a source code change event exists; if a source code change event exists, determining the addition of a branch, and issuing a compilation exception warning if the verification of the addition of the branch fails.

[0047] Among them, source code change events refer to the addition, modification, or deletion of source code (such as variant lists, type combination rules, etc.) that defines algebraic data types (ADTs) during the software development process; new branches refer to new type combination paths or state branches introduced into the ADT tree structure due to source code changes, such as adding a variant combination corresponding to a new user authentication method; compilation exception alerts are error messages or alarms automatically issued by the system when compiling and verifying an ADT tree containing new branches, if it does not conform to preset business rules or type constraints (such as illegal states, missing necessary fields, violation of mutual exclusion conditions, etc.), in order to prevent non-compliant models from entering subsequent business processes.

[0048] Specifically, during system operation or continuous integration, the system continuously monitors for source code change events related to the domain model. Once such a change is detected (e.g., adding a mobile phone number and SMS verification code as user identity variants), the system parses the changed content and identifies the new branch in the resulting ADT tree, i.e., the newly introduced state combination path. Subsequently, the system performs the same compilation and verification process as the original model on the new branch, including type validity checks, mutual exclusion / integrity constraint verification, and pattern matching coverage analysis. If verification fails, a compilation exception warning is immediately triggered to prevent the change from being merged or deployed, and the specific reason for the violation is reported to the developer, ensuring that only semantically correct and structurally compliant models can participate in business processing.

[0049] The method for constructing algebraic data types for microservice domains based on functional programming, as proposed in this application, involves obtaining a list of variants of the target business domain, identifying the properties of each variant, determining the type of each variant based on its properties, combining all variants in the list based on their types to obtain an algebraic data type tree, compiling the algebraic data type tree, and validating the compiled algebraic data type tree for business processing. This solves the problems of scattered domain object definitions, high coupling, lack of clear boundaries, and complex and lengthy validation logic in microservices. By introducing functional programming concepts, it aggregates and encapsulates business attributes with common characteristics at a fine-grained level, effectively decoupling the domain model and intercepting illegal state errors that might otherwise be exposed at runtime during the compilation stage. This simplifies data transfer and validation processes, improves code readability and maintainability, and ultimately enhances the overall reliability and development efficiency of the microservice system.

[0050] Next, referring to the accompanying drawings, a device for constructing microservice domain algebraic data types based on functional programming, according to an embodiment of this application, is described.

[0051] Figure 4 This is a block diagram of a microservice domain algebra data type construction device based on functional programming according to an embodiment of this application.

[0052] like Figure 4 As shown, the microservice domain algebra data type construction device 10 based on functional programming includes: an acquisition module 100, an identification module 200, and a verification module 300.

[0053] The acquisition module 100 is used to acquire a list of variants of the target business domain.

[0054] The identification module 200 is used to identify the properties of each variant in the variant list and determine the type of each variant based on the properties of each variant.

[0055] The verification module 300 is used to combine all variants in the variant list based on the type of each variant to obtain an algebraic data type tree, compile the algebraic data type tree, and verify the compiled algebraic data type tree so that business processing can be performed on the algebraic data type tree that passes the verification.

[0056] Optionally, in some embodiments, the acquisition module 100 includes an identification unit and a generation unit.

[0057] The identification unit is used to identify all business differences that may occur in the target business domain in a cross-microservice scenario.

[0058] The generation unit is used to generate a list of variants based on all business differences.

[0059] Optionally, in some embodiments, the identification module 200 includes a filtering unit and a determination unit.

[0060] The filtering unit is used to filter out a first target variant that satisfies the mutually exclusive variant condition from the variant list based on the same business time, and to filter out a second target variant that satisfies the complete existence condition from the variant list, thus obtaining a second variant set.

[0061] The determination unit is used to determine the type of the variant in the first variant set as the sum type and the type of the variant in the second variant set as the product type.

[0062] Optionally, in some embodiments, it further includes a judgment unit and a reminder unit.

[0063] The judgment unit is used to determine whether a source code change event exists.

[0064] The alert unit is used to identify the new branch when there is a source code change event, and to provide a compilation error alert if the verification of the new branch fails.

[0065] Optionally, in some embodiments, the variants in the variant list include at least one of user identifier, user name, user identity information, user email address, and email verification timestamp.

[0066] It should be noted that the foregoing explanation of the embodiment of the microservice domain algebra data type construction method based on functional programming also applies to the microservice domain algebra data type construction device based on functional programming in this embodiment, and will not be repeated here.

[0067] The microservice domain algebraic data type construction device based on functional programming proposed in this application obtains a variant list of the target business domain, identifies the properties of each variant in the variant list, determines the type of each variant based on its properties, combines all variants in the variant list based on the type of each variant to obtain an algebraic data type tree, compiles the algebraic data type tree, and verifies the compiled algebraic data type tree to perform business processing. This solves the problems of scattered domain object definitions, high coupling, lack of clear boundaries, and complex and lengthy verification logic in microservices. By introducing functional programming concepts, it aggregates and encapsulates business attributes with common characteristics at a fine-grained level, effectively decoupling the domain model and intercepting illegal state errors that might otherwise be exposed at runtime during the compilation stage. This simplifies data transmission and verification processes, improves code readability and maintainability, and thus enhances the overall reliability and development efficiency of the microservice system.

[0068] Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may include: The memory 501, the processor 502, and the computer program stored on the memory 501 and capable of running on the processor 502.

[0069] When processor 502 executes the program, it implements the method for constructing microservice domain algebra data types based on functional programming provided in the above embodiments.

[0070] Furthermore, electronic devices also include: Communication interface 503 is used for communication between memory 501 and processor 502.

[0071] The memory 501 is used to store computer programs that can run on the processor 502.

[0072] The memory 501 may include high-speed RAM (Random Access Memory) memory, and may also include non-volatile memory, such as at least one disk storage.

[0073] If the memory 501, processor 502, and communication interface 503 are implemented independently, then the communication interface 503, memory 501, and processor 502 can be interconnected via a bus to complete communication between them. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0074] Optionally, in a specific implementation, if the memory 501, processor 502, and communication interface 503 are integrated on a single chip, then the memory 501, processor 502, and communication interface 503 can communicate with each other through an internal interface.

[0075] The processor 502 may be a CPU (Central Processing Unit), an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of this application.

[0076] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for constructing microservice domain algebra data types based on functional programming.

[0077] In the description of this specification, the references to "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that 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. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0078] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0079] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0080] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (FPGAs), field-programmable gate arrays (FPGAs), etc.

[0081] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0082] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.< / r> < / r> < / r> < / r> < / r>

Claims

1. A method for constructing algebraic data types in a microservice domain based on functional programming, characterized in that, Includes the following steps: Obtain a list of variants for the target business domain; Identify the properties of each variant in the variant list, and determine the type of each variant based on the properties of each variant; Based on the type of each variant, all variants in the variant list are combined to obtain an algebraic data type tree. The algebraic data type tree is then compiled and verified, so that business processing can be performed using the verified algebraic data type tree.

2. The method according to claim 1, characterized in that, The process of obtaining the variant list of the target business domain includes: Identify all business differences that may occur in the target business domain under a cross-microservice scenario; The variant list is generated based on all the business differences.

3. The method according to claim 1, characterized in that, The process of identifying the properties of each variant in the variant list and determining the type of each variant based on the properties of each variant includes: Based on the same business time, a first target variant that satisfies the mutually exclusive variant condition is selected from the variant list to obtain a first variant set, and a second target variant that satisfies the complete existence condition is selected from the variant list to obtain a second variant set; The type of the variants in the first variant set is determined to be of type S, and the type of the variants in the second variant set is determined to be of type P.E.

4. The method according to claim 1, characterized in that, Also includes: Determine if a source code change event exists; If the aforementioned source code change event exists, a new branch will be added, and a compilation error warning will be issued if the verification of the new branch fails.

5. The method according to claim 1, characterized in that, The variants in the variant list include at least one of user ID, user name, user identity information, user email address, and email verification timestamp.

6. A device for constructing algebraic data types in a microservice domain based on functional programming, characterized in that, include: The acquisition module is used to obtain a list of variants for the target business domain; An identification module is used to identify the properties of each variant in the variant list and determine the type of each variant based on the properties of each variant; The verification module is used to combine all variants in the variant list based on the type of each variant to obtain an algebraic data type tree, compile the algebraic data type tree, and verify the compiled algebraic data type tree so that business processing can be performed on the verified algebraic data type tree.

7. The apparatus according to claim 6, characterized in that, The acquisition module includes: The identification unit is used to identify all business differences that may occur in the target business domain in a cross-microservice scenario; A generation unit is used to generate the variant list based on all the business difference items.

8. The apparatus according to claim 6, characterized in that, The identification module includes: The filtering unit is used to filter out a first target variant that satisfies the mutually exclusive variant condition from the variant list based on the same business time to obtain a first variant set, and to filter out a second target variant that satisfies the complete existence condition from the variant list to obtain a second variant set; The determination unit is used to determine the type of the variant in the first variant set as a sum type and the type of the variant in the second variant set as a product type.

9. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the method for constructing microservice domain algebra data types based on functional programming as described in any one of claims 1-5.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the method for constructing microservice domain algebra data types based on functional programming as described in any one of claims 1-5.

Images