Enterprise digital application project-based architecture optimization design method and system

Abstract

The embodiment of the invention provides a framework optimization design method and system based on an enterprise digital application project, and belongs to the technical field of application frameworks. The method comprises the following steps: recycling an architecture design demand confirmed by a user, and generating demand specification information based on the architecture design demand; identifying each data report based on the demand specification information to obtain an identification result; determining aggregation roots based on the identification result, and classifying the aggregation roots to obtain an aggregation root set of each architecture layer; and correspondingly constructing each architecture layer based on the aggregation root set of each architecture layer, and allocating a corresponding service processing rule to each architecture layer. According to the scheme, complex business logic can be better centralized and managed, the maintainability and expansibility of the system are improved, and the defects of a traditional MVC architecture in complex projects are overcome.

Description

Technical Field

[0001] The present invention relates to the technical field of application architectures, and specifically to an architecture optimization design method and an architecture optimization design system based on enterprise digital application projects. Background Art

[0002] In the current software development field, the MVC (Model-View-Controller) architecture is widely used in medium and small projects. Especially in the context of agile development, developers are more inclined to use the MVC architecture to improve development efficiency. The MVC architecture divides an application into three parts: model, view, and controller, realizing the separation of data, business logic, and user interface. This separation can improve the maintainability and flexibility of the code, enabling developers to handle the user interface and business logic separately and reducing coupling. However, with the increase in application complexity, especially in some large digital projects that need to integrate multiple historical projects, the MVC architecture gradually exposes some problems and limitations and is difficult to meet the requirements of these complex projects.

[0003] The business logic in the MVC architecture is prone to dispersion. The model is responsible for processing data, and the controller is responsible for coordinating the interaction between the model and the view. However, since both may contain business logic judgments, it is difficult to centrally manage and uniformly encapsulate the business logic. This is particularly obvious in complex applications, where the business logic may be repeatedly implemented in different controllers or models, increasing the code redundancy and maintenance difficulty. For example, in an e-commerce system, the business logic related to order processing may be scattered in multiple controllers, causing problems such as scattered logic and difficulty in tracking.

[0004] The MVC architecture has deficiencies in expressing business domain concepts. Its design focuses more on the display and transmission of data, and lacks clear expression and distinction of core concepts in the business domain such as entities and value objects. This deficiency may cause it difficult for developers to clearly present the core structure and rules of the business in the code, affecting subsequent understanding and maintenance. For example, in a financial system, if core business concepts such as currency, account, and transaction are not clearly presented through a domain model, the code will become chaotic and difficult to understand.

[0005] The MVC architecture also has ambiguity in responsibility division. Although front-end developers are mainly responsible for the implementation of the view, and back-end personnel are responsible for the development of the model and controller, in actual development, the division of business logic may lead to unclear responsibilities, increasing the communication cost. Especially in the case of separated front-end and back-end teams, it is easy for developers to have inconsistent understandings of the responsibility boundaries, affecting the project progress.

[0006] The MVC architecture lacks a unified business language, and different developers may use different terms and concepts to describe the same business. This lack of uniformity in terminology can easily lead to a decrease in communication efficiency among teams, thereby affecting the collaboration effect.

[0007] Based on the above problems, the MVC architecture is difficult to meet the requirements of complex system integration projects, and there is an urgent need for an architecture solution that can effectively manage complex business logic and clearly express domain concepts. Summary of the Invention

[0008] The purpose of the embodiments of the present invention is to provide an architecture optimization design method and system based on enterprise digital application projects to at least solve the problem that the MVC architecture is difficult to meet the requirements of complex system integration projects.

[0009] To achieve the above object, the first aspect of the present invention provides an architecture optimization design method based on enterprise digital application projects, which is applied to the architecture optimization design of digital application projects with multiple legacy systems. The method includes: collecting the architecture design requirements confirmed by users, and generating requirement specification information based on the architecture design requirements; based on the requirement specification information, identifying each data report to obtain an identification result; determining the aggregate roots based on the identification result, and classifying each aggregate root to obtain the aggregate root sets of each architecture layer; correspondingly constructing each architecture layer based on the aggregate root sets of each architecture layer, and assigning corresponding business processing rules to each architecture layer.

[0010] Optionally, the requirement specification information includes any one or more of: information on each data report type, data source information of each data report, management process information of each data report, and data attribute information of each data report.

