Plug-in type software system realized based on standardization-customization function separation

Abstract

The invention discloses a plug-in software system based on standardization-customization function separation, belongs to the technical field of computers, comprises a front-end framework and a server framework, and solves the technical problems of standardization and customization collaboration, development and maintenance cost reduction and expandability enhancement in system delivery. According to the front-end architecture system and the standardization and customization decoupling method thereof provided by the invention, through a configuration system and a glue component mechanism, the thorough isolation of standard and customization functions is realized, the maintainability and delivery efficiency of the system are improved, and the customization of component dynamic loading, routing configuration automatic extraction and page jump is supported; the service end adopts an expansion point and actuator mechanism, realizes independent development and deployment of standard and customized logic, supports tenant-level expansion and plug-in mounting, constructs an open extensible ecological system, and is suitable for multi-tenant and multi-scene enterprise-level application delivery requirements.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, and in particular relates to a plug-in software system based on the separation of standardized and customized functions. Background Technology

[0002] Existing retail software often adopts a monolithic front-end project and a single back-end service, and achieves customer customization through branching, resulting in frequent code conflicts; components and routes are hard-coded and cannot be dynamically loaded according to tenants, requiring repeated packaging during the build process, which complicates operation and maintenance.

[0003] Standardization improves development efficiency, ensures system consistency, and reduces maintenance costs, thus it is widely used in the design and delivery of enterprise-level products. Customization, on the other hand, directly reflects the differentiated needs of customers' businesses and is an important means of improving customer satisfaction and product competitiveness. Especially in B2B systems, facing multiple customers, industries, and scenarios, there is a demand for both rapid delivery and precise adaptation. Traditional architectures often suffer from problems such as bloated architecture, redundant development, and high maintenance costs. The mixing of standard and customized functions results in high code coupling, affecting the stability of the main system and increasing the risk of cascading changes caused by customization.

[0004] Defects and shortcomings of existing technology: Most systems are delivered using a single code repository or unified deployment package, failing to clearly separate standard functionalities from customer-customized functionalities at the architectural level. This primarily results in the following problems: Severe module coupling: Standard functions and customized logic are mixed in the same code, making maintenance difficult and increasing the risk of changes.

[0005] Difficult to reuse: As standard functions are continuously eroded by customized logic, their reusability is greatly reduced, resulting in a large number of "customer-unique versions".

[0006] Low delivery efficiency: Each delivery requires repeated evaluation and manual stripping of customer-customized code, which affects the delivery cycle.

[0007] High testing costs: It is impossible to perform unified regression testing on standard functions, and the quality of the backbone is easily degraded due to customer customization.

[0008] Version control is chaotic: the code branches are numerous and difficult to merge, version releases are uncontrollable, and regression issues are prone to occur. Summary of the Invention

[0009] The purpose of this invention is to provide a plug-in software system based on the separation of standardized and customized functions, which solves the technical problems of coordinating standardization and customization in system delivery, reducing development and maintenance costs, and enhancing scalability.

[0010] To achieve the above objectives, the present invention adopts the following technical solution: A plug-in software system based on the separation of standardized and customized functions, including a front-end architecture and a server-side architecture; The front-end architecture includes a configuration system module, a configuration reading module, a glue component module, a plug-in mechanism module, and a custom product module; The configuration reading module is responsible for connecting to the configuration center and uses a configuration reader based on the LRU caching mechanism to uniformly obtain system-level global configurations. The glue component module is responsible for uniformly loading local and remote components, shielding the differences in component sources, and providing a standard component loading interface to perform component metadata registration, on-demand loading, and lifecycle management. The plugin mechanism module is used to uniformly manage public dependencies and perform dynamic extension, uninstallation, and hot update of public functions; Customized product modules are based on a standardized engineering foundation and support the isolation and reuse of customized functions by calling standard component libraries, customized Groovy scripts and API services through configuration and plug-in mechanisms. The server-side architecture includes a configuration service module, an extension point execution engine module, an extension client module, and an extension invocation module; The configuration service module is used to manage the configuration of extension points exposed by standard projects. It supports adding, modifying, deleting, enabling and disabling configurations, and pushes configuration changes to clients. The extension point execution engine module is deployed in standard projects and supports multiple extension execution methods based on HTTP, RPC, script engines, and SPIJar packages. It dynamically matches and calls customized extensions according to business scenarios and tenant information. The extended client module is responsible for scanning classes annotated with @preextension, @afterextension, and @overrideextension at startup, extracting metadata and registering them to the configuration service, injecting them into the Spring container, and thus completing the initialization of the extended service. The extension call module is responsible for intercepting the business method after it is marked with the @extensionpoint annotation, passing the extension parameters through the HTTP interface, routing the call to the corresponding extension service, executing the extension logic, and returning the result. The configuration service module is used to provide extension point configurations and extension scripts to the front-end architecture; The front-end architecture and the server-side architecture interact through extension points and extension configurations.

