DDD-based software automatic design method and apparatus, and electronic device

Abstract

The invention discloses a DDD-based software automatic design method and apparatus, and an electronic device. The method comprises the steps of S1, demand input and preprocessing; s2, modeling is carried out from bottom to top; s3, supplementing from top to bottom; step S4, code generation; step S5, code testing; s6, reverse verification is carried out; and S7, carrying out difference analysis and code updating. Carrying out static analysis and large model collaborative reverse extraction on a DDD model of a code view angle, and carrying out structure and semantic comparison on the DDD model and a primary edition DDD model to generate a difference report; and finally, according to the difference risk level, automatically repairing low-risk deviation or submitting high-risk change for manual auditing, writing the confirmed change back to the model, triggering a new round of generation and test, and forming a continuous closed loop of modeling-generation-verification-evolution.

Description

Technical Field

[0001] This invention belongs to the field of software automatic design technology, and relates to a software automatic design method, device and electronic device based on DDD. Background Technology

[0002] As software systems become increasingly large and complex, the traditional manual modeling-coding-testing process is time-consuming, costly, and prone to distortion. Domain-Driven Design (DDD), as a software design methodology, can establish a unified language from a business perspective, effectively addressing complex business scenarios. However, DDD heavily relies on expert experience, has a high modeling threshold, and is difficult to implement, limiting its widespread application in the industry. In recent years, large language models (LLMs) have made breakthroughs in information extraction and code generation, providing new possibilities for software development. However, large models perform poorly in strategic design (such as subdomain partitioning and bounded context boundary determination), resulting in insufficient accuracy in "directly generating a complete DDD model from a large model," which is insufficient to meet actual engineering needs.

[0003] Currently, the industry mainly uses the following technical solutions to solve the DDD modeling and code implementation problem: Manual DDD modeling + handwritten code: Domain experts and architects conduct Event Storming based on requirements documents, and then manually produce the model and code. This method relies on expert experience, is inefficient and costly, and makes it difficult to guarantee the long-term consistency of the model and code. Pure LLM end-to-end code generation: Directly inputting requirements documents into a large model, outputting the code skeleton in one go. This method lacks DDD semantic verification, especially at the strategic design level, where the error rate is high, and problems often arise with aggregation boundaries and context dependencies. Traditional MDE tools (such as EMF, MagicDraw) forward engineering: First draw UML / DSL, then generate code. These tools usually lack automatic reverse verification from code to model, causing the model and code to gradually deviate during project evolution, model drift cannot be detected in time, and continuous iteration is difficult. However, although the Chinese invention patent application with publication number CN112506502A discloses a visual programming method based on human-computer interaction, the technical solution does not solve the core problems in DDD modeling, such as the weak strategic abstraction ability of large models and the difficulty in detecting model drift. Summary of the Invention

[0004] The purpose of this invention is to overcome the shortcomings of the prior art and provide a method, device and electronic device for automatic software design based on DDD. By integrating the semantic understanding ability of large language models, the code generation ability of model-driven engineering and static analysis and feedback closed-loop mechanism, it realizes the fully automatic construction of DDD software system from original requirements to runnable, verifiable and evolvable software system.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a software automatic design method based on DDD, comprising the following steps: S1. Receive the user's requirements document, and perform formatting and structuring processing to obtain a formatted requirements document; S2. Based on the formatted requirements document, extract several tactical elements, cluster these tactical elements into several aggregates and unclustered tactical elements; cluster these aggregates and unclustered tactical elements into several subdomains, and supplement these subdomains with domain services to form the initial version of the DDD model. S3. Supplement the initial DDD model from the perspective of DDD strategic design, and output the final DDD model; S4. Generate project code and several test cases based on the final DDD model, and combine them into complete project code; S5. Test based on the complete project code; If the test is successful, obtain the code that passed the test; If a test fails, patch the entire project code and retest until the test passes and you obtain code that passes the test. S6. Analyze the code that passed the test, extract the DDD model from the code perspective, compare the DDD model from the code perspective with the final DDD model, and output a difference report. S7. Based on the difference report, determine whether the code that passed the test needs to be updated; If not, output the code that passed the test; If so, update the code that passed the test to form a new complete project code, and repeat steps S5~S6 until it is no longer necessary to update the code that passed the test, and output the code that passed the test.