[0011] Optionally, the information on each data report type is any one or more of: performance appraisal declaration report, project approval application report, project investment decision application report, project information change report, and project post-evaluation process report; the data source information of each data report is any one or more of: database, file system, and external system; the management process information of each data report is any one or more of: strategic management, plan management, and project management; the data attribute information of each data report is any one or more of: data structure, data format, data update frequency, generation period of the data report, distribution method of the data report, and permission control of the data report.

[0012] Optionally, the identification result includes: identified entities and value objects; among them, the identified entities include any one or more of: data reports, data sources, report parameters, and user information; the value objects include any one or more of: report format, data sorting method, and date range.

[0013] Optionally, performing recognition of each data report based on the requirement specification information to obtain a recognition result, including: performing entity recognition of each data report based on the requirement specification information; performing value object recognition of each data report based on the requirement specification information; and outputting a recognition result based on the recognized entities and value objects.

[0014] Optionally, determining an aggregate root based on the recognition result includes: taking each data report as an aggregate root from the recognition result, and determining a data source, parameters, and format based on each aggregate root; the method further includes: when report parameters or related data change, regenerating a data report through the report aggregate root.

[0015] Optionally, the architecture layer includes: a front-end interface display architecture layer and a back-end application architecture layer; the back-end application architecture layer includes: an interface layer, a service layer, and a domain layer.

[0016] Optionally, assigning corresponding business processing rules to each architecture layer includes: the business processing rule of the front-end interface display architecture layer is to represent each value object based on a view object; the business processing rules of the interface layer and the service layer are to perform data transmission between different architecture layers or different systems based on a data transfer object; the business processing rule of the domain layer is to represent entities or concepts in the business domain based on a domain object.

[0017] A second aspect of the present invention provides an architecture optimization design system for an enterprise digital application project, which is applied to the architecture optimization design of a digital application project with multiple legacy systems. The system includes: a recovery unit for recovering the architecture design requirements confirmed by a user and generating requirement specification information based on the architecture design requirements; an identification unit for performing recognition of each data report based on the requirement specification information to obtain a recognition result; a processing unit for determining an aggregate root based on the recognition result and classifying each aggregate root to obtain an aggregate root set for each architecture layer; and a construction unit for correspondingly constructing each architecture layer based on the aggregate root set for each architecture layer and assigning corresponding business processing rules to each architecture layer.

[0018] On the other hand, the present invention provides a computer-readable storage medium, on which instructions are stored, and when the instructions are run on a computer, the computer is caused to execute the above-mentioned architecture optimization design method for an enterprise digital application project.

[0019] Through the above technical solution, the solution of the present invention designs the architecture based on DDD (Domain-Driven Design), generates requirement specification information by recycling the architecture design requirements confirmed by users, thereby ensuring the clarity and accuracy of the requirements. This solution can identify data reports according to the requirement specification information and determine the aggregate root based on the identification result. The classification and hierarchical management of the aggregate root enable effective division and organization of each architecture layer, thus realizing the modularization and clarity of business logic. At the same time, corresponding business processing rules are assigned to each architecture layer, ensuring the unity and independence of business logic between different layers and reducing the problem of chaotic responsibilities in the traditional MVC architecture. This architecture solution can better centralize and manage complex business logic, improve the maintainability and scalability of the system, and solve the deficiencies of the traditional MVC architecture in complex projects.

[0020] Other features and advantages of the embodiments of the present invention will be described in detail in the subsequent specific embodiments section. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The drawings are used to provide a further understanding of the embodiments of the present invention, and constitute a part of the specification. They are used together with the following specific embodiments to explain the embodiments of the present invention, but do not constitute a limitation to the embodiments of the present invention. In the drawings:

[0022] Figure 1 is a flowchart of the steps of an architecture optimization design method for enterprise digital application projects provided by an embodiment of the present invention;

[0023] Figure 2 is a schematic diagram of the front-end display interface architecture layer provided by an embodiment of the present invention;

[0024] Figure 3 is a schematic diagram of the interface layer provided by an embodiment of the present invention;

[0025] Figure 4 is a schematic diagram of the service layer provided by an embodiment of the present invention;

[0026] Figure 5 is a schematic diagram of the domain layer provided by an embodiment of the present invention;

[0027] Figure 6 is a system structure diagram of an architecture optimization design system for enterprise digital application projects provided by an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0028] The following will describe in detail the specific embodiments of the present invention with reference to the drawings. It should be understood that the specific embodiments described herein are only for the purpose of illustrating and explaining the present invention, and are not used to limit the present invention.