[0011] Preferably, the configuration system module is also responsible for module menu management, component list management, and operation permission management; The LRU caching mechanism of the configuration read module supports a one-minute cache invalidation policy; The glue component module supports module federation and ESModule remote component loading; The customized product module supports customized component libraries, customized page logic, and page navigation.

[0012] Preferably, the configuration service module is responsible for real-time push of configuration changes and configuration retrieval when the client starts; The extension points include the caller, the interface front-end, the main logic of the interface, and the interface back-end; The extension point execution engine module supports engineering mode and strategy design mode, and supports flexible expansion to new execution methods.

[0013] This invention presents a plug-in software system based on the separation of standardized and customized functions. It solves the technical problems of coordinating standardization and customization in system delivery, reducing development and maintenance costs, and enhancing scalability. The front-end of this invention completely decouples standardization and customization, improving system maintainability. By introducing a configuration system and glue component mechanism, it effectively isolates standard and customized functions at the architectural level, preventing code erosion, effectively reducing coupling between modules, and minimizing risks caused by changes. This significantly improves system maintainability and scalability, increases delivery efficiency, and flexibly adapts to the needs of multiple customers and scenarios. Through configuration-driven methods, it can quickly generate page structures, component layouts, and routing logic, eliminating repetitive development work and enabling one-time development and reuse across multiple projects for standard functions. This significantly shortens the delivery cycle of customized projects. It supports dynamic component loading and runtime management, optimizing front-end performance and system flexibility. A lazy loading strategy is adopted for local components, and remote components are dynamically imported through module federation or ESModule, significantly reducing the initial screen loading size.Meanwhile, a unified component lifecycle management mechanism avoids redundant loading, improves system operating efficiency, enhances function reuse and asset accumulation capabilities, and reduces development and maintenance costs. Standard engineering has accumulated a unified component library, API services, utility functions, and configuration modules, providing a stable and reliable basic framework for various customized projects. Combined with a plug-in mechanism and component recycling capabilities, it supports the long-term accumulation and reuse of business assets, improving overall team development efficiency. It supports dynamic routing analysis and automatic extraction, adapting to complex page navigation logic. Through static analysis capabilities, it automatically extracts navigation relationships between pages and manages them in a configurable manner, reducing hard-coded dependencies and enhancing the system's adaptability to complex business processes. It possesses excellent page navigation customization capabilities and supports front-end and back-end decoupling evolution. The glue component and plug-in mechanism naturally support low-code platforms for dynamic orchestration of components and pages, laying a solid foundation for the future system architecture to completely decouple from the front-end and back-end and evolve towards visual development. The server-side portion of this invention achieves complete isolation between standardization and customization. Supporting independent development and deployment, standard and customized projects are completely isolated on the server side through extension points and extension executors. Standard services can evolve independently, while customized logic is mounted through dynamic registration and executors. The development and deployment of the two do not interfere with each other, and the standard project version remains consistent, achieving efficient delivery and low-cost operation and maintenance. Since the customization capabilities are managed by the extension mechanism, standard services can maintain a single version, avoiding code branching and splitting caused by customization requirements, significantly improving system stability and reducing maintenance costs. Supporting tenant-level extension capabilities enhances system flexibility and openness. The system provides tenant-level extension registration and execution capabilities. Customers with independent development capabilities can access customized logic by registering extension services to meet differentiated business needs. It has plug-in ecosystem capabilities, supporting the mounting and running of third-party functions. The system can build a unified plug-in market, allowing third-party developers to develop functional plug-ins based on extension interfaces and mount them to the platform for operation, thereby building a flexible and open ecosystem. Attached Figure Description

