Software Modular Intelligent Design Platform and Implementation Method Based on Microservice Architecture

Abstract

This invention discloses a software modular intelligent design platform and implementation method based on microservice architecture, involving the interdisciplinary fields of microservice architecture design and accounting software engineering. This method relies on accounting knowledge graphs for semantic parsing and compliance completion, drives service unit partitioning based on aggregation coupling degree, completes precise component adaptation by combining cohesion parameters, performs full-dimensional verification and hierarchical processing using a built-in compliance rule library, and finally covers all stages of development, testing, deployment, iteration, and decommissioning through full-process baseline control. This invention automatically partitions microservices through knowledge graphs and weighted calculations, eliminating human bias and ensuring stable accounting reconciliation; intelligently selects and matches layered components to improve the reusability of financial and tax components and shorten the development cycle; pre-verifies risks using a built-in compliance library, and provides a full-process control link to ensure data integrity and traceability, reduce operation and maintenance costs, adapt to multi-business architecture requirements, and improve the standardization and intelligence level of accounting software architecture design.

Description

Technical Field

[0001] This invention relates to the interdisciplinary field of microservice architecture design and accounting software engineering, specifically to a software modular intelligent design platform and implementation method based on microservice architecture. Background Technology

[0002] As digital transformation continues, the financial and accounting management systems of various business entities are gradually upgrading to online platforms. Financial and accounting software, which handles accounting, tax declaration, fund management, and audit archiving, has become a core carrier for enterprise management, with its software architecture undergoing three iterations. Early financial and accounting software generally adopted a monolithic architecture, integrating all business logic into a single project, relying only on code directories for shallow module differentiation, and lacking independently running service units. Subsequently, the industry introduced traditional SOA architecture, relying on a service bus to achieve coarse-grained business decomposition and cross-module data interaction. Currently, the mainstream development model is a general microservice architecture, achieving business decoupling and phased iteration by splitting and deploying independent units. Financial and accounting operations possess unique attributes distinct from general-purpose software. Accounting data has fixed reconciliation logic, and business processes are subject to multiple constraints from accounting standards, tax regulations, and enterprise internal controls. Furthermore, group-type business entities have complex business needs due to multiple branches, multiple industry formats, and differentiated tax systems. Existing microservice design tools on the market are only for building standardized templates for general information software. They do not create exclusive intelligent design logic for the rigid constraints and multi-layered relationships of accounting and finance business. The traditional manual architecture building mode is difficult to match the current large-scale and standardized accounting and finance software development needs. The industry has a long-term need for automated modular design solutions that are adapted to accounting and finance scenarios.

[0003] Existing microservice architectures for accounting software suffer from multiple layers of underlying technical deficiencies, making it difficult to adapt to the specific constraints of accounting operations. First, there is a lack of standardized, automated decision-making logic for business module division. Module boundaries rely entirely on the subjective definition of developers' professional experience. The decomposition process only considers surface-level business functions, failing to identify the accounting reconciliation and compliance domain affiliations between business nodes. This easily leads to nested business logic across services, and subsequent iterations adjusting any business unit can disrupt the overall accounting data balance, causing irreversible business problems such as data validation failures. Second, general-purpose architecture tools only provide general technical components, lacking standardized business components adapted to tax scenarios. High-frequency accounting fundamentals such as tax calculation, double-entry bookkeeping, and audit traceability require repeated development by the R&D team, lacking a complete component matching and reuse chain, thus lengthening the overall development cycle. Third, compliance verification is only implemented during project testing and deployment phases. The architecture design phase lacks a linked rule verification engine, making it impossible to identify compliance defects such as account settings, tax calculation logic, and data retention periods in advance. Once problems are discovered, large-scale architecture refactoring is required. Fourth, existing tools only cover a single aspect of architecture design and have not established a unified management benchmark covering development, testing, deployment, iteration, and decommissioning. Module versions, interface specifications, and data change records lack unified traceability standards. At the same time, they cannot adaptively adjust the service granularity according to the enterprise's business volume and concurrency requirements, making it difficult to meet the differentiated construction needs of lightweight systems for small and micro enterprises and complex management and control platforms for large groups. Summary of the Invention

[0004] The purpose of this invention is to overcome the shortcomings of existing technologies and provide a software modular intelligent design platform and implementation method based on microservice architecture. This method achieves full-process intelligentization from requirement input to architecture solution generation through five core steps: requirement parsing and matching, node aggregation and partitioning, component adaptation and assembly, compliance verification output, and full-chain management implementation. This includes using accounting and business knowledge graphs for semantic parsing and compliance completion, driving microservice unit partitioning through a comprehensive aggregation coupling degree formula, and calculating comprehensive adaptation and fit with cohesion parameters to complete precise component assembly. At the same time, a built-in financial and tax compliance rule library is used to perform full-dimensional verification and hierarchical processing.

[0005] To solve the above-mentioned technical problems, this invention provides the following technical solution: a software modular intelligent design platform and implementation method based on microservice architecture, wherein the specific steps of the method are as follows: S100, Requirements Analysis and Matching: Receives four types of requirement files for accounting software: functional requirements, compliance requirements, performance requirements, and deployment requirements. After semantic analysis, it breaks down business nodes, data flow paths, and compliance constraints, and performs bidirectional matching with the built-in accounting business knowledge graph to eliminate non-compliant requirement items, complete accounting control rules, and generate a standardized structured requirement model. S200, Node Aggregation and Partitioning: Retrieve all business nodes in the structured requirement model, calculate the comprehensive aggregation coupling degree of each node pair and complete node aggregation, optimize the partitioning boundary in combination with accounting business boundary rules, verify the single responsibility of each service unit, and output the service partitioning scheme and the average cohesion parameter of each service. S300, Component Adaptation and Assembly: Retrieve the service partitioning scheme and average cohesion parameters, identify the characteristics of each service scenario, calculate the comprehensive adaptation and fit of candidate components, select the optimal components to complete the architecture docking and dependency configuration, adaptively adjust the service granularity, and generate the initial draft of the microservice architecture. S400 Compliance Verification Output: Retrieves the initial draft of the microservice architecture, calls the built-in financial and tax compliance rule library to perform full-dimensional compliance verification, performs graded processing according to risk level, supports manual fine-tuning and synchronous review, solidifies the solution after verification, and generates a complete set of standardized implementation documents; S500, full-chain management implementation: retrieve the fixed architecture solution, initialize the full-process management baseline, execute corresponding management actions in the five stages of development, testing, deployment, iteration, and decommissioning, and retain operation and data change records throughout the process.