[0029] Figure 1 This is the method flow chart of the architecture optimization design method for enterprise digital application projects provided by an embodiment of the present invention. As Figure 1 shown, an embodiment of the present invention provides an architecture optimization design method for enterprise digital application projects, and the method includes:

[0030] Step S10: Recycle the architecture design requirements confirmed by users, and generate requirement specification information based on the architecture design requirements.

[0031] Specifically, the requirement specification information includes any one or more of the information of each data report type, the data source information of each data report, the management process information of each data report, and the data attribute information of each data report.

[0032] Further, the information of each data report type is any one or more of a performance assessment declaration report, a project approval application report, a project investment decision application report, a project information change report, and a project post-evaluation process report;

[0033] The data source information of each data report is any one or more of a database, a file system, and an external system;

[0034] The management process information of each data report is any one or more of strategic management, plan management, and project management;

[0035] The data attribute information of each data report is any one or more of data structure, data format, data update frequency, data report generation period, data report distribution method, and data report permission control

[0036] In the embodiment of the present invention, in order to effectively support the design of complex business processes and report management systems, it is first necessary to clarify the goals, uses, and user requirements of the system to form a detailed requirement specification. This process includes recycling and confirming the user's requirements for system architecture design, and generating detailed requirement specification information based on these requirements. In this process, the generation of requirement specification information is crucial because it ensures the accuracy and pertinence of system design. The content of the requirement specification information should include the types of various data reports, the data sources on which the reports depend, management processes, and the attributes of the data.

[0037] Specifically, the components of the requirement specification information should cover the following aspects. First, the system needs to identify different types of data report requirements, such as performance appraisal declaration reports, project establishment application reports, project investment decision-making application reports, project information change reports, and post-project evaluation process reports, etc. The differences in these report types determine the differentiated requirements of the system in aspects such as data processing, format definition, and generation cycle. The data source information of the report is also an important component in the requirement specification. The data source can come from multiple channels, including databases, file systems, external systems, etc. Clearly defining the data source corresponding to the report helps ensure the timeliness, accuracy, and consistency of the data, thus providing a reliable basis for report generation.

[0038] Furthermore, the management process information involves all aspects of report generation and approval. The system needs to understand and sort out various management processes such as strategic management, plan management, and project management to ensure that report generation, approval, and distribution comply with these fixed business process specifications. This not only improves the standardization degree of the process but also ensures the consistency and traceability of reports in different business scenarios. The data attribute information is the key content for describing the structure, format, and update frequency of the data in the report. Understanding the structure and format of the data can help the system process the data more efficiently and generate reports that meet the user's needs. At the same time, the system also needs to clarify the report generation cycle, distribution method, and permission control requirements to ensure that the system can meet the actual usage needs of different users.

[0039] Based on the solution of the present invention, by generating the requirement specification information, this architecture solution can effectively classify and organize various reports and data, ensuring that the system has higher flexibility and scalability when dealing with complex business requirements. In addition, by clarifying the management process and data attribute information, the system can more accurately define business rules, thereby improving the efficiency of report generation and distribution. This design can significantly solve problems such as unclear data sources, chaotic processes, and unclear permission control in traditional report management systems, ensuring that the system has stronger maintainability and business adaptability.

[0040] Step S20: Based on the requirement specification information, perform the identification of each data report to obtain an identification result.

[0041] Specifically, the identification result includes: identification entities and value objects; among them, the identification entities include: any one or more of data reports, data sources, report parameters, and user information; the value objects include: any one or more of report formats, data sorting methods, and date ranges. The performing the identification of each data report based on the requirement specification information to obtain an identification result includes: performing the entity identification of each data report based on the requirement specification information; performing the value object identification of each data report based on the requirement specification information; and outputting the identification result based on the identified entities and value objects.

[0042] In an embodiment of the present invention, by identifying entities and value objects in a report system based on requirement specification information, it is possible to ensure that the system can accurately capture user requirements and provide a basis for subsequent report generation and processing.