[0014] Figure 1 This is the overall system architecture diagram of the present invention; Figure 2 This is a schematic diagram of the server-side architecture of the present invention; Figure 3 This is a schematic diagram of the front-end architecture of the present invention. Detailed Implementation

[0015] Depend on Figures 1-3 The illustrated plug-in software system is based on a standardized-customized functional separation, including a front-end architecture and a server-side architecture. The front-end architecture includes a configuration system module, a configuration reading module, a glue component module, a plug-in mechanism module, and a custom product module; The configuration system module, configuration reading module, glue component module, plug-in mechanism module, and customized product module communicate with each other via the Internet.

[0016] The configuration reading module is responsible for connecting to the configuration center and uses a configuration reader based on the LRU caching mechanism to uniformly obtain system-level global configurations. The glue component module is responsible for uniformly loading local and remote components, shielding the differences in component sources, and providing a standard component loading interface to perform component metadata registration, on-demand loading, and lifecycle management. The plugin mechanism module is used to uniformly manage public dependencies and perform dynamic extension, uninstallation, and hot update of public functions; Customized product modules are based on a standardized engineering foundation and support the isolation and reuse of customized functions by calling standard component libraries, customized Groovy scripts and API services through configuration and plug-in mechanisms. The configuration system module is also responsible for module menu management, component list management, and operation permission management. The LRU caching mechanism of the configuration read module supports a one-minute cache invalidation policy; The glue component module supports module federation and ESModule remote component loading; The customized product module supports customized component libraries, customized page logic, and page navigation.

[0017] The workflow of the front-end architecture is as follows: Step A1: Configure system initialization and management, specifically as follows: The configuration system acts as a bridge between "standard" and "custom" configurations, centrally managing various configuration items such as page-level component configurations, page element navigation configurations, and page navigation configurations. Through the configuration system, operations and maintenance personnel can uniformly manage module menus, component lists, and operation permissions, and support component review, editing, preview, and rollback operations, ensuring the reliability and flexibility of the configuration.

[0018] Step A2: Global configuration reading and caching, specifically: The system retrieves system-level global configurations from the configuration center via a configuration reader, employing an LRU-based caching mechanism to improve configuration read performance and reduce request pressure. Configuration content maintains backward compatibility, ensuring stable system operation.

[0019] Step A3: Dynamic loading of the adhesive component, specifically: A "glue component" system is introduced to achieve unified loading and management of local and remote components. Internally, the glue component system shields the differences in component sources, while externally it provides a unified standard component loading interface. The component loading process includes metadata registration, on-demand loading, and unified lifecycle management, ensuring efficient component rendering and resource utilization.

[0020] Step A4: Plugin mechanism support, specifically: To address the redundancy issue caused by the repeated introduction of common dependencies by multiple components, the front-end architecture of this invention integrates a plugin mechanism to uniformly manage common dependencies, enabling dynamic expansion, uninstallation, and hot updates of common functions, thereby improving system flexibility and maintenance efficiency.

[0021] Step A5: Standardize and solidify customized products, specifically: Based on our experience in ToB projects, we have abstracted a standardized engineering framework, which includes a general business component library, unified API services, common utility functions, and configuration management modules, serving as the foundation for custom product development.

[0022] Customized projects call standard modules through configuration and plugin mechanisms, realizing a development model of "standard as a service, customization with isolation", which promotes code reuse and unified operation and maintenance.

[0023] The following is an application scenario of the front-end architecture in this embodiment: Step S1: Construct a standard project framework and a customized engineering structure.