[0006] Furthermore, the aforementioned requirements documents are written documents that embody the requirements for the construction of accounting projects. These documents encompass two types of formats: offline prepared documents and online input forms. The functional requirements documents include the business operation processes, interaction logic, and data input and output content corresponding to general ledger accounting, expense reimbursement, tax declaration, fund management, and file archiving. The compliance requirements documents include provisions of financial and tax regulations, internal control approval clauses, data security retention requirements, and constraints on the separation of accounting responsibilities. The performance requirements documents include relevant indicators such as concurrent processing limits, data response time, batch accounting processing rate, and storage capacity thresholds. The deployment requirements documents include relevant content on hardware configuration, network transmission bandwidth, multi-branch deployment methods, and scheduled task configuration.

[0007] Furthermore, the process involves extracting key fields from the text of the requirements document segment by segment, breaking down independent business nodes based on accounting business actions, distinguishing various independent operation units such as document entry, voucher generation, tax calculation, and file retention, and marking the input and output objects of each node; sorting out the data flow path based on the order of business within the document, marking the data's starting carrier, intermediate transmission links, final storage location, and cross-business flow direction; extracting relevant financial and tax and internal control-related limiting statements from the document as compliance constraints, dividing them into four categories of constraint items: access control, accounting reconciliation, data retention, and approval process, and simultaneously marking the effective business scope corresponding to each constraint.

[0008] Furthermore, the accounting and finance business knowledge graph uses natural language processing technology to analyze accounting standards, tax regulations, corporate financial systems, and historical business data to construct a database. It extracts four core entities: accounting subjects, business types, tax calculation rules, and audit nodes, and sorts out three types of relationships: reconciliation, flow, and constraint. The two-way matching process verifies the compliance of each business node in the requirements one by one, marks and removes requirements that violate financial and tax supervision requirements, and supplements the missing accounting control rules and data retention requirements in the requirements based on the industry business standards in the accounting and finance business knowledge graph. The generated structured requirement model contains five types of data: a complete list of business nodes, node attribute definitions, data flow links, compliance constraint rules, and performance indicator requirements. All data has been standardized and converted.

[0009] Furthermore, the overall aggregation coupling degree is expressed by the formula: The calculation shows that, in the formula The overall aggregation coupling degree between business node i and business node j, with a value range of [0,1]; The degree of reconciliation between the two nodes is denoted by , with a value range of [0,1], reflecting the closeness of the correspondence between accounting subjects, the balance of debit and credit entries, and the verification of data reconciliation. This is the reconciliation rigidity enhancement coefficient, with a value range of 1.4 to 1.8. It is used to amplify the association weight of strong reconciliation nodes and reflect the rigid binding characteristics of the reconciliation relationship between financial and accounting records. The data dependency relationship between two nodes reflects the degree of dependency in data reading and writing, field mapping, and cross-node flow; The degree of business process correlation between two nodes reflects the tightness of the connection between the preceding and following nodes, the temporal dependence, and the triggering linkage in the business link; The frequency correlation between the two nodes reflects the frequency of mutual calls and the proportion of linked triggering business. , , , These are the weighting coefficients for the four dimensions, with values ​​of 0.4, 0.3, 0.2, and 0.1 respectively. The compliance domain consistency decay factor ranges from 0 to 1. It is 1 when the two nodes belong to the same financial and tax compliance regulatory domain, and 0.3 to 0.6 when they belong to different compliance regulatory domains. Specifically, it is 0.5 when they belong to different industry regulatory domains, 0.4 when they belong to different tax type regulatory domains, and 0.3 when they belong to different industry and different tax type regulatory domains.

[0010] Furthermore, the service partitioning scheme records complete textual data of all aggregated service units, including the business category to which each service unit belongs, a list of all aggregated business nodes, the internal data flow of the unit, a list of external interaction nodes of the unit, the basis for internal control isolation partitioning, and an explanation of accounting reconciliation. It also marks the independent business scope of each service unit and the rules for cross-unit interaction. The average cohesion parameter of each service is the average value of the pairwise aggregation coupling degree of all business nodes in the corresponding single service unit. The parameter is accompanied by the original calculation details of node coupling degree, the marking of highly coupled nodes, and the comparison value of the parameter before and after boundary adjustment, which can intuitively reflect the tightness of business association within a single service and serve as the basic input basis for the subsequent component adaptation process.

[0011] Furthermore, the overall fit and suitability of the candidate components is determined by the formula... The calculation yields the following result: The comprehensive fit between the target microservice unit m and the candidate component k is defined, with a value range of [0,2]. Industry compatibility reflects the degree to which the component's business logic adapts to the accounting and financial characteristics of the industry to which the unit belongs; For compliance adaptation matching degree, it reflects the degree of coverage and matching between the component's financial and tax compliance rules and the unit's compliance requirements, with a value range of [0,1]. Performance matching degree reflects the degree of matching between the component's concurrent carrying capacity and the unit's business volume; To ensure compatibility and compatibility, this reflects the degree of compatibility between the component and the unit's technology stack and interface specifications; , , , These are the weighting coefficients for the four dimensions, with values ​​of 0.4, 0.3, 0.15, and 0.15 respectively. is the average cohesion of the microservice unit m, obtained by the rigid clustering algorithm of accounting; r is the cohesion gain coefficient, with a value ranging from 0.3 to 0.5, used to achieve positive linkage between splitting quality and adaptation accuracy; The compliance rule matching correction coefficient has a value range of (0, 1.2], and its value selection rule is: when the compliance rules of candidate component k completely cover the compliance requirements of microservice unit m, The value is 1.2; 1.0 when the coverage reaches 80% or more; 0.9 when the coverage reaches 60% to 80%; and 0.8 when the coverage is less than 60%.