[0006] Furthermore, step S1 specifically includes: (1) Receive the requirement document input by the user, perform text parsing on the requirement document through the large language model, extract and reorganize the content to form a structured requirement document; (2) The structured requirements document is formatted by a large language model. The formatting process includes: unifying the terminology dictionary, removing redundant descriptions, and completing implicit subjects to form a formatted requirements document.

[0007] Furthermore, step S2 specifically includes: (1) Input the formatted requirements document into the large language model, and extract several tactical elements according to the definition of tactical elements in domain-driven design. The tactical elements include: entities and value objects. (2) Several tactical elements are clustered into several aggregates and unclustered tactical elements based on the semantic similarity and dependency coupling between the tactical elements by using a large language model. Each aggregate contains at least one entity, and the entity in the core of the business in the aggregate is called the aggregate root. (3) Several aggregated and unclusterable tactical elements are clustered into several subdomains based on semantic similarity and dependency coupling degree using a large language model; (4) Based on the content and formatted requirements documents of several subdomains, domain services are added to each subdomain through the large language model. The domain service is an object that carries domain logic but is not suitable to be attributed to any entity or value object. All subdomains after adding domain services together form the initial version of the DDD model.

[0008] Furthermore, step S3 specifically includes: The initial version of the DDD model is structurally reviewed and optimized to output the final DDD model. The structural review and optimization include: identifying and eliminating overlapping aggregation boundaries, correcting unreasonable subdomain partitioning, adjusting dependencies between subdomains to prevent circular dependencies, and discovering and resolving rule conflicts of domain services across subdomains, thereby improving the cohesion of the initial version of the DDD model and the system's evolutionary capability.

[0009] Furthermore, step S5 specifically includes: (1) The complete project code and its required runtime environment are packaged by a code packaging tool to generate a deployable container image. The runtime environment includes: third-party libraries and system dependencies required for the code to run. (2) Push the deployable container image to the deployment environment through the image repository, run all test cases, and collect test results; (3) If all test results are normal, the complete project code is the code that has passed the test; (4) If the test results are abnormal, the complete project code is repaired by generating a large language model through code, and all test cases are retested until the test results are all normal, and the code that passes the test is obtained.

[0010] Furthermore, step S6 specifically includes: (1) Input the code that passed the test into the large language model, and extract the following in order: subdomain, domain service, aggregate, entity, and value object to form a DDD model from the code perspective; (2) Input the code-perspective DDD model, the final DDD model and the tested code into the large language model, compare the code-perspective DDD model and the final DDD model and output a difference report. The difference report consists of several difference points, including: difference content and whether the code needs to be modified.

[0011] Furthermore, step S7 specifically includes: (1) Input the difference report into the large language model and analyze whether the code that passed the test needs to be updated; (2) If the code that passed the test does not need to be updated, then end; (3) If it is necessary to update the code that has passed the test, the code that has passed the test is updated by generating a large language model to form a new complete project code, and steps S5~S6 are repeated until it is no longer necessary to update the code that has passed the test. At this time, the code that has passed the test is the final output.

[0012] A software-automated design apparatus based on DDD, comprising: The input module is used to receive the user's requirement document, and perform formatting and structuring processing to obtain a formatted requirement document; The first generation module is used to extract several tactical elements based on the formatted requirements document, cluster these tactical elements into several aggregates and unclustered tactical elements, cluster these aggregates and unclustered tactical elements into several subdomains, and supplement the subdomains with domain services to form the initial version of the DDD model. The supplementary module is used to supplement the initial version of the DDD model from the perspective of DDD strategic design, and output the final DDD model; The second generation module is used to generate project code and several test cases based on the final DDD model, and combine them into complete project code; The testing module is used to test the complete project code. If the test is normal, the code that passes the test is obtained; if the test fails, the complete project code is patched and retested until the test is normal, and the code that passes the test is obtained. The analysis module is used to analyze the code that has passed the test, extract the DDD model from the code perspective, compare the DDD model from the code perspective with the final DDD model, and output a difference report. The judgment module is used to determine whether the code that has passed the test needs to be updated based on the difference report. If not, the code that has passed the test is output. If so, the code that has passed the test is updated to form a new complete project code. The test module and analysis module are repeated until the code that has passed the test no longer needs to be updated, and then the code that has passed the test is output.