[0024] In this embodiment, the front-end system consists of standard products and customized functions. The front-end architecture first constructs a standard project framework, which includes a front-end application framework module, glue component sub-modules, customized configuration sub-modules, and extension point definition modules. These modules together constitute a scalable and reusable basic capability system.

[0025] Customization projects build upon this foundation by introducing customized pages and components to meet the differentiated needs of tenants or business scenarios.

[0026] Step S2: Load extended configuration from the configuration server front-end module.

[0027] In this embodiment, the front-end architecture sends a request to the configuration service on the server to obtain extension configuration information, including extension point registration information, extension service configuration, and extension script configuration.

[0028] The front-end architecture has local caching capabilities to support fault-tolerant loading in offline environments and to serve as the basic data source for subsequent page rendering and component loading.

[0029] Step S3: Start the front-end application framework and execute the extended configuration logic.

[0030] In this embodiment, during the initialization phase, the front-end application framework retrieves the extension scripts and extension point configurations, and dynamically determines the page structure and logical behavior by combining the current tenant context and routing path.

[0031] During this process, the front-end application framework will inject extended configurations into the standard process, forming an organic combination of standard logic and customized logic.

[0032] Step S4: Load the customized page logic and adapt it to different strategies.

[0033] In this embodiment, the front-end architecture distinguishes between loading new or old pages based on the extension point configuration. Each page is loaded driven by the custom configuration, and different custom points (such as Custom 1, Custom 2, etc.) are embedded in the page as functional placeholders, supporting flexible assembly of views and business logic, and achieving low-intrusion expansion.

[0034] Step S5: The configuration center module supports full-process configuration management.

[0035] In this embodiment, the front-end architecture manages page configuration, component configuration, project configuration and tenant configuration in a unified manner, and supports page generation and component combination through a WYSIWYG interactive method.

[0036] The front-end architecture builds an end-to-end configuration chain, which is a key support for achieving standardization and customization collaboration in front-end engineering.

[0037] Step S6: Load the component and render the page through the glue component submodule.

[0038] In this embodiment, the front-end architecture uses the glue component submodule to perform dynamic loading and lifecycle management of components.

[0039] The glue component submodule shields the technical differences between local and remote components, providing a unified registration, loading, rendering, and caching mechanism, effectively supporting module federation and remote hot update capabilities of low-code components.

[0040] Step S7: Configure the read and cache module to optimize runtime performance.

[0041] In this embodiment, the front-end architecture adopts an LRU caching mechanism and sets a 1-minute expiration policy to ensure that the timeliness of configuration information and access efficiency are both taken into account, providing stable performance support for high-frequency page access scenarios.

[0042] The server-side architecture includes a configuration service module, an extension point execution engine module, an extension client module, and an extension invocation module; the configuration service module, extension point execution engine module, extension client module, and extension invocation module communicate with each other via the Internet.

[0043] The configuration service module is used to manage the configuration of extension points exposed by standard projects. It supports adding, modifying, deleting, enabling and disabling configurations, and pushes configuration changes to clients. The extension point execution engine module is deployed in standard projects and supports multiple extension execution methods based on HTTP, RPC, script engines, and SPIJar packages. It dynamically matches and calls customized extensions according to business scenarios and tenant information. The extended client module is responsible for scanning classes annotated with @preextension, @afterextension, and @overrideextension at startup, extracting metadata and registering them to the configuration service, injecting them into the Spring container, and thus completing the initialization of the extended service. The extension call module is responsible for intercepting the business method after it is marked with the @extensionpoint annotation, passing the extension parameters through the HTTP interface, routing the call to the corresponding extension service, executing the extension logic, and returning the result. In this embodiment, a custom Groovy script can also be executed through the built-in script engine to achieve customized extension logic. The configuration service module is used to provide extension point configurations and extension scripts to the front-end architecture; The front-end architecture and the server-side architecture interact through extension points and extension configurations.