[0012] Furthermore, the component adaptation and assembly step sorts all candidate components from highest to lowest based on their overall compatibility score, eliminates candidate components with a compatibility score below 0.85, and selects the top-ranked component as the matching component for the corresponding business group. Based on the component's built-in data interaction interface and data read / write specifications, the architecture of the components is integrated, the order of data calls between components is determined, and the required dependency interfaces, data fields, and call triggering conditions for cross-component data transfer are registered, fully recording all dependency relationships. After completing component matching and dependency configuration, the business coverage of each group is fine-tuned based on the average cohesion parameter of each group to achieve adaptive adjustment of service granularity. The matching component list, component connection links, component dependencies, business coverage, and granularity adjustment records for each group are summarized and integrated into a complete text carrier, which is the initial draft of the microservice architecture.

[0013] Furthermore, the aforementioned financial and tax compliance rule base is a standardized collection of financial and accounting compliance judgment items, covering accounting standards rules, tax control rules, and enterprise internal control audit rules. The accounting standards rules include account matching specifications, debit and credit balance requirements, voucher preparation standards, and period-end carry-forward constraints. The tax control rules include tax calculation standards, input tax deduction limits, declaration data verification, and tax-related document retention time limits. The enterprise internal control audit rules include operation traceability requirements, accounting modification traceability markers, business responsibility isolation, and cross-business data verification standards. The rule base allows for the addition, deletion, and updating of various constraint items.

[0014] Furthermore, the comprehensive verification covers five dimensions: accounting subject standardization, accounting consistency, tax calculation logic legality, data retention compliance, and interface data security. Risk levels are divided into three levels: high-risk, medium-risk, and low-risk. High-risk risks directly block the saving and export of solutions, preventing the solutions from entering the next stage. Medium-risk risks mark the problem location and optimization direction, and push them to designers for confirmation and rectification. Low-risk risks are automatically standardized and corrected by the system, and modification records are retained. Manual adjustment channels are opened for marked risk content. Each time an architectural content modification is completed, a second comprehensive review is automatically triggered until no new risk markings are added.

[0015] Furthermore, the three levels of risk—high-risk, medium-risk, and low-risk—are classified based on the degree of regulatory penalties corresponding to the violations, the scope of impact of accounting distortions, and the severity of consequences of internal control failures. High-risk issues include violations of mandatory tax regulations, overall imbalance of accounting data, and failure to separate funds from tax-related business permissions. Medium-risk issues include only partial business processes that do not comply with internal control rules, deviations in tax calculation parameter values, and lack of basic verification items for cross-business data interaction that will not cause major tax errors. Low-risk issues include only minor flaws such as field naming, storage duration, and log format that do not affect accounting and tax calculation results.

[0016] Furthermore, the solidified solution involves locking in all aspects of the architecture—business divisions, component combinations, data interaction links, and compliance constraint configurations—that have been repeatedly reviewed and deemed risk-free, prohibiting any unauthorized modifications. A complete set of standardized implementation documents is automatically generated based on the solidified solution, extracting various information in sequence: detailed business divisions, component adaptation lists, component dependency configurations, full-process data flow paths, compliance verification records, and risk rectification ledgers. The extracted content is then filled into four types of document templates: architecture description documents, business implementation documents, component configuration files, and compliance verification reports. The text format and data annotation rules are standardized, and all documents are compiled, packaged, and archived to form a complete set of standardized implementation documents that can be directly used for project implementation.

[0017] Furthermore, the execution of corresponding control actions relies on the initialized full-process control baseline, covering five stages: development, testing, deployment, iteration, and decommissioning. During the development stage, the scope of component development and data interface standards are constrained by the fixed architecture scheme, and new business logic is verified to match the financial and tax control baseline. During the testing stage, specific tests for accounting and tax-related scenarios are conducted according to compliance verification standards to verify the consistency of component interaction data. During the deployment stage, hardware configuration and data storage retention rules are checked against the control baseline to confirm that deployment parameters meet compliance requirements. During the iteration stage, compliance re-checks are automatically initiated after each adjustment to business division and component configuration, and the control baseline is updated and changes are retained synchronously. During the decommissioning stage, historical accounting data and operation records are fully archived, and data sealing is completed according to regulatory requirements. All control actions at each stage use the initialized full-process control baseline as a unified judgment standard.

[0018] Compared with existing technologies, this software modular intelligent design platform and implementation method based on microservice architecture has the following advantages: I. This invention automatically partitions microservice modules using a knowledge graph of accounting and finance business combined with multi-dimensional weighted calculation logic. It leverages the inherent multi-layered relationships within accounting and finance to cluster business nodes, and simultaneously optimizes service partitioning boundaries using industry business boundary rules, eliminating experience-based biases caused by manual partitioning from the ground up. The entire partitioning logic aligns with the strong accounting relationships and responsibility isolation inherent in accounting systems, naturally ensuring that each service unit has a single responsibility, reducing cross-module business logic nesting, and preventing business risks such as data imbalance and invalid reconciliation caused by subsequent iterations and modifications. The standardized intelligent partitioning model unifies the microservice partitioning standards for accounting and finance software, reduces internal coupling, minimizes the impact of single-point failures, improves overall operational stability, and simplifies the operational and maintenance difficulties of later iterations and troubleshooting, adapting to the differentiated accounting and finance business architecture needs of multiple business formats and subsidiaries.