[0043] Furthermore, based on the requirement specification information, entity identification of each data report is gradually carried out. An entity is an object with an independent meaning of existence in the system, often having a clear life cycle and a unique identifier. In this system, the main entities include data reports, data sources, report parameters, and user information, etc. For example, a report entity includes attributes such as report name, description, type, data source, parameters, generation time, and status, which can reflect the specific characteristics and generation status of each report. The data source entity can be a database connection, a file path, or an API interface, and has attributes such as connection information, data format, and update frequency. The report parameter entity is used to define the conditions for data filtering and screening, and the user entity covers information such as user name, role, and permissions, ensuring that different users can access and use the corresponding report functions according to their permissions.

[0044] Furthermore, it is also necessary to identify various types of value objects based on the requirement specification information. Value objects are different from entities. They are objects without independent identifiers and are immutable, usually used to describe a specific attribute or operation method. In this system, common value objects include report formats, data sorting methods, and date ranges, etc. For example, the report format value object may include PDF, Excel, HTML, etc., which determine the output format of report generation. The data sorting method is another value object used to determine the display order of report data, which may be ascending or descending. The date range value object is used to limit the data time interval required for report generation, which is particularly important for generating data reports based on a specific time period. During the process of entity and value object identification, the system will automatically identify various reports and related components based on the requirement specification information, ensuring that it can accurately reflect user requirements under complex business logics. The results of the identification include the relevant entities and value objects of the report, which will be used as the basic data in the report generation and processing process. Through this identification process, the system can clearly determine the various types of information required for the report, and further classify and organize the report through these entities and value objects.

[0045] Furthermore, the technical effects of the recognition process are reflected in multiple aspects. First of all, the entity and value object recognition based on the requirement specification information ensures the accuracy and integrity of the system design. By automatically identifying entities such as reports, data sources, and users, the system can avoid information omission or errors in manual intervention. In addition, the recognition of value objects enables the system to manage immutable configurations and rules, such as report formats and data sorting methods, more flexibly, improving the scalability and reusability of the system. Most importantly, this process greatly simplifies the generation and maintenance of complex report systems, ensuring that the system can flexibly respond to demand changes in various business scenarios.

[0046] Step S30: Determine the aggregate roots based on the recognition results, classify each aggregate root, and obtain the aggregate root sets of each architecture layer.

[0047] Specifically, from the recognition results, each data report is used as an aggregate root, and the data source, parameters, and format are determined based on each aggregate root; the method further includes: when the report parameters or related data change, the data report is regenerated through the report aggregate root.

[0048] In the embodiments of the present invention, each data report is regarded as an aggregate root. The aggregate root is a core concept in Domain-Driven Design (DDD) and is responsible for managing all related entities and value objects within its scope. Specifically, a report aggregates multiple related entities and value objects, such as data sources, report parameters, and formats. By using the report as an aggregate root, the system can effectively organize and manage various types of data and operations related to the report, ensuring data consistency and integrity during the report generation process.

[0049] Furthermore, once the report is determined as the aggregate root, the system will further clarify the specific data sources, parameters, and formats relied on by each report according to the recognition results. This process enables the system to flexibly respond to the requirements of different report types, ensuring that each report is generated and maintained according to its specific requirements. For example, a certain report may use a specific database as the data source, apply specific parameter filtering conditions, and output in PDF format. The system will determine these elements based on the aggregate root and perform corresponding configuration and processing.

[0050] Furthermore, a dynamic response mechanism for changes in report parameters or related data is also introduced. When the parameters of a report or other related data change, the system only needs to regenerate the corresponding report aggregate root without affecting other reports. The technical effect of this mechanism is to reduce unnecessary report reconstruction operations and ensure that the system is more efficient and flexible in responding to changes in business requirements. Through this method of classifying and managing the aggregate root, the system can achieve the independence of each report, ensuring that the business logic and data processing between different reports do not interfere with each other. This architecture design not only improves the maintainability of the system but also ensures data consistency and operational efficiency in a large-scale complex report management system.

[0051] Step S40: Based on the aggregate root sets of each architecture layer, construct each architecture layer and assign corresponding business processing rules to each architecture layer.

[0052] Specifically, the architecture layer includes: a front-end interface display architecture layer and a back-end application architecture layer; the back-end application architecture layer includes: an interface layer, a service layer, and a domain layer. Assigning corresponding business processing rules to each architecture layer includes: the business processing rule of the front-end interface display architecture layer is to represent each value object based on a view object; the business processing rules of the interface layer and the service layer are to transfer data between different architecture layers or different systems based on a data transfer object; the business processing rule of the domain layer is to represent entities or concepts in the business domain based on a domain object.