[0044] The configuration service module is responsible for real-time push of configuration changes and configuration retrieval when the client starts. The extension points include the caller, the interface front-end, the main logic of the interface, and the interface back-end; The extension point execution engine module supports engineering mode and strategy design mode, and supports flexible expansion to new execution methods.

[0045] The server-side workflow is as follows: Step B1: Extension point and extension configuration management, specifically including: The configuration service module is responsible for managing the configuration of extension points exposed by standard projects and the specific extension configurations for extension points. It supports adding, modifying, deleting, and enabling / disabling extension points and extension configurations.

[0046] The configuration service module enables real-time push of configuration changes and configuration retrieval by clients, ensuring dynamic consistency of system configuration.

[0047] Step B2: Extension point execution engine mechanism, specifically including: Standard projects expose multiple extension points in core business processes, such as callers, interface front-ends, interface main logic, and interface back-ends. The extension point execution engine dynamically matches the corresponding customized extensions based on business scenarios and tenant information.

[0048] The execution engine supports multiple execution methods, providing HTTP, RPC executors, and script engines by default, and can be extended to an SPI-based Jar package executor to meet different extension implementation needs.

[0049] In this embodiment, the extension point execution engine serves as a bridge connecting standard business processes and customized logic, and its core structure includes: The extension point registration manager is responsible for registering and verifying extension metadata; The executor adaptation layer supports multiple calling modes, with default implementations including HTTP caller, RPC caller, and script engine, and reserves space for SPI plugin extension; The router is used to dynamically select the appropriate extended service based on extensionName, tenant ID, and service context. The execution caching module is used to manage the cache of extended service Bean instances and optimize performance. Call tracing and exception handlers are used to record call chains, capture exception information, and ensure the stability of the extension.

[0050] Step B3: Startup and registration process, specifically including: During system startup, the extension client scans classes annotated with @preextension, @afterextension, and @overrideextension, extracts annotation metadata, and registers it with the configuration server.

[0051] After the server confirms successful registration, the client injects the extended class into the Spring container to complete the initialization of the extended service.

[0052] Step B4: Extend the call flow, specifically including: At runtime, business methods annotated with @extensionpoint will be intercepted by the extension client.

[0053] The client passes extension configuration parameters to the extension execution engine via an HTTP interface. The engine routes requests based on the extension name, calls the corresponding extension service bean, executes the extension logic, and finally returns the extension result to the caller. This enables dynamic extension and customization of business functions, or executes customized Groovy scripts through the built-in script engine to achieve extended and customized logic.

[0054] Step B5: Collaboration between standard and custom projects, specifically including: Standard and customized projects share the aforementioned extension mechanism, and their startup and invocation processes are consistent, ensuring that system functions are dynamically injected with customized logic through extension points to meet the business needs of different customers, while ensuring the stability and maintainability of the core system.

[0055] The following is the operational flow of the server-side architecture in standard and custom projects: moana-server: Corresponds to the configuration service module, responsible for the registration, management and push functions of extension point configuration and extension implementation configuration, serving as the configuration center; moana-extension-client: This corresponds to the extension client module, which is responsible for scanning, registering, injecting extension classes, and actually calling the extension logic. It mainly runs in custom projects. moana-client: Corresponds to the extended call module, located in the standard project. It is responsible for intercepting the extended point in the standard business process and calling the extended service defined in the extended client module through a unified interface. Executor components (such as HTTP / RPC executors, script engines, SPI Jar executors): collectively referred to as extension point execution engine modules, are responsible for distributing extension requests to the corresponding extension services according to the definition and configuration of extension points, and support multiple execution protocols.

[0056] The standard service process involves the following steps: Start-up phase: Step Y1: During the startup phase, the moana-extension-client module scans all extension classes annotated with @PreExtension, @AfterExtension, or @OverrideExtension; Step Y2: Extract the annotation class meta information and register it to the moana-server module as extension point metadata; Step Y3: The moana-server module confirms successful metadata registration and returns a confirmation result; Step Y4: The moana-extension-client module injects the above-mentioned annotation classes into the Spring container, which need to implement the corresponding extension interface (such as Pre, After or Override type). Step Y5: The Spring container completes the injection and initialization of the extension class and notifies the extension client module.