[0013] An electronic device, comprising: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors perform the methods described above.

[0014] A computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of the method described above.

[0015] The present invention has the following beneficial effects: (1) It realizes the fully automated construction of unstructured requirements documents into DDD tactical and strategic models, significantly reducing the dependence on manual modeling experience; (2) Through the dual mechanism of “bottom-up modeling + top-down verification”, the model is ensured to conform to both fine-grained business semantics and macro-architectural constraints. (3) A complete closed loop of "model → code → verification → correction" was constructed. Static analysis and large model were used to extract the code perspective model in reverse, ensuring the consistency between the model and the code. (4) Introduce differential risk classification and automatic repair mechanism to support the continuous model freshness of the system during the evolution process and avoid model drift.

[0016] In summary, this invention achieves a high degree of automation in DDD modeling through an innovative two-stage modeling strategy, a flexible aggregation mechanism, intelligent reverse verification, and differential grading processing, demonstrating significant technological advancements and practical value. Attached Figure Description

[0017] Figure 1 This is a flowchart of the DDD-based automatic software design method of the present invention; Figure 2 This is a block diagram of the software automatic design device based on DDD according to the present invention. Detailed Implementation

[0018] The present invention will be further described in detail below with reference to the accompanying drawings and specific implementation steps. It should be understood that the specific embodiments described herein are only for explaining the present invention and are not intended to limit the scope of protection of the present invention.

[0019] This invention enables end-to-end automated construction of domain-driven design (DDD) software systems, from unstructured business requirements to operable, verifiable, and evolvable systems. This method comprises seven core steps: First, the received requirements document is preprocessed with structure and formatting. Then, tactical elements such as entities, value objects, and domain events are extracted from the bottom up using a large language model, and clustered using semantic similarity and dependency coupling to form aggregated and bounded contexts, constructing an initial version of the DDD model. Subsequently, the initial model is validated from top to bottom using a strategic perspective, correcting overlapping aggregate boundaries, circular dependencies in contexts, and conflicts in business rules. The validated model is injected into a Model-Driven Engineering (MDE) engine, automatically generating microservice code skeletons, domain layer implementations, and corresponding test cases, and is then deployed and validated via a CI pipeline. If tests fail, the large model is used to automatically locate and repair the code. Further, a code-perspective DDD model is extracted through static analysis and in collaboration with the large model, and its structure and semantics are compared with the initial DDD model to generate a difference report. Finally, based on the difference risk level, low-risk deviations are automatically repaired or high-risk changes are submitted for manual review, and confirmed changes are written back to the model, triggering a new round of generation and testing, forming a continuous closed loop of modeling—generation—validation—evolution. This invention effectively solves the problems of relying on human experience, the disconnect between models and code, and the lack of automatic verification and continuous alignment mechanisms in traditional DDD implementation, and significantly improves the development efficiency and architecture quality of complex business systems.

[0020] Example 1 This embodiment requires generating complete project code based on the user-provided requirements document. Specifically, the user requirement is to generate a student course selection management system.

[0021] like Figure 1 A software automatic design method based on DDD includes the following steps: S1. Receive the user's requirements document, and perform formatting and structuring processing to obtain a formatted requirements document; Step S1 is as follows: (1) Receive the requirement document input by the user, perform text parsing on the requirement document through the large language model, extract and reorganize the content to form a structured requirement document; (2) The structured requirements document is formatted by a large language model. The formatting process includes: unifying the terminology dictionary, removing redundant descriptions, and completing implicit subjects to form a formatted requirements document.