[0019] Second, this invention achieves intelligent component selection through a layered accounting-specific component system coupled with scenario-based matching logic. It utilizes multi-dimensional adaptation judgment rules to screen standardized components that fit business scenarios, compliance requirements, and technical architecture, reducing repetitive development of basic accounting business logic, increasing the reuse rate of general and tax-specific components, and shortening the overall software development cycle. A pre-verification link is built upon a built-in standardized tax compliance rule library, covering multi-dimensional compliance reviews such as account categories, tax calculation, data retention, and access control during the architecture design phase. This proactively identifies and addresses various tax risks, avoiding large-scale rework and rectification after deployment. A comprehensive end-to-end management link is provided, unifying the management judgment benchmarks at each stage, retaining records of all operations and data changes, ensuring the integrity and traceability of accounting data, and simultaneously standardizing the entire process of version iteration, deployment, and decommissioning, reducing long-term operation and maintenance costs.

[0020] Other advantages, objectives and features of the invention will be set forth in part in the description which follows, and in part will be apparent to those skilled in the art from the following examination or study, or may be learned from the practice of the invention. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0022] Figure 1 A framework diagram of a software modular intelligent design platform and implementation method based on microservice architecture; Figure 2 A flowchart illustrating a software modular intelligent design platform and its implementation method based on a microservice architecture; Figure 3 A flowchart for the compliance verification output steps. Detailed Implementation

[0023] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structures, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided below.

[0024] Example 1: This implementation example focuses on the development of a new financial control system for a medium-sized manufacturing group. The group comprises multiple production and sales subsidiaries. Previously, their financial instruments were fragmented and independent, resulting in inefficient cross-entity reconciliation, potential logical discrepancies in tax declarations, lengthy data aggregation cycles, and inconsistent internal controls and tax standards across subsidiaries. The overall project objective is to establish a unified group financial and accounting control platform that strictly adheres to current corporate accounting standards and VAT administration regulations. This platform will enable independent accounting by subsidiaries and automatic aggregation across the group, ensuring accurate reconciliation of accounts, full traceability of tax-related transactions, and support for long-term business expansion and tax policy iterations, while reducing overall operation and maintenance costs. Figure 1 As shown.

[0025] The first step is to analyze and match requirements. The platform uniformly imports four types of requirement documents for the project. Functional requirements cover all business processes, interaction logic, and data entry and exit rules for general ledger accounting, expense reimbursement, tax declaration, fund management, and file archiving. Compliance requirements include financial and tax regulations, corporate internal control approvals, data retention time limits, and constraints related to the separation of accounting responsibilities. Performance requirements specify the system's concurrency limit, response time, batch accounting processing speed, and storage threshold indicators. Deployment requirements specify hardware configuration, network bandwidth, multi-branch deployment mode, and scheduled task rules. The platform leverages semantic parsing technology to extract all key fields from the text, dividing it into independent business nodes based on accounting and financial operations. It differentiates operational units such as document entry, voucher generation, tax calculation, and file retention, labeling the input and output objects of each node. Based on the sequence of business operations, it outlines the complete data flow path, marking the data's initial carrier, intermediate transmission links, final storage location, and cross-entity flow direction. It extracts financial and tax-related and internal control constraints as compliance measures, categorizing items into four types: access control, accounting reconciliation, data retention, and approval processes, and labeling their corresponding effective business scope. This standardizes requirement descriptions, avoiding design rework caused by ambiguous requirement expressions from the outset. The system utilizes a built-in accounting and financial business knowledge graph for bidirectional matching. This graph, built using natural language processing to analyze accounting standards, tax regulations, corporate financial systems, and historical business data, extracts four entities: accounting subjects, business types, tax calculation rules, and audit nodes, establishing three types of relationships: reconciliation, flow, and constraints. The matching process meticulously checks the compliance of all business nodes, identifying and eliminating requirements that violate financial and tax regulations. It supplements missing accounting control and data retention rules within the requirements based on industry standards, proactively eliminating compliance loopholes and business logic deficiencies at the requirements stage. The final output is a standardized, structured requirements model that fully encompasses five categories of standardized data: a list of business nodes, node attributes, data flow links, compliance constraints, and performance indicators. This model can be directly integrated into the next stage without requiring manual secondary processing and conversion.

[0026] The second step involves node aggregation and partitioning. The platform retrieves all business nodes within the structured requirement model and calculates the overall aggregation coupling degree using the following formula: Extract all business nodes i and j within the project sequentially, and collect data one by one. Accounting reconciliation correlation Data dependency correlation Business process relevance Four metrics, including call frequency and relevance, are assigned uniform weights. =0.4、 =0.3、 =0.2、 =0.1, stiffness enhancement coefficient Select interval 1.6, then determine whether the two nodes belong to the same compliance regulatory domain. Assigning a value of 1, across compliance domains Select values ​​in the range of 0.3 to 0.6, substitute all parameters into the formula, and calculate the comprehensive aggregation coupling degree of each group of nodes in batches. Based on the calculation results, highly correlated nodes are clustered and aggregated. The calculation dimensions cover accounting reconciliation, data dependency, business process, and call frequency correlation. Simultaneously, the rigid characteristics of accounting reconciliation and compliance domain consistency judgment standards are incorporated to accurately distinguish between strongly bound accounting nodes and weakly correlated ordinary business nodes, preventing accounting nodes with strong reconciliation relationships from being split into different service units. After initial node aggregation, the boundaries of each service unit are optimized based on accounting business boundary rules. The single responsibility of each service unit is verified item by item, and clustering results with cross-unit business logic nesting and unreasonable boundary divisions are adjusted. This ensures that each service unit carries an independent and complete business scope, reducing the possibility of cross-service accounting linkage errors during subsequent iterations and modifications. The project ultimately outputs a complete service partitioning scheme and average cohesion parameters for each service. The service partitioning scheme fully records the business category to which each service unit belongs, the business nodes to which it is collected, the internal data flow, the external interaction nodes, the basis for internal control isolation, and the accounting reconciliation explanation. It clearly marks the independent business scope and cross-unit interaction specifications. The average cohesion parameters include details of node coupling calculation, high coupling node marking, and comparisons before and after boundary adjustments, which intuitively reflect the strength of business relationships within the unit. This serves as the basic input for subsequent component adaptation work and provides a quantitative reference for continuous architecture optimization.