[0053] In the embodiment of the present invention, a layered architecture design of the front end and the back end is adopted. The front-end interface display architecture layer is mainly used to display data and interact with users, while the back-end application architecture layer is responsible for processing business logic and data management. The back-end application architecture layer is further divided into an interface layer, a service layer, and a domain layer.

[0054] 1) Front-end interface display architecture layer: The main responsibility of the front-end interface layer is to present various information that needs to be displayed on the user interface through a VO (view object). The view object is specifically used to convert the data passed from the back end into the format required for front-end display, and it contains business-related logic. The business processing rules of this layer focus on how to present data to users in a suitable way to ensure the smoothness of the user experience. The view object is closely related to the business logic. By encapsulating specific objects and values, it integrates them into the user interface to meet the design requirements and user interaction standards.

[0055] 2) Back-end application architecture layer: The back-end application architecture layer is further divided into the following parts:

[0056] Interface Layer (Controller): The interface layer is responsible for receiving the VO (View Object) passed from the front end and converting it into a DTO (Data Transfer Object). This process transfers data in a format suitable for transmission between different layers or different systems. The business processing rules of the interface layer are to ensure the efficient and error-free transfer of data between the front and back ends and different systems.

[0057] Service Layer (Service): After receiving the DTO from the interface layer, the service layer is responsible for converting it into a Context (Context Object) that can be understood by the domain layer. The business rules of the service layer are to ensure that when data is transferred between different layers, it can be docked with the subsequent business logic in an appropriate form. At the same time, the service layer will also perform preliminary business processing on the DTO according to business requirements.

[0058] Domain Layer (Domain): The domain layer is the core part of the business logic. In the domain layer, the DTO is converted into a DO (Domain Object), and then specific operations are performed according to business rules. DOs are objects that represent specific entities or concepts in the business domain of the system. They may change during their life cycle and have unique identifiers. In the domain layer, the main task of the system is to execute complex business logic and persist data by interacting with the infrastructure layer (such as a database).

[0059] Furthermore, after the business logic in the domain layer is executed, the domain objects interact with the database through the infrastructure layer. The infrastructure layer provides interfaces to database systems (such as MySQL, MongoDB, Redis, etc.) to ensure that the system can efficiently read and write data. The database is responsible for storing business data and ensuring its consistency and reliability.

[0060] In this architecture design, different layers share different business processing rules, ensuring clear division of responsibilities for each layer, reducing coupling, and enhancing the flexibility and maintainability of the system.

[0061] 1) Business processing rules of the front-end interface display architecture layer: The front-end layer mainly represents each value object based on the view object (VO). This ensures that data can be displayed in a user-friendly form, and the logic of the UI layer is decoupled from the core business logic. In this way, when the front-end display needs to be modified, it will not affect the back-end business logic.

[0062] 2) Business processing rules of the interface layer and the service layer: The interface layer and the service layer perform data transmission and processing through DTOs to ensure that data can be transmitted between different architecture layers or systems. This DTO design enables the interface and service layers to flexibly respond to system expansion. Especially when the system needs to dock with third-party services, DTOs can be used as a standard transmission format to reduce coupling.

[0063] 3) Business processing rules of the domain layer: The core of the domain layer is to represent entities or concepts in the business domain based on domain objects (DO). In this layer, the implementation of business logic is operated through context objects to ensure that domain objects are closely integrated with business logic and handle complex business requirements. This design makes the domain layer highly scalable and business independent.

[0064] Based on the solution of the present invention, a large system is divided vertically and horizontally. Through vertical and horizontal division, each architecture layer, aggregate root and entity is independent of each other, and the impact between them is minimized as much as possible:

[0065] 1) Vertical segmentation: ensures the decoupling of the front-end and back-end. The front-end is responsible for display and interaction, while the back-end is responsible for processing data and business logic. In this way, if the front-end interface changes, it will not affect the back-end business logic. At the same time, the decoupling between the back-end interface layer, service layer, and domain layer makes the system more flexible and easy to maintain when processing data and business logic.

[0066] 2) Horizontal segmentation: Horizontal segmentation is mainly reflected in the independence between different aggregate roots (such as performance evaluation, project application, project information change, etc.) and entities. Each aggregate root has its own independent business logic processing. If the business logic in a certain aggregate root changes, it will not affect other aggregate roots. This reduces the overall complexity of the system and reduces maintenance costs, especially in large systems, which can significantly improve development efficiency and system stability.

