Java framework implementation method suitable for multi-party customization requirements

Abstract

The invention discloses a java framework implementation method suitable for multi-party customization demands, which comprises the following steps of: S1, constructing a customization demand flow chart, and constructing a service module according to the flow chart; s2, configuring a dependency relationship among the service modules; and S3, carrying out test verification on the constructed framework. According to the method, a java back-end service is split into a multi-module mode, so that a public service is isolated from a customized service, and the service is not distinguished by using a code version management mode of a third-party tool; the isolation is thorough and clear, the code maintenance is simple, and infinite custom business requirements can be met.

Description

Technical Field

[0001] The present invention relates to the technical field of computer back-end design, and specifically provides a method for implementing a java framework suitable for multi-party customization requirements. Background Art

[0002] When IT companies promote their software services, it is inevitable to serve multiple customers. When users choose this software service, they will put forward reasonable function changes or add certain function services in combination with their own usage requirements.

[0003] When using java to provide services, gitlub is generally used for corresponding version management, and different branches can be used to manage different codes. However, when serving too many customers, the following situations will occur: 1. Different implementations are required for the same function 2. Adding unique function modules for a certain customer is redundant for other customers 3. When serving too many customers and having too many customization requirements, it is difficult to maintain git branches, and the newly added common functions cannot be shared. Summary of the Invention

[0004] To solve the above problems, the present invention provides a method for implementing a java framework suitable for multi-party customization requirements, including the following steps: S1. Construct a flowchart of customization requirements and build service modules according to the flowchart; S2. Configure the dependency relationships between each service module; S3. Test and verify the constructed framework.

[0005] Further, in step S1, specifically: separate the public business module from the customization requirement business module, and build multiple service modules at the same time.

[0006] Further, the public business module includes: a public business specific implementation module and a public business interface definition module.

[0007] Further, the customization requirement business module includes: a customization requirement business processing module and a service startup module.

[0008] Further, the dependency relationships between each service module in step S2 are specifically: the customization requirement business processing module depends on the public business interface definition module, and both the public business interface definition module and the service startup module depend on the public business specific implementation module.

[0009] The present invention provides a method for implementing a java framework suitable for multi-party customization requirements, which has the following beneficial effects: The present invention separates the common business from the customized business by splitting the Java back-end service into multiple modules, rather than using the code version management of third-party tools to distinguish the business; the isolation is thorough and clear, and at the same time, the code maintenance is simple, and it can also cope with infinitely many customized business requirements. Brief Description of the Drawings

[0010] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on the structures shown in these drawings without creative efforts.

[0011] Figure 1 It is a flowchart of the method provided by the present invention. Detailed Embodiments

[0012] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0013] The following will describe in detail the implementation method of the present invention with reference to the drawings. The described are only some embodiments, not all embodiments. For the purpose of clarity, the representations and descriptions irrelevant to the present invention are omitted in the drawings and the description.

[0014] In order to have a clearer understanding of the technical features, objectives, and beneficial effects of the present invention, the following will provide a detailed description of the technical solutions of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all embodiments, and should not be construed as limiting the scope of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the protection scope of the present invention.

[0015] As Figure 1 shown, the present invention provides a method for implementing a Java framework suitable for multi-party customization requirements, including the following steps: S1. Construct a flowchart of customization requirements and build service modules according to the flowchart; S2. Configure the dependency relationships between the service modules; S3. Test and verify the constructed framework.

[0016] Specifically in step S1: separate the common business module from the customized requirement business module and build multiple service modules simultaneously.

[0017] The common business module includes: a specific implementation module for common business and an interface definition module for common business.

[0018] The customized requirement business module includes: a customized requirement business processing module and a service startup module.

[0019] The specific dependency relationships among the service modules in step S2 are as follows: the customized requirement business processing module depends on the common business interface definition module, and both the common business interface definition module and the service startup module depend on the common business specific implementation module.

[0020] The present invention adopts the backend multi-module method. Define interfaces in the common service module and make specific implementations in the customized module; establish a customized module to implement new functions for single-party customers; use the multi-starter method to reference different modules. Start different starters to provide services for different businesses without using multi-git branch management.

[0021] Embodiment: Build modules according to the flowchart, separate the common business and the customized business, and at the same time build multiple service startup modules: test-server: service name, service root directory: server-common: common business module, which includes server-common-impl and server-common-interface.

[0022] server-common-impl: common business specific implementation module. It can include specific implementations such as Controller, Service, Entity, and Mapper.