[0027] The third step involves component adaptation and assembly. The platform retrieves the service partitioning scheme and the average cohesion parameters of each service, identifies the business characteristics of each service unit in the group's manufacturing scenario, and extracts feature dimensions such as industry attributes, compliance standards, business volume, and technical compatibility requirements. The comprehensive adaptation fit formula for candidate components is as follows: For each microservice unit m and candidate component k, data is collected separately. Industry compatibility and matching Compliance, Adaptation and Matching Performance compatibility Compatibility and fit, fixed weight =0.4、 =0.3、 =0.15、 =0.15), read the average cohesion of service unit m. A fixed value within the range of 0.3 to 0.5 was selected as the cohesion gain coefficient r, which was determined in conjunction with the compliance matching of components and units. Compliance rules matching correction coefficient, substitute all parameters into the formula to calculate the overall component adaptability and fit. The platform's computation covers four dimensions: industry adaptation, compliance adaptation, performance adaptation, and compatibility adaptation. It leverages the cohesion of service units to achieve a two-way improvement in both the quality of component decomposition and the effectiveness of component adaptation. The platform sorts all candidate components from highest to lowest compatibility, filters out components below a preset threshold, and selects the top-ranked component as the matching carrier for corresponding business groups. It utilizes a three-layer component library to call upon basic technical components, general business components, and accounting-specific compliance components, comprehensively covering three types of needs: underlying technical support, general office business, and core financial and tax algorithms. This saves developers the workload of repeatedly writing underlying logic for tax calculation, bookkeeping, and audit traceability, thus shortening the overall development cycle. The platform reads the built-in interaction interfaces and data read / write specifications of components to complete component architecture integration, analyzes the data call sequence between components, registers the interfaces, fields, and trigger conditions required for cross-component interaction, and completely retains all dependencies, avoiding extensive integration work caused by interface incompatibility and missing dependencies during the development phase. After component configuration, the service granularity is adaptively adjusted based on the average cohesion parameter of each service. High-concurrency modules such as general ledger and taxation are finely split to ensure response speed, while low-frequency static modules such as reports and basic files are appropriately merged to balance system performance and future maintenance pressure. The platform integrates component matching lists, connection links, dependencies, business coverage, and granularity adjustment records to generate a complete initial draft of the microservice architecture, intuitively presenting the overall architecture topology and component matching logic.

[0028] The fourth step involves compliance verification output. The platform retrieves the initial architecture draft and uses its built-in financial and tax compliance rule library to conduct comprehensive verification. This rule library includes three categories of standardized judgment items: accounting standards, tax control, and internal control auditing. It covers all constraints related to account standardization, debit and credit balance, voucher preparation, tax calculation standards, input tax deduction, data retention, operation logs, and separation of rights and responsibilities. Rules can be added, deleted, and updated in real time according to the latest financial and tax policies. The verification process covers five dimensions: accounting account standardization, consistency of accounting entries, legality of tax calculation logic, compliance of data retention, and security of interface data. Screening is completed node by node, interface by interface, and field by field, leaving no blind spots and comprehensively identifying hidden compliance risks within the architecture design. The system employs a three-tiered risk classification system: high-risk, medium-risk, and low-risk. High-risk cases directly restrict the saving and exporting of solutions, preventing defects from flowing into the development phase and mitigating serious consequences such as accounting discrepancies and tax penalties after deployment. Medium-risk cases are marked with problem locations and optimization directions, pushing them to designers for rectification and providing a clear adjustment strategy to reduce modification time. Low-risk cases are automatically and standardizedly corrected by the system, with modification logs retained, eliminating the need for manual intervention to handle minor flaws. The platform also offers a manual fine-tuning channel; every architectural modification automatically triggers a full-dimensional secondary review, continuously cyclically verifying until no new risk markers are added, balancing the need for customized adjustments with rigorous compliance control. Once all verifications pass, the overall architecture solution is solidified, locking in all aspects of business division, component matching, data links, and compliance configurations, prohibiting unverified temporary changes and ensuring a consistent and stable design solution. The system automatically extracts architecture details, component lists, dependency configurations, workflow paths, verification records, and rectification logs, and fills them into four types of standardized templates to generate a complete set of implementation documents, including architecture descriptions, business implementation, component configurations, and compliance verification. After standardizing the format, these documents are packaged and archived, ready for direct delivery to the development team, saving significant time spent on manual document writing. Figure 3 As shown.

[0029] The fifth step involves implementing full-chain control. The platform reads the fixed architecture plan and initializes a project-specific full-process control baseline. This baseline incorporates business segmentation, component standards, compliance constraints, and data retention requirements, serving as a unified benchmark for judgment throughout the development, testing, deployment, iteration, and decommissioning phases. This eliminates architectural deviations caused by inconsistent execution standards at different stages. During development, the baseline constrains the scope of component development and interface specifications, verifying that new business logic matches financial and tax control requirements, preventing arbitrary changes to the architecture design during development, and ensuring consistency between development results and the plan. During testing, compliance verification standards are used to conduct accounting and tax-related tests, verifying the reconciliation of component interaction data and identifying defects in tax calculation and reconciliation logic in advance. During deployment, hardware, storage, and network configurations are checked against the baseline to confirm that all deployment parameters meet compliance and performance standards, ensuring stable system operation after launch. During iteration, compliance re-checks are automatically initiated after each adjustment to business or component configurations, synchronously updating the control baseline and fully retaining change records, continuously upholding compliance standards throughout long-term iterations. During decommissioning, all historical accounting data and operation logs are fully archived, and data sealing is completed according to regulatory requirements to meet long-term audit and traceability needs. The system retains all operation and data change records throughout the entire process. Every adjustment can be traced back to the operating entity and time, fully covering the entire chain from design to decommissioning, and matching the core requirements of internal control auditing in the accounting industry.