[0067] Preferably, the defined domain services include:

[0068] 1) Report generation service: responsible for obtaining data from the data source, applying report parameters for filtering and calculation, and generating report files in a specific format.

[0069] 2) Data verification service: Verify the availability of data sources and the integrity of data to ensure the accuracy of report generation.

[0070] 3) Permission management service: Control access to and operation of reports based on user roles and permissions.

[0071] Designers and developers can determine a common design and development language according to the above steps and methods to avoid as much as possible the deterioration of demand understanding caused by different professional terminology and cognitive understanding, thereby reducing development and maintenance costs.

[0072] In the embodiments of the present invention, the data of the system comes from unified input, user filling, and interaction with other systems. Among them, both unified input and user filling store data into the database manually. The interaction with other systems requires specific business logic, interfaces, and data requests to obtain. The obtained data is used on the one hand for users to normally obtain information, and on the other hand as auxiliary information when users fill in information. Therefore, if normal data cannot be obtained when requesting data, it will have a great impact on the normal operation of the system. Because there are different companies and different teams responsible for other business systems, if a data acquisition error occurs, obtaining the correct error information, contacting the other team to locate the problem, and determining the repair responsibility is an extremely long process. On the one hand, the system should formulate standard data specifications as much as possible and distinguish possible problem data at the code logic level. In this way, if an error occurs during data sending and receiving, the type of problem can be located immediately, reducing the debugging and positioning time. On the other hand, a mechanism for automatically sending probe test data at night should be established. Compare the obtained data content with the sorted data specifications. If there are problems such as incorrect data formats, missing parts of data content, or sudden inability to obtain data, automatically organize the problems to form a problem report and send it to the relevant persons in charge of other systems via text messages and emails. Instead of triggering a data request when the user uses it and then discovering the error, the possible time points of problems are advanced. And formally inform in a way agreed upon with other teams, clarify the scope of responsibilities, and minimize the impact on normal business as much as possible.

[0073] Based on the solution of the present invention, this system is designed by drawing on the design concept of DDD, and clear business sub-domains and domain boundaries are divided. The system architecture is more reasonable, and the layered structure makes the responsibilities of each part of the system clear, easy to maintain and expand. High cohesion and low coupling make each module in this system have high cohesion, that is, the functions within each module are closely related, while the coupling degree between modules is relatively low. In this way, when the business requirements change, only the relevant modules need to be modified without affecting the entire system. If it is necessary to replace the underlying data storage technology or underlying components, due to the layered architecture of DDD and good encapsulation, the technology can be replaced at the infrastructure layer without having a significant impact on the upper-layer business logic. The code readability is improved. Following the design principles of DDD, the code structure is clearer and easier to understand. The use of concepts such as entities, value objects, and domain services makes the code more expressive, and newly added developers can understand the business logic and code structure of the system faster, thus improving the maintenance efficiency.

[0074] In a possible embodiment, as Figure 2 、 Figure 3 、 Figure 4 and Figure 5, a schematic diagram of the entity architecture of a front - end interface display architecture layer, an interface layer, a service layer, and a domain layer is provided respectively.

[0075] Figure 6 It is the system structure diagram of an architecture optimization design system for enterprise digital application projects provided by an embodiment of the present invention. As Figure 6 shown, an embodiment of the present invention provides an architecture optimization design system for enterprise digital application projects. The system includes: a recovery unit, configured to recover the architecture design requirements confirmed by the user and generate requirement specification information based on the architecture design requirements; an identification unit, configured to perform identification on each data report based on the requirement specification information to obtain an identification result; a processing unit, configured to determine the aggregate roots based on the identification result and classify each aggregate root to obtain the aggregate root sets of each architecture layer; a construction unit, configured to construct each architecture layer corresponding to the aggregate root sets of each architecture layer and assign corresponding business processing rules to each architecture layer.

[0076] An embodiment of the present invention also provides a computer - readable storage medium. Instructions are stored on this computer - readable storage medium, and when running on a computer, it causes the computer to execute the above - mentioned architecture optimization design method for enterprise digital application projects.