[0022] In this embodiment, the DeepSeek-R1 model is used with the prompt, "Please analyze the input requirements document, parse, extract, and reorganize its content into a structured requirements document. The structured requirements document should consist of the following three parts: Background (summarize the scenario in the requirements document), People (all people involved in the requirements document), and Functions (extract all the functions that need to be implemented according to the requirements document)." This prompt parses the user-input requirements document, forming a structured requirements document composed of these three parts. Then, the structured requirements document is input into the DeepSeek-R1 model, with the prompt, "Please analyze the input structured requirements document, and perform three formatting processes on the structured requirements document: unify the terminology dictionary, remove redundant descriptions, and complete implicit subjects. Without modifying the overall structure, still following the three parts of background, people, and functions, output a formatted requirements document." This process ultimately yields the structured requirements document. In this embodiment, the "Background" section of the formatted requirements document output by the large model is: "The student course selection system is used to support the school in managing the basic information of students, teachers and courses, and to realize online course selection for students and course teacher allocation." The "Characters" section is: "System Administrator", "Student", "Teacher". The "Functions" section will be generated based on the content of the "Characters" section, such as: "System Administrator adds teacher" and "System Administrator adds course".

[0023] S2. Based on the formatted requirements document, extract several tactical elements, cluster these tactical elements into several aggregates and unclustered tactical elements; cluster these aggregates and unclustered tactical elements into several subdomains, and supplement these subdomains with domain services to form the initial version of the DDD model. Step S2 is as follows: (1) Input the formatted requirements document into the large language model, and extract several tactical elements according to the definition of tactical elements in domain-driven design. The tactical elements include: entities and value objects. (2) Several tactical elements are clustered into several aggregates and unclustered tactical elements based on the semantic similarity and dependency coupling between the tactical elements by using a large language model. Each aggregate contains at least one entity, and the entity in the core of the business in the aggregate is called the aggregate root. (3) Several aggregated and unclusterable tactical elements are clustered into several subdomains based on semantic similarity and dependency coupling degree using a large language model; (4) Based on the content and formatted requirements documents of several subdomains, domain services are added to each subdomain through the large language model. The domain service is an object that carries domain logic but is not suitable to be attributed to any entity or value object. All subdomains after adding domain services together form the initial version of the DDD model.

[0024] In this embodiment, the definition of tactical elements in Domain-Driven Design is as follows: An entity is a domain object with a unique identifier whose continuity is determined by identity rather than attributes, used to represent core business objects with lifecycles and state changes; while a value object is an object without a unique identifier, whose equality is determined by attribute values, used to characterize the attribute features of business concepts, and is usually designed to be immutable and entirely replaceable. For example, "student" is an entity, uniquely identified by "student ID," and its identity does not change due to changes in name or grade. "Class time" is a value object; it has no unique identifier and consists only of the day of the week and the time period.

[0025] In this embodiment, a formatted requirements document is input into the deepseek-r1 model. The prompt message is "Please extract tactical elements from the provided formatted requirements document according to the definition of tactical elements in domain-driven design. The tactical elements include entities and value objects." Several tactical elements are obtained, such as "student", "teacher", "system administrator", "course", "class time", and "class location".

[0026] In this embodiment, a series of tactical elements are input into the deepseek-r1 model. The prompt is "Please cluster the input series of tactical elements into several aggregates based on the semantic similarity and dependency coupling between the tactical elements according to the relevant ideas of domain-driven design. If a certain tactical element cannot or is not suitable to form an aggregate, it is regarded as a tactical element that cannot be clustered. Each aggregate contains at least one entity." Several aggregates and tactical elements that cannot be clustered are obtained. For example, the "student aggregate" contains the "student" entity, which is also the aggregate root, as well as the "course selection record" entity, and the value objects "name", "contact information" and "grade".

[0027] In this embodiment, several aggregated and non-clusterable tactical elements are input into the deepseek-r1 model. The prompt word is "Please cluster the input aggregated and non-clusterable tactical elements into several subdomains based on semantic similarity and dependency coupling degree according to the relevant ideas of domain-driven design". Several subdomains are obtained, such as: "Basic data management subdomain" is responsible for managing the basic data of students, teachers and courses, and "course selection subdomain" is responsible for implementing the core functions of the system.