[0057] Execution phase: Step Y6: The moana-client module intercepts methods annotated with @ExtensionPoint in the business logic; Step Y7: Forward the call request containing extended configuration parameters (such as extensionName) to the moana-extension-client module through the / extension / gateway interface; Step Y8: The moana-extension-client module routes to the corresponding extension service based on the extension name; Step Y9: Obtain the matching extended service bean instance from the Spring container; Step Y10: The Spring container returns the instance to the extended client module; Step Y11: The moana-extension-client module calls the target method in the extension bean to execute custom logic; Step Y12: The extended service execution is complete and the processing result is returned; Step Y13: The extended client module returns the result to the caller (moana-client); Step Y14: The final result is sent to the user or the upper-layer service.

[0058] Customized service processes are identical to standard service processes in terms of startup and invocation logic, but they provide independently developed extended service logic, which is physically decoupled from the standard project implementation and deployed independently.

[0059] The difference between the customized service process and the standard service process is as follows: Although the scanning and registration process for annotation classes is the same, it is the "custom implementation class" that is registered; Extended service beans are implemented by custom projects and dynamically loaded and executed within standard processes; The extension point execution engine has dynamic selection capabilities, matching corresponding customized implementations based on tenant context or business identifiers; It supports remote invocation of customized services and script engines via HTTP / RPC interfaces, or local integration via SPI plugins.

[0060] The configuration service module in the front-end architecture and the server-side architecture collaborates through network communication.

[0061] During the application framework startup phase, the front-end architecture pulls extension point configurations and extension scripts from the configuration service module to drive the loading of page structure and component logic.

[0062] The server-side architecture uses extension points defined in the standard project to call registered custom services through the extension point execution engine, thereby enabling dynamic expansion of business logic.

[0063] The front-end and server are decoupled and linked by extension points, supporting low-intrusion customization and dynamic rendering of interface and execution logic according to tenant dimensions.

[0064] In this embodiment, the integrated dynamic expansion capability of the server and the front end is realized through the configuration center and extension point mechanism. The front end loads components and pages based on the configuration, and the server calls specific customized logic through the extension execution engine. Together, they ensure that the business process is configurable, pluggable, and isolable.

[0065] This invention presents a plug-in software system based on the separation of standardized and customized functions. It solves the technical problems of coordinating standardization and customization in system delivery, reducing development and maintenance costs, and enhancing scalability. The front-end of this invention completely decouples standardization and customization, improving system maintainability. By introducing a configuration system and glue component mechanism, it effectively isolates standard and customized functions at the architectural level, preventing code erosion, effectively reducing coupling between modules, and minimizing risks caused by changes. This significantly improves system maintainability and scalability, increases delivery efficiency, and flexibly adapts to the needs of multiple customers and scenarios. Through configuration-driven methods, it can quickly generate page structures, component layouts, and routing logic, eliminating repetitive development work and enabling one-time development and reuse across multiple projects for standard functions. This significantly shortens the delivery cycle of customized projects. It supports dynamic component loading and runtime management, optimizing front-end performance and system flexibility. A lazy loading strategy is adopted for local components, and remote components are dynamically imported through module federation or ESModule, significantly reducing the initial screen loading size.Meanwhile, a unified component lifecycle management mechanism avoids redundant loading, improves system operating efficiency, enhances function reuse and asset accumulation capabilities, and reduces development and maintenance costs. Standard engineering has accumulated a unified component library, API services, utility functions, and configuration modules, providing a stable and reliable basic framework for various customized projects. Combined with a plug-in mechanism and component recycling capabilities, it supports the long-term accumulation and reuse of business assets, improving overall team development efficiency. It supports dynamic routing analysis and automatic extraction, adapting to complex page navigation logic. Through static analysis capabilities, it automatically extracts navigation relationships between pages and manages them in a configurable manner, reducing hard-coded dependencies and enhancing the system's adaptability to complex business processes. It possesses excellent page navigation customization capabilities and supports front-end and back-end decoupling evolution. The glue component and plug-in mechanism naturally support low-code platforms for dynamic orchestration of components and pages, laying a solid foundation for the future system architecture to completely decouple from the front-end and back-end and evolve towards visual development. The server-side portion of this invention achieves complete isolation between standardization and customization. Supporting independent development and deployment, standard and customized projects are completely isolated on the server side through extension points and extension executors. Standard services can evolve independently, while customized logic is mounted through dynamic registration and executors. The development and deployment of the two do not interfere with each other, and the standard project version remains consistent, achieving efficient delivery and low-cost operation and maintenance. Since the customization capabilities are managed by the extension mechanism, standard services can maintain a single version, avoiding code branching and splitting caused by customization requirements, significantly improving system stability and reducing maintenance costs. Supporting tenant-level extension capabilities enhances system flexibility and openness. The system provides tenant-level extension registration and execution capabilities. Customers with independent development capabilities can access customized logic by registering extension services to meet differentiated business needs. It has plug-in ecosystem capabilities, supporting the mounting and running of third-party functions. The system can build a unified plug-in market, allowing third-party developers to develop functional plug-ins based on extension interfaces and mount them to the platform for operation, thereby building a flexible and open ecosystem.