[0030] In summary, this embodiment demonstrates the complete implementation of a new accounting system for a medium-sized manufacturing group. The entire process forms a closed loop of requirements gathering, breakdown, assembly, verification, and control. It leverages intelligent clustering to standardize microservice boundaries, proactively mitigating most financial and tax risks through pre-compliance verification, and reduces redundant development through layered accounting components. The solution is adaptable to the dual business needs of multiple subsidiaries within a group requiring independent accounting and unified aggregation. After implementation, accounting accuracy, compliance assurance capabilities, and iteration efficiency are all improved. It can provide a directly reusable, standardized implementation path for the development of new accounting systems for similar manufacturing enterprises.

[0031] Example 2: This embodiment addresses the microservice transformation project of an existing standalone accounting system for a regional chain retail enterprise. The enterprise has numerous offline stores and operates simultaneously with online channels. The original standalone system handled store expense reimbursements, purchase and sales declarations, accounts receivable / payable accounting, chain data aggregation, and electronic record management. With the expansion of business scale, the system's concurrency capacity became insufficient, version iteration cycles were lengthy, tax policy adaptation lagged, and cross-store reconciliation was cumbersome. A full system overhaul was too costly and carried a high risk of business interruption. Therefore, a microservice transformation solution compatible with existing data was adopted. The project required that the transformed system be compatible with the original technology stack and historical accounting data. Each business module was deployed and iterated independently to meet the concurrent operation needs of multiple stores. Accounting and tax-related logic conformed to current regulatory standards. The transformation process involved parallel operation of the old and new systems without interrupting daily accounting business. Figure 2 As shown.

[0032] The first step involves demand analysis and matching. The platform imports four types of demand documents for the transformation project: functional requirements, including a complete review of the original system's business processes, rules for migrating existing data, store reconciliation, online order accounting, and new functional requirements such as business analysis; compliance requirements, covering tax and financial regulations for the commercial industry, internal control standards for chain enterprises, and rules for retaining electronic accounting archives; performance requirements, matching indicators for concurrent operations across multiple stores and batch accounting processing; and deployment requirements, adapting to the enterprise's existing hardware, network, and multi-location store access modes. The platform extracts all key fields through semantic analysis, breaks down financial and accounting business actions into independent business nodes, distinguishes various operation units and labels input and output objects, specifically marks the correspondence between existing nodes and newly added expansion nodes, sorts out data flow paths based on business timelines, clarifies the existing data migration and adjustment links, extracts tax and internal control constraints and divides them into four types of control items and labels their effective scope, clearly defining the transformation boundaries and preventing errors in migration plan design due to ambiguous demands. The system utilizes a knowledge graph of accounting and finance operations for bidirectional matching. Based on the entities and relationships within the graph, it verifies the compliance of the modification requirements item by item, eliminating outdated business logic from the existing system that does not meet the latest regulatory requirements. It also supplements missing control and retention rules according to industry standards for chain retail, resolving long-standing compliance shortcomings in the existing system in one go. Finally, it generates a structured requirement model with identifiers for existing business operations, and all data is standardized to directly support subsequent node aggregation and partitioning.

[0033] The second step involves node aggregation and partitioning. The platform retrieves all business nodes within the model and uses a comprehensive aggregation coupling degree calculation method to determine the degree of node association. The calculation covers four dimensions: reconciliation, data dependency, process, and call frequency. It also incorporates reconciliation rigidity and compliance domain judgment standards, taking into account the feasibility of splitting and migrating existing data. Strongly related existing accounting nodes are not split into different services, reducing the difficulty of data migration. After initial aggregation, service boundaries are optimized based on chain retail business rules. The single responsibility of each unit is verified one by one. For highly coupled business logic in the original system, reasonable splitting is performed without disrupting accounting reconciliation. Each service unit only carries a single business scope, reducing the probability of cross-service data interaction errors after the transformation. The project outputs a service partitioning scheme and average cohesion parameters adapted to the existing system transformation scenario. The partitioning scheme specifies the business categories, aggregation nodes, internal flow, external interaction, internal control isolation, and reconciliation relationships of each service, and additionally marks the scope of existing data migration and splitting rules. The cohesion parameters include detailed coupling calculations, high-coupling node markings, and comparisons before and after boundary adjustments, supporting component matching and providing a reference for existing data splitting and migration.

[0034] The third step involves component adaptation and assembly. The platform retrieves the service partitioning scheme and average cohesion parameters, identifies the dual characteristics of chain retail and existing system renovation scenarios, and extracts industry, compliance, business volume, and technology compatibility features. A comprehensive adaptation fit calculation method for candidate components is used to evaluate component matching effectiveness. The four-dimensional adaptation dimensions are synchronously linked to cohesion gains, with a focus on increasing the matching weight of the technology compatibility dimension. This ensures seamless integration of components with the existing system's technology stack, avoiding the risks and learning costs associated with large-scale technology reconstruction. The platform sorts all candidate components in descending order of adaptability, eliminates components below a preset threshold, selects the best-matching components, prioritizes components compatible with existing data formats, and supplements the missing accounting and compliance components in the original system using a three-layer component library. This adds compliance capabilities while retaining the original business operation logic, eliminating the need to develop a complete set of underlying business code from scratch. The platform reads component interfaces and reads / writes specifications to complete the architecture integration, analyzes component call sequences, registers cross-component interaction interfaces, fields, and trigger conditions, fully records all dependencies, and adds transition interfaces between the old and new systems to ensure parallel operation of both systems during the transition period. After component configuration, the service granularity is adaptively adjusted based on average cohesion. High-concurrency modules such as store reimbursement and accounts receivable / payable are further broken down, while low-frequency modules such as archives and basic configurations are appropriately merged to balance system performance and subsequent maintenance costs. The platform compiles the component list, connection links, dependencies, business scope, and granularity adjustment records to generate a draft of a microservice architecture specifically for existing system transformation.