[0028] In this embodiment, several subdomains and a formatted requirements document are input into the DeepSeek-R1 model. The task is to "analyze the input formatted requirements document and several subdomains, and supplement the subdomains with domain services based on the principles of Domain-Driven Design." This results in subdomains with supplemented domain services. For example, the "Assign Teachers to Courses" domain service is added to the "Basic Data Management Subdomain." This domain service involves two entities, "Teacher" and "Course," and is not suitable to be attributed to any single entity, so it is added as a domain service to the "Basic Data Management Subdomain." All subdomains with supplemented domain services together form the initial version of the DDD model.

[0029] S3. Supplement the initial DDD model from the perspective of DDD strategic design, and output the final DDD model; The initial version of the DDD model is structurally reviewed and optimized to output the final DDD model. The structural review and optimization include: identifying and eliminating overlapping aggregation boundaries, correcting unreasonable subdomain partitioning, adjusting dependencies between subdomains to prevent circular dependencies, and discovering and resolving rule conflicts of domain services across subdomains, thereby improving the cohesion of the initial version of the DDD model and the system's evolutionary capability.

[0030] In this embodiment, the initial version of the DDD model is input into the deepseek-r1 model. The prompt message is: "Based on the principles of Domain-Driven Design, please conduct a structural review and optimization of the input initial version of the DDD model from a strategic perspective. The review and optimization should focus on the following four aspects: identifying and eliminating overlapping aggregation boundaries, correcting unreasonable subdomain partitioning, adjusting dependencies between subdomains to prevent circular dependencies, and discovering and resolving rule conflicts between cross-subdomain domain services." This yields the final DDD model. For example, in the initial version of the DDD model, "course selection records" are placed within both the "student aggregation" and the "course aggregation." This design results in the same business concept, "course selection records," being managed by two aggregations simultaneously, leading to a significant aggregation boundary overlap problem. Therefore, deepseek-r1 adjusts the aggregation structure, clarifying that the lifecycle of "course selection records" primarily depends on student behavior and is only retained within the "student aggregation." This adjustment resolves the aggregation boundary overlap problem.

[0031] S4. Generate project code and several test cases based on the final DDD model, and combine them into complete project code; The final DDD model is input into the large language model, which then generates corresponding project code and several test cases based on the final DDD model. The test cases are mainly used to check whether the code implementing domain services in the project code can run normally. The project code and several test cases are combined into complete project code.

[0032] In this embodiment, the final DDD model is input into the deepseek-coder-v2 model to generate Java code. The prompt message is: "Please generate the corresponding Java code based on the input final DDD model. The code consists of two parts: one part is the project code corresponding to the final DDD model, and the other part is several test cases to test whether the domain services in the test project code can run normally." This results in the deepseek-coder-v2 model outputting the corresponding project code and several test cases for the final DDD model. For example, based on "Student Aggregation" in the "Basic Data Management Subdomain," the "Student" class and "StudentService Test" class are generated; based on the domain service "Assign Teachers to Courses" in the "Basic Data Management Subdomain," the "TeachingResourceService" class and "TeachingResourceServiceTest Test" class are generated.

[0033] S5. Test based on the complete project code; If the test is successful, obtain the code that passed the test; If a test fails, patch the entire project code and retest until the test passes and you obtain code that passes the test. Step S5 is as follows: (1) The complete project code and its required runtime environment are packaged by a code packaging tool to generate a deployable container image. The runtime environment includes: third-party libraries and system dependencies required for the code to run. (2) Push the deployable container image to the deployment environment through the image repository, run all test cases, and collect test results; (3) If all test results are normal, the complete project code is the code that has passed the test; (4) If the test results are abnormal, the complete project code is repaired by generating a large language model through code, and all test cases are retested until the test results are all normal, and the code that passes the test is obtained.

[0034] In this embodiment, Docker container technology is used to encapsulate the complete runtime code and its required third-party libraries and system dependencies, generating a deployable container image, which is then pushed to the deployment environment through an image repository. In this embodiment, the deployment environment is a cloud server environment based on the Linux operating system. The corresponding service instance is started using container run instructions, putting the system into a running state capable of providing functional services, running all test cases, and collecting test results.