Claims

1. A plug-in software system based on the separation of standardized and customized functions, characterized in that: This includes front-end architecture and server-side architecture; The front-end architecture includes a configuration system module, a configuration reading module, a glue component module, a plug-in mechanism module, and a custom product module; The configuration system module is responsible for module menu management, component list management, and operation permission management. The configuration reading module is responsible for connecting to the configuration center and uses a configuration reader based on the LRU caching mechanism to uniformly obtain system-level global configurations. The glue component module is responsible for uniformly loading local and remote components, shielding the differences in component sources, and providing a standard component loading interface to perform component metadata registration, on-demand loading, and lifecycle management. The plugin mechanism module is used to uniformly manage public dependencies and perform dynamic extension, uninstallation, and hot update of public functions; Customized product modules are based on a standardized engineering foundation and support the isolation and reuse of customized functions by calling standard component libraries, customized Groovy scripts and API services through configuration and plug-in mechanisms. The server-side architecture includes a configuration service module, an extension point execution engine module, an extension client module, and an extension invocation module; The configuration service module is used to manage the configuration of extension points exposed by standard projects. It supports adding, modifying, deleting, enabling and disabling configurations, and pushes configuration changes to clients. The extension point execution engine module is deployed in standard projects and supports multiple extension execution methods based on HTTP, RPC, script engines, and SPIJar packages. It dynamically matches and calls customized extensions according to business scenarios and tenant information. The extended client module is responsible for scanning classes annotated with @preextension, @afterextension, and @overrideextension at startup, extracting metadata and registering them to the configuration service, injecting them into the Spring container, and thus completing the initialization of the extended service. The extension call module is responsible for intercepting the business method after it is marked with the @extensionpoint annotation, passing the extension parameters through the HTTP interface, routing the call to the corresponding extension service, executing the extension logic, and returning the result. The configuration service module is used to provide extension point configurations and extension scripts to the front-end architecture; The front-end architecture and the server-side architecture interact through extension points and extension configurations.

2. The plug-in software system based on standardized-customized functional separation as described in claim 1, characterized in that: The LRU caching mechanism of the configuration read module supports a one-minute cache invalidation policy; The glue component module supports module federation and ESModule remote component loading; The customized product module supports customized component libraries, customized page logic, and page navigation.

3. A plug-in software system based on standardized-customized functional separation as described in claim 1, characterized in that: The configuration service module is responsible for real-time push of configuration changes and configuration retrieval when the client starts. The extension points include the caller, the interface front-end, the interface main logic, and the interface back-end; The extension point execution engine module supports engineering mode and strategy design mode, and supports flexible extension of new execution methods.

Images