[0035] The fourth step involves compliance verification output. The platform retrieves the initial draft of the modified architecture and calls upon the financial and tax compliance rule library to perform full-dimensional verification. The rule library comprehensively covers various constraints related to accounting standards, tax control, and internal control audits. The verification scope simultaneously covers the compliance status of the new architecture design logic and the migrated existing data, ensuring that historical data still meets regulatory standards after conversion. The verification covers five dimensions: subject standardization, consistency, tax calculation legality, data retention, and interface security. It checks for potential risks node by node, interface, and field, and simultaneously conducts a special verification of the compliance of existing data formats, retention periods, and migration rules, leaving no verification omissions. The system handles risks according to a three-level risk classification. High-risk risks directly lock the solution to prevent defects from entering the modification and development stage; medium-risk risks mark the location of problems and rectification directions, simplifying the manual adjustment process; low-risk risks automatically generate standardized correction rules to batch process existing data format defects without requiring manual modification. The platform provides a channel for manual fine-tuning. Every architecture change automatically triggers a full-dimensional review, and verification is carried out cyclically until no new risks are added, balancing the flexibility of modification with the strength of compliance control. Once the verification is passed, the transformation architecture solution is solidified, locking all business processes, components, links, and compliance configurations, prohibiting arbitrary changes without review. The system automatically extracts business details, component lists, dependency configurations, workflow paths, migration rules, and verification ledgers, and fills in five types of templates to generate architecture descriptions, implementation documents, component configurations, compliance reports, and data migration guidelines. After being formatted in a unified way, these documents are packaged and archived, directly supporting the implementation of transformation projects and reducing the workload of manually writing supporting documents.

[0036] The fifth step is to implement full-chain management and control. The platform reads the solidified transformation architecture plan and initializes a dedicated full-process management and control baseline for the transformation. Business division, component standards, compliance constraints, data retention, and existing data migration rules are all incorporated into the baseline as a unified judgment standard for the five stages, avoiding data migration errors caused by inconsistent standards in each stage of the transformation. During the development phase, new feature development and existing logic migration are managed concurrently. The development scope and interface standards are constrained against the baseline, and the accounting logic after migration is verified to meet financial and tax control requirements to prevent unauthorized changes to existing logic during development that could cause data corruption. During the testing phase, new feature testing and existing data migration verification are carried out simultaneously. Accounting and tax-related special tests are completed based on compliance standards to verify the consistency of component reconciliation and parallel data between the old and new systems, and to avoid data distortion issues during migration in advance. During the deployment phase, a gray-scale launch is carried out according to the baseline, first piloting the system in stores, and then promoting it to all stores after stabilization. Hardware and storage configurations are verified to meet compliance requirements to prevent business interruptions caused by a one-time full launch. During the iteration phase, each feature update automatically initiates a compliance review, updates the baseline and retains change records, and continuously adheres to compliance standards during long-term iterations. During the decommissioning phase of the original monolithic system, all historical accounting and operation records are fully archived, and data is sealed in accordance with regulatory requirements to prevent the loss of historical audit data. The system retains all transformation operations and data change records throughout the entire process. Every step of the operation can be traced back to the personnel and time, fully covering the entire process of transformation design, development, gray-scale deployment, and old system decommissioning, meeting the hard requirements of auditing and internal control management for commercial enterprises.

[0037] In summary, this embodiment successfully implemented the microservice transformation of an existing accounting system for chain retail businesses. The entire solution is fully compatible with existing data and core business logic, achieving a smooth transition between the old and new systems without interrupting daily accounting operations at the stores. By leveraging intelligent component matching to reduce development workload, and by conducting comprehensive compliance checks upfront to address compliance shortcomings in the original monolithic system, the system's concurrency capabilities, iteration speed, and tax compliance level have been significantly improved after the transformation. This provides a mature and standardized implementation model for the microservice upgrade and transformation of various existing accounting systems.

[0038] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A software modular intelligent design platform and implementation method based on microservice architecture, characterized in that, The specific steps of this method are as follows: S100, Requirements Analysis and Matching: Receives accounting software requirements files, decomposes business nodes, data flow paths and compliance constraints through semantic analysis, matches them bidirectionally with the built-in accounting business knowledge graph, eliminates non-compliant requirements, completes accounting control rules, and generates a standardized structured requirements model. S200, Node Aggregation and Partitioning: Retrieve all business nodes in the structured requirement model, calculate the comprehensive aggregation coupling degree of each node pair and complete node aggregation, optimize the partitioning boundary in combination with accounting business boundary rules, and output the service partitioning scheme and the average cohesion parameter of each service. S300, Component Adaptation and Assembly: Retrieve the service partitioning scheme and average cohesion parameters, identify the characteristics of each service scenario, calculate the comprehensive adaptation and fit of candidate components, select the optimal components to complete the architecture docking and dependency configuration, adaptively adjust the service granularity, and generate the initial draft of the microservice architecture. S400 Compliance Verification Output: Retrieves the initial draft of the microservice architecture, calls the built-in financial and tax compliance rule library to perform full-dimensional compliance verification, performs graded processing according to risk level, supports manual fine-tuning and synchronous review, solidifies the solution after verification, and generates a complete set of standardized implementation documents; S500, full-chain management implementation: retrieve the fixed architecture solution, initialize the full-process management baseline, execute the corresponding management actions, and retain operation and data change records throughout the process.

2. The software modular intelligent design platform and implementation method based on microservice architecture according to claim 1, characterized in that, In step S100, the requirement document is a written document that carries the requirements for the construction of the accounting project. The document covers two types of carriers: offline document preparation and online form input. The functional requirements document includes the business operation process, interaction logic, and data entry and output content for general ledger accounting, expense reimbursement, tax declaration, fund management, and file archiving. The compliance requirements document includes provisions of financial and tax regulations, corporate internal control approval clauses, data security retention requirements, and constraints on the separation of accounting responsibilities. The performance requirements document includes metrics such as concurrent processing limits, data response time, batch accounting processing rate, and storage capacity thresholds; the deployment requirements document includes specifications for hardware configuration, network bandwidth, multi-branch deployment methods, and scheduled task configuration.