[0035] In this embodiment, if all test results are normal, the complete project code is the code that has passed the test. If the test results are abnormal, the exception report corresponding to the abnormal test case and the complete project code are input into the deepseek-coder-v2 model. The model analyzes the exception report and modifies the complete project code. There are two scenarios: one is that an error occurs in the project code generated by the final DDD model, and the other is that the test case itself has an error. For the former error, the deepseek-coder-v2 model needs to repair the error in the project code generated by the final DDD model and update the test cases simultaneously. Then, all test cases are retested until all test results are normal, resulting in the code that has passed the test. For the latter error, the deepseek-coder-v2 model only needs to repair the test cases and then retest all test cases until all test results are normal, resulting in the code that has passed the test. For example, the test case "EnrollmentServiceTest" corresponding to the domain service "EnrollmentService" in the "Course Selection Subdomain" fails, and the exception report indicates: "Students are allowed to select courses again even after successfully selecting courses." After analyzing the exception, the model identifies: The issue stemmed from a missing business logic in the "enroll" method of "EnrollmentService," which failed to verify whether students had already selected the same course. The deepseek-coder-v2 model resolved the exception by modifying the code of the "enroll" method to complete the missing business logic.

[0036] S6. Analyze the code that passed the test, extract the DDD model from the code perspective, compare the DDD model from the code perspective with the final DDD model, and output a difference report. Step S6 is as follows: (1) Input the code that passed the test into the large language model, and extract the following in order: subdomain, domain service, aggregate, entity, and value object to form a DDD model from the code perspective; (2) Input the code-perspective DDD model, the final DDD model and the tested code into the large language model, compare the code-perspective DDD model and the final DDD model and output a difference report. The difference report consists of several difference points, including: difference content and whether the code needs to be modified.

[0037] In this embodiment, the tested code is input into the Deepseek-r1 model. The prompt message is "Based on Domain-Driven Design principles, extract a code-perspective DDD model from the provided Java code, including: subdomains, domain services, aggregates, entities, and value objects." This yields the code-perspective DDD model. Then, a difference report is generated by comparing the code-perspective DDD model with the final DDD model using a large language model. This report consists of several differences, including: the content of the differences and whether code modifications are needed. Since DDD models rely on human experience, the code-perspective DDD model and the final DDD model cannot be completely identical. Finding these differences essentially involves identifying any domain services in the final DDD model that are not implemented in the code.

[0038] In this embodiment, the code-perspective DDD model, the final DDD model, and the tested code are input into deepseek-r1. A discrepancy report is generated using the prompt: "Using the tested code as supplementary data, compare the code-perspective DDD model and the final DDD model, and output a discrepancy report containing several discrepancies. Each discrepancy consists of the discrepancy content and whether code modification is required." This results in a discrepancy report containing several discrepancies, for example: "Differences: In the final DDD model, the 'Course aggregation' is designed as an independent aggregation; while in the code-perspective DDD model, the Course class is used as a regular entity, without reflecting clear aggregation boundary control logic."

[0039] Code modification required: No. The current system is small in scale and does not involve complex consistency constraints across aggregates. This difference does not affect the correctness of domain behavior and is a reasonable engineering simplification. S7. Based on the difference report, determine whether the code that passed the test needs to be updated; If not, output the code that passed the test; If so, update the code that passed the test to form a new complete project code, and repeat steps S5~S6 until it is no longer necessary to update the code that passed the test, and output the code that passed the test.

[0040] Step S7 is as follows: (1) Input the difference report into the large language model and analyze whether the code that passed the test needs to be updated; (2) If the code that passed the test does not need to be updated, then end; (3) If it is necessary to update the code that has passed the test, the code that has passed the test is updated by generating a large language model to form a new complete project code, and steps S5~S6 are repeated until it is no longer necessary to update the code that has passed the test. At this time, the code that has passed the test is the final output.