[0077] Those skilled in the art can understand that all or part of the steps in the methods of the above - mentioned embodiments can be completed by instructing relevant hardware through a program. This program is stored in a storage medium and includes several instructions to cause a single - chip microcomputer, a chip, or a processor to execute all or part of the steps of the methods described in various embodiments of the present invention. The aforementioned storage medium includes: USB flash drives, mobile hard disks, read - only memories (ROM, Read - Only Memory), random access memories (RAM, Random Access Memory), magnetic disks, or optical disks and other various media that can store program codes.

[0078] The optional embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the embodiments of the present invention are not limited to the specific details in the above - mentioned embodiments. Within the technical concept scope of the embodiments of the present invention, various simple modifications can be made to the technical solutions of the embodiments of the present invention, and these simple modifications all belong to the protection scope of the embodiments of the present invention. Additionally, it should be noted that, among the various specific technical features described in the above - mentioned specific embodiments, they can be combined in any suitable manner without conflict. To avoid unnecessary repetition, the embodiments of the present invention do not separately describe various possible combination methods.

[0079] In addition, any combination can be made among various different embodiments of the present invention, as long as it does not violate the idea of the embodiments of the present invention, and it should equally be regarded as the content disclosed by the embodiments of the present invention.

Claims

1. An architecture optimization design method for enterprise digital application projects, which is applied to the architecture optimization design of digital application projects with multiple legacy systems, and is characterized in that, The method includes: Recycling the architecture design requirements confirmed by the user and generating requirement specification information based on the architecture design requirements; Based on the requirement specification information, identifying each data report to obtain an identification result; Determining aggregate roots based on the identification result and classifying each aggregate root to obtain an aggregate root set for each architecture layer; Constructing each architecture layer corresponding to the aggregate root set of each architecture layer and assigning corresponding business processing rules to each architecture layer.

2. The method according to claim 1, characterized in that The requirement specification information includes: Any one or more of each data report type information, data source information of each data report, management process information of each data report, and data attribute information of each data report.

3. The method according to claim 2, characterized in that, Each of the data report type information is any one or more of a performance appraisal declaration report, a project approval application report, a project investment decision application report, a project information change report, and a project post-evaluation process report; Each of the data source information of the data reports is any one or more of a database, a file system, and an external system; Each of the management process information of the data reports is any one or more of strategic management, plan management, and project management; Each of the data attribute information of the data reports is any one or more of data structure, data format, data update frequency, generation period of the data report, distribution method of the data report, and permission control of the data report.

4. The method according to claim 1, wherein The identification result includes: Identified entities and value objects; among them, The identified entities include: Any one or more of a data report, a data source, a report parameter, and user information; The value objects include: Any one or more of a report format, a data sorting method, and a date range.

5. The method according to claim 4, wherein The performing each data report identification based on the requirement specification information to obtain an identification result includes: Performing entity identification of each data report based on the requirement specification information; Performing value object identification of each data report based on the requirement specification information; Outputting an identification result based on the identified entities and value objects.

6. The method according to claim 1, wherein The determining aggregate roots based on the identification result includes: Regarding each data report as an aggregate root from the identification result and determining a data source, parameters, and format based on each aggregate root; The method further includes: When a report parameter or related data changes, regenerating a data report through the report aggregate root.

7. The method according to claim 1, characterized in that, The architecture layer includes: A front-end interface display architecture layer and a back-end application architecture layer; The back-end application architecture layer includes: An interface layer, a service layer, and a domain layer.

8. The method according to claim 7, characterized in that Assigning corresponding business processing rules to each architecture layer includes: The business processing rule of the front-end interface display architecture layer is to represent each value object based on a view object; The business processing rules of the interface layer and the service layer are to perform data transmission between different architecture layers or different systems based on a data transfer object; The business processing rule of the domain layer is to represent entities or concepts in the business domain based on domain objects.

9. An architecture optimization design system based on enterprise digital application projects, which is applied to the architecture optimization design of digital application projects with multiple legacy systems, is characterized in that The system includes: A recycling unit for recycling the architecture design requirements confirmed by the user and generating requirement specification information based on the architecture design requirements; An identification unit for performing each data report identification based on the requirement specification information to obtain an identification result; A processing unit, configured to determine an aggregate root based on an identification result, classify each aggregate root, and obtain an aggregate root set for each architecture layer; A construction unit, configured to construct each architecture layer corresponding to the aggregate root set of each architecture layer, and allocate corresponding business processing rules to each architecture layer.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions which, when running on a computer, cause the computer to execute the architecture optimization design method based on an enterprise digital application project according to any one of claims 1-8.

Images