3. The software modular intelligent design platform and implementation method based on microservice architecture according to claim 1, characterized in that, In step S100, the accounting business knowledge graph is constructed by analyzing accounting standards, tax regulations, corporate financial systems, and historical business data using natural language processing technology. It extracts four core entities: accounting subjects, business types, tax calculation rules, and audit nodes, and sorts out three types of relationships: reconciliation relationships, flow relationships, and constraint relationships. The two-way matching process verifies the compliance of each business node in the requirements one by one, marks and removes requirement items that violate financial and tax supervision requirements, and supplements the missing accounting control rules and data retention requirements in the requirements based on the industry business standards in the accounting business knowledge graph. The generated structured requirement model contains five types of data: a complete list of business nodes, node attribute definitions, data flow links, compliance constraint rules, and performance indicator requirements. All data has been standardized and converted.

4. The software modular intelligent design platform and implementation method based on microservice architecture according to claim 1, characterized in that, In step S200, the overall aggregation coupling degree is determined by the formula: The calculation shows that, in the formula The overall aggregation coupling degree between business node i and business node j; The degree of reconciliation between the accounts of the two nodes; The stiffness enhancement coefficient is the reciprocal stiffness. The degree of data dependency between two nodes; The degree of correlation between the business processes of the two nodes; The correlation between the call frequencies of the two nodes; , , , These are the weighting coefficients for the four dimensions; This is the compliance domain consistency decay factor.

5. The software modular intelligent design platform and implementation method based on microservice architecture according to claim 1, characterized in that, In step S200, the service partitioning scheme is to record complete text data of all aggregated service units, including the business category to which each service unit belongs, a list of all aggregated business nodes, the internal data flow of the unit, a list of external interaction nodes of the unit, the basis for internal control isolation partitioning, and an explanation of accounting reconciliation. At the same time, it marks the independent business scope of each service unit and the cross-unit interaction and docking rules. The average cohesion parameter of each service is the average value of the pairwise aggregation coupling degree of all business nodes in the corresponding single service unit. The parameter is accompanied by the original calculation details of node coupling degree, the labeling of highly coupled nodes, and the comparison value of the parameter before and after boundary adjustment.

6. The software modular intelligent design platform and implementation method based on microservice architecture according to claim 1, characterized in that, In step S300, the overall fit of the candidate components is determined by the formula... The calculation yields the following result: The overall fit and suitability between the target microservice unit m and the candidate component k; Industry-specific compatibility; To ensure compliance and adapt the matching degree; To optimize performance for optimal matching; To ensure compatibility and fit; These are the weighting coefficients; is the average cohesion of the microservice unit m; r is the cohesion gain coefficient. Adjust the coefficients to match compliance rules.

7. The software modular intelligent design platform and implementation method based on microservice architecture according to claim 1, characterized in that, In step S300, the component adaptation and assembly step sorts all candidate components from high to low according to their comprehensive adaptation fit value, removes candidate components with a fit value lower than a preset threshold, and selects the first-ranked component as the matching component for the corresponding business group; conducts inter-component architecture docking based on the component's built-in data interaction interface and data read / write specifications, sorts out the order of data calls between components, registers the dependent interfaces, data fields, and call triggering conditions required for cross-component data transmission, and records all dependency relationships completely; after completing component matching and dependency configuration, the business coverage of each group is fine-tuned based on the average cohesion parameter of each group to achieve adaptive adjustment of service granularity, and summarizes the matching component list, component docking link, component dependency relationship, business coverage, and granularity adjustment record of each group, integrating them into a complete text carrier, which is the initial draft of the microservice architecture.

8. The software modular intelligent design platform and implementation method based on microservice architecture according to claim 1, characterized in that, In step S400, the full-dimensional verification covers five dimensions: accounting subject standardization, accounting consistency, tax calculation logic legality, data retention compliance, and interface data security. The risk level is divided into three levels: high risk, medium risk, and low risk. High-risk risks will directly block the saving and export of the plan and prevent the plan from entering the next stage. For medium-risk items, the system identifies the location and optimization direction of the issues and pushes them to designers for confirmation and rectification. For low-risk items, the system automatically completes standardized corrections and retains modification records. For marked risk content, a manual adjustment channel is opened, and each time an architectural content modification is completed, a full-dimensional secondary review is automatically triggered until no new risk markings are added.

9. The software modular intelligent design platform and implementation method based on microservice architecture according to claim 1, characterized in that, In step S400, the solidification scheme involves locking in all aspects of the architecture's business division, component matching, data interaction links, and compliance constraint configurations that have been repeatedly reviewed and deemed risk-free, prohibiting any unauthorized modifications. A complete set of standardized implementation documents is automatically generated based on the solidified scheme by extracting various information, including detailed business divisions, component adaptation lists, component dependency configurations, full-process data flow paths, compliance verification records, and risk rectification ledgers. The extracted content is then filled into four types of document templates: architecture description documents, business implementation documents, component configuration files, and compliance verification reports. The text format and data annotation rules are standardized, and all documents are compiled, packaged, and archived to form a complete set of standardized implementation documents that can be directly used for project implementation.

10. The software modular intelligent design platform and implementation method based on microservice architecture according to claim 1, characterized in that, In step S500, the execution of the corresponding control action is carried out based on the fully initialized control baseline, covering five stages: development, testing, deployment, iteration, and decommissioning. During the development stage, the development scope of components and data interface standards are constrained by the fixed architecture scheme, and the newly added business logic is verified to match the financial and tax control baseline. During the testing stage, special tests for accounting and tax-related scenarios are conducted according to compliance verification standards to verify the consistency of component interaction data. During the deployment stage, the hardware configuration and data storage retention rules are checked against the control baseline to confirm that the deployment parameters meet compliance requirements. During the iteration stage, after each adjustment to business division and component combination, a compliance review is automatically initiated, and the control baseline is updated and the changed content is retained synchronously. During the offline phase, complete the archiving of historical accounting data and operation records, and complete the data sealing in accordance with regulatory requirements.

Images