[0041] In this embodiment, the difference report is input into the deepseek-r1 model to determine whether the code that passed the test needs to be updated. If the code that passed the test does not need to be updated, the process ends. If the code that passed the test needs to be updated, the difference report and the code that passed the test are input into the deepseek-coder-v2 model. The prompt message is "Please analyze the code that passed the test and modify the code corresponding to the differences in the difference report." This generates new project code and test cases, forming a new complete project code. Steps S5 and S6 are repeated, i.e., the new complete project code is repackaged and the test cases are run to generate a new difference report. If none of the differences in the report require code modification, the process ends, and the code that passed the test at this point is the final output.

[0042] Example 2 A software-automated design apparatus based on DDD, comprising: Input module 1 is used to receive the user's requirement document, and perform formatting and structuring processing to obtain a formatted requirement document; The first generation module 2 is used to extract several tactical elements based on the formatted requirements document, cluster the several tactical elements into several aggregates and unclustered tactical elements; cluster the several aggregates and unclustered tactical elements into several subdomains, and supplement the domain services in the several subdomains to form the initial version of the DDD model. Supplementary Module 3 is used to supplement the initial version of the DDD model from the perspective of DDD strategic design, and output the final DDD model; The second generation module 4 is used to generate project code and several test cases based on the final DDD model, and combine them into complete project code; Test module 5 is used to test the complete project code; if the test is normal, the code that passes the test is obtained; if the test is abnormal, the complete project code is patched and retested until the test is normal and the code that passes the test is obtained. Analysis module 6 is used to analyze the code that passed the test, extract the DDD model from the code perspective, compare the DDD model from the code perspective with the final DDD model, and output a difference report; Module 7 is used to determine whether the code that has passed the test needs to be updated based on the difference report. If not, the code that has passed the test is output. If so, the code that has passed the test is updated to form a new complete project code. The test module and analysis module are repeated until the code that has passed the test no longer needs to be updated, and then the code that has passed the test is output.

[0043] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0044] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0045] Accordingly, this application also provides an electronic device, including: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors perform the methods described above.

[0046] Accordingly, this application also provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of any of the above methods.

[0047] In the embodiments provided in this application, it should be understood that the disclosed methods and systems can also be implemented in other ways. The method and system embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0048] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0049] On the other hand, a computer-readable storage medium stores computer instructions thereon, which, when executed by a processor, implement the steps of the above-described method. When the computer program is executed by the processor, it implements the method as described in any of the first aspects above. If the function is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0050] 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 automatic design method based on DDD, characterized in that, Includes the following steps: S1. Receive the user's requirements document, and perform formatting and structuring processing to obtain a formatted requirements document; S2. Based on the formatted requirements document, extract several tactical elements, cluster these tactical elements into several aggregates and unclustered tactical elements; cluster these aggregates and unclustered tactical elements into several subdomains, and supplement these subdomains with domain services to form the initial version of the DDD model. S3. Supplement the initial DDD model from the perspective of DDD strategic design, and output the final DDD model; S4. Generate project code and several test cases based on the final DDD model, and combine them into complete project code; S5. Test based on the complete project code; If the test is successful, obtain the code that passed the test; If a test fails, patch the entire project code and retest until the test passes and you obtain code that passes the test. S6. Analyze the code that passed the test, extract the DDD model from the code perspective, compare the DDD model from the code perspective with the final DDD model, and output a difference report. S7. Based on the difference report, determine whether the code that passed the test needs to be updated; If not, output the code that passed the test; If so, update the code that passed the test to form a new complete project code, and repeat steps S5~S6 until it is no longer necessary to update the code that passed the test, and output the code that passed the test.

2. The method according to claim 1, characterized in that, Step S1 is as follows: (1) Receive the requirement document input by the user, perform text parsing on the requirement document through the large language model, extract and reorganize the content to form a structured requirement document; (2) The structured requirements document is formatted by a large language model. The formatting process includes: unifying the terminology dictionary, removing redundant descriptions, and completing implicit subjects to form a formatted requirements document.