[0023] server-common-interface: common business interface definition module. Different implementation interfaces of the common business are defined in this module (only interface definitions are made in this module without implementation).

[0024] server-custom: custom business processing module. It can include modules such as server-custom-A and server-custom-B. The number of sub-modules is not limited under this module, and it can be increased infinitely according to the customized requirements of multiple parties.

[0025] server-custom-A: specific implementation module for the customized requirements of customer A. It can implement the interfaces defined in server-common-interface to perform different implementation logics for the same business. It can also include specific implementations of non-common functions such as Controller, Service, Entity, and Mapper.

[0026] server-custom-B: The specific implementation module for Customer B's customization requirements. It has the same functions as server-custom-A.

[0027] server-starter: The service startup module. It contains multiple sub-startup modules such as server-starter-A and server-starter-B. The number of sub-modules under this module is not restricted and can be customized according to the requirements of the software product.

[0028] server-starter-A: The service startup module for Customer A. This module needs to configure the SpringBoot startup class and reference relevant modules in the pom of this module to start different services and implement different business logic functions.

[0029] server-starter-B: The service startup module for Customer B. It is the same as server-starter-A.

[0030] Configure the dependency relationships between each module: server-common-interface depends on server-common-impl; server-custom-A depends on server-common-interface; server-custom-B depends on server-common-interface; server-starter-A depends on server-common-impl, server-common-interface, and server-custom-A; server-starter-B depends on server-common-impl, server-common-interface, and server-custom-B.

[0031] Test and verify. As shown in Table 1, conduct a connectivity test and verification on the established dependency relationships between the above modules: Table 1 Verification of the Dependency Relationships between Modules Access Path Startup Class Return Result http: / / localhost:8080 / test / common server-starter-A Do Common! http: / / localhost:8080 / test / custom server-starter-A Do Custom A Service Impl http: / / localhost:8080 / test / customA server-starter-A Custom A Controller! http: / / localhost:8080 / test / customB server-starter-A 404 http: / / localhost:8080 / test / common server-starter-B Do Common! http: / / localhost:8080 / test / custom server-starter-B Do Custom B Service Impl http: / / localhost:8080 / test / customA server-starter-B 404 http: / / localhost:8080 / test / customB server-starter-B Custom B Controller! In the present invention, the Java backend service is split into multiple modules to isolate the common business and the customized business, rather than using the code version management method of third-party tools to distinguish the business; the isolation is thorough and clear, and at the same time, the code maintenance is simple, and it can also handle infinitely many customized business requirements.

[0032] The above method of building the module is not a fixed method. If there are the same requirements among different customers, the sub-modules under server-custom can be split more finely, and the refined modules can be referenced and connected through server-starter to achieve more complex requirements.

[0033] In the Java development language, product customization business differentiation can be achieved through the multi-module and multi-starter method; the multi-module and multi-starter method can be used to replace the third-party version management method to distinguish different code implementations. This method makes the isolation of business code clearer. At the same time, there is no need to worry about the difficulties in code maintenance and version iteration caused by too many customization services; it is more flexible and stable for software products facing multiple customers.

[0034] The above description is only the preferred embodiment of the present invention. It should be understood that the present invention is not limited to the form disclosed herein, and should not be regarded as excluding other embodiments, but can be used in various other combinations, modifications, and environments, and can be changed within the scope of the concept described herein through the above teachings or the techniques or knowledge in related fields. Any changes and modifications made by those skilled in the art without departing from the spirit and scope of the present invention shall fall within the protection scope of the appended claims of the present invention.

Claims

1. A Java framework implementation method suitable for multi-party customization requirements, characterized in that: The following steps are involved: S1. Build a customized demand flow chart and build a service module based on the flow chart; S2. Configure the dependencies between various service modules; S3. Test and verify the constructed framework.

2. The Java framework implementation method applicable to multi-party customization requirements according to claim 1 is characterized in that: The step S1 specifically includes: processing the common business module and the customized demand business module separately, and building multiple building service modules at the same time.

3. The Java framework implementation method applicable to multi-party customization requirements according to claim 2 is characterized in that: The public service module includes: a public service specific implementation module and a public service interface definition module.

4. The Java framework implementation method applicable to multi-party customization requirements according to claim 2 is characterized in that: The customized demand business module includes: a customized demand business processing module and a service startup module.

5. The Java framework implementation method applicable to multi-party customization requirements according to claim 1 is characterized in that: The dependency relationship between the various service modules in step S2 is specifically as follows: the customized demand business processing module depends on the public business interface definition module, and the public business interface definition module and the service startup module both depend on the public business specific implementation module.

Images