3. The method according to claim 1, characterized in that, Step S2 is as follows: (1) Input the formatted requirements document into the large language model, and extract several tactical elements according to the definition of tactical elements in domain-driven design. The tactical elements include: entities and value objects. (2) Several tactical elements are clustered into several aggregates and unclustered tactical elements based on the semantic similarity and dependency coupling between the tactical elements by using a large language model. Each aggregate contains at least one entity, and the entity in the core of the business in the aggregate is called the aggregate root. (3) Several aggregated and unclusterable tactical elements are clustered into several subdomains based on semantic similarity and dependency coupling degree using a large language model; (4) Based on the content and formatted requirements documents of several subdomains, domain services are added to each subdomain through the large language model. The domain service is an object that carries domain logic but is not suitable to be attributed to any entity or value object. All subdomains after adding domain services together form the initial version of the DDD model.

4. The method according to claim 1, characterized in that, Step S3 is as follows: The initial version of the DDD model is structurally reviewed and optimized to output the final DDD model. The structural review and optimization include: identifying and eliminating overlapping aggregation boundaries, correcting unreasonable subdomain partitioning, adjusting dependencies between subdomains to prevent circular dependencies, and discovering and resolving rule conflicts of domain services across subdomains, thereby improving the cohesion of the initial version of the DDD model and the system's evolutionary capability.

5. The method according to claim 1, characterized in that, Step S5 specifically involves: (1) Encapsulating the complete project code and its required runtime environment using a code packaging tool to generate a deployable container image, wherein the runtime environment includes: third-party libraries and system dependencies required for code runtime; (2) Push the deployable container image to the deployment environment through the image repository, run all test cases, and collect test results; (3) If all test results are normal, the complete project code is the code that has passed the test; (4) If the test results are abnormal, the complete project code is repaired by generating a large language model through code, and all test cases are retested until the test results are all normal, and the code that passes the test is obtained.

6. The method according to claim 1, characterized in that, Step S6 is as follows: (1) Input the code that passed the test into the large language model, and extract the following in order: subdomain, domain service, aggregate, entity, and value object to form a DDD model from the code perspective; (2) Input the code-perspective DDD model, the final DDD model and the tested code into the large language model, compare the code-perspective DDD model and the final DDD model and output a difference report. The difference report consists of several difference points, including: difference content and whether the code needs to be modified.

7. The method according to claim 1, characterized in that, Step S7 is as follows: (1) Input the difference report into the large language model and analyze whether the code that passed the test needs to be updated; (2) If the code that passed the test does not need to be updated, then end; (3) If it is necessary to update the code that has passed the test, the code that has passed the test is updated by generating a large language model to form a new complete project code, and steps S5~S6 are repeated until it is no longer necessary to update the code that has passed the test. At this time, the code that has passed the test is the final output.

8. A software-automated design device based on DDD, characterized in that, include The input module is used to receive the user's requirement document, and perform formatting and structuring processing to obtain a formatted requirement document; The first generation module is used to extract several tactical elements based on the formatted requirements document, and to cluster these tactical elements into several aggregates and unclustered tactical elements. Several aggregated and non-clusterable tactical elements are clustered into several subdomains, and domain services are added to these subdomains to form an initial version of the DDD model. The supplementary module is used to supplement the initial version of the DDD model from the perspective of DDD strategic design, and output the final DDD model; The second generation module is used to generate project code and several test cases based on the final DDD model, and combine them into complete project code; The testing module is used to test the complete project code; if the test is successful, the code that passed the test is obtained. If a test fails, patch the entire project code and retest until the test passes and you obtain code that passes the test. The analysis module is used to analyze the code that has passed the test, extract the DDD model from the code perspective, compare the DDD model from the code perspective with the final DDD model, and output a difference report. The judgment module is used to determine whether the code that has passed the test needs to be updated based on the difference report. If not, the code that has passed the test is output. If so, the code that has passed the test is updated to form a new complete project code, and the steps of the test module and the analysis module are repeated until the code that has passed the test no longer needs to be updated, and the code that has passed the test is output.

9. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-7.

10. A computer-readable storage medium storing computer instructions thereon, characterized in that, When executed by the processor, this instruction implements the steps of the method as described in any one of claims 1-7.

Images