System architecture automatic design method based on domain-specific language

Abstract

The invention relates to a system architecture automatic design method based on a domain-specific language (DSL). The method comprises the following steps: S1, constructing a DSL file definition system; s2, carrying out service DSL (Digital Subscriber Line) modeling; s3, judging whether expansion is needed or not, if so, turning to S4 after expansion, otherwise, directly turning to S4; s4, after the participants are determined, performing logic writing on the process and the process steps; s5, carrying out system architecture DSL (Digital Subscriber Line) modeling; s6, judging whether the integration point needs to be expanded or defined, if so, turning to S7 after expansion or definition, and otherwise, directly turning to S7; s7, compiling components, interfaces and constraints in detail; s8, binding and mapping business and system architecture field elements; and S9, carrying out automatic analysis, verification and reasoning by adopting a DSL analysis engine, generating a framework blueprint, if abnormity exists in the verification process or business requirements change, turning to S3, and otherwise, directly outputting the framework blueprint and an interface document. Compared with the prior art, the method has the advantages of high design efficiency, high expandability, high accuracy and the like.

Description

Technical Field

[0001] The present invention relates to the field of system architecture design automation, and in particular to a system architecture automation design method based on a domain specific language. Background Art

[0002] The traditional document-driven approach combines graphical modeling and prototyping, generating various documents through multiple steps, including business analysis and requirements design. These documents, models, and prototypes are then used to communicate with different personnel. Requirements analysts conduct research and produce business plans and requirements documents. These analysts then collaborate with architecture experts and development engineers to produce architecture and detailed technical design documents, which developers then use to develop the system. This approach has significant drawbacks: low efficiency, cumbersome manual operations, and tedious document management; difficult communication, with barriers to understanding between different roles and high communication costs; slow iterations and error-prone updates; insufficient automation; over-reliance on individual experience; and a lack of effective feedback mechanisms, making it difficult to adapt to project and market changes.

[0003] Therefore, there is an urgent need to design a new method for automated system architecture design that can effectively overcome the above-mentioned defects, thereby improving design efficiency, scalability and accuracy. Summary of the Invention

[0004] The purpose of the present invention is to overcome the defects of the above-mentioned prior art and provide a system architecture automation design method based on domain-specific language with high design efficiency, strong scalability and high accuracy.

[0005] The purpose of the present invention can be achieved by the following technical solutions:

[0006] The present invention provides a system architecture automation design method based on a domain-specific language, comprising:

[0007] S1. Build a domain-specific language DSL file definition system based on the adaptive Schema mechanism;

[0008] S2. Based on business requirements, define the system through description files to perform business DSL modeling. Business domain elements include participants, processes, and process steps.

[0009] S3: Determine whether the business domain elements and Schema need to be expanded. If so, expand them and then go to S4; otherwise, go directly to S4.

[0010] S4. After determining the participants, logically write the process and process steps;

[0011] S5. Define the system through description files to perform system architecture DSL modeling. The system architecture domain elements include components, interfaces and constraints.

[0012] S6. Determine whether it is necessary to expand the system architecture domain elements or define integration points. If necessary, expand or define them and then go to S7. Otherwise, go directly to S7.

[0013] S7. Detailed writing of components, interfaces and constraints;

[0014] S8. Bind and map business domain elements and system architecture domain elements;

[0015] S9: Use the DSL parsing engine to automatically parse, verify, and infer the business DSL file and system architecture DSL file to generate an architecture blueprint. If there is an exception in the verification process or the business requirements change, go to S3; otherwise, directly output the architecture blueprint and interface document.

[0016] Preferably, in the domain-specific language DSL file definition system based on the adaptive Schema mechanism, JSON is used as the structure definition of the syntax Schema, and Markdown text language is used as the description of the domain-specific language DSL.

[0017] Preferably, a change awareness plug-in is integrated into the DSL editor of the domain-specific language DSL file definition system based on the adaptive Schema mechanism, which is used to monitor the addition, deletion and modification of DSL text and Schema in real time. After each modification of the DSL text, the DSL parsing engine will immediately verify it, and visually display the verification results and update the architecture blueprint.

[0018] Preferably, the domain-specific language DSL file definition system based on the adaptive Schema mechanism pre-defines a regularly updated participant library, process step library, business process library, component library, interface library and constraint library for calling during business DSL modeling and system architecture DSL modeling; it allows custom elements to be declared during the DSL modeling process, and the custom elements are mapped to the Schema structure by setting tags, and the DSL parsing engine automatically completes and verifies the mapping.

[0019] Preferably, the DSL parsing engine adopts a multi-level pipeline setting, and its automatic parsing verification process includes sequentially performing syntax legality verification, text structure matching verification and multi-dimensional constraint verification. The text structure matching verification process also includes implicit constraint identification.

[0020] Preferably, the DSL parsing engine is used to automatically parse, verify, and infer the business DSL file and the system architecture DSL file to generate an architecture blueprint, including:

[0021] S901. Input the business DSL file and the system architecture DSL file;

[0022] S902. Automatically identify and load the schema version corresponding to the DSL file; wherein each DSL instance is automatically associated with a unique schema version identifier;

[0023] S903, Syntax validity check: Use the adaptive grammar analyzer to check the basic writing standards of the DSL file according to the grammatical rules generated by the schema;

[0024] S904, Text Structure Matching Verification: Verify that the text structure of the DSL file is consistent with the Schema definition, check the integrity and hierarchical relationships of process, component, and interface elements, analyze the semantic relationships between business elements and system elements through the embedded domain knowledge base, and automatically identify implicit constraints between business processes and components;

[0025] S905, Multi-dimensional constraint verification: Comprehensive verification of various constraints in the DSL file;

[0026] S906, model layer mapping: generate a bidirectional mapping table between business elements and system elements;

[0027] S907: Automatically generate a multi-perspective architecture blueprint based on the parsed and verified mapping information, wherein the multi-perspective architecture blueprint includes a business process diagram, a component interaction diagram, an interface association diagram, and a constraint relationship diagram.

[0028] Preferably, the implicit constraints between the business process and system components include data flow, permissions and dependencies.

[0029] Preferably, the process of binding and mapping the business domain elements and the system architecture domain elements explicitly defines the mapping relationship between the business process and the components through the `bind` keyword.

[0030] Preferably, if there is an abnormality in the verification process or the business requirements have changed, then go to S3, otherwise directly output the architecture blueprint. Specifically: if an abnormality is detected during the parsing process, locate the abnormal context, and automatically generate repair suggestions based on the historical domain knowledge base and rule base, then go to S3; if there is no abnormality in the verification process but the business requirements have changed, then go to S3, otherwise directly output the architecture blueprint.

[0031] Preferably, the DSL parsing engine is a modular and plug-in architecture with an open API interface, allowing third-party developers to extend the domain knowledge base, rule base or visualization template.

[0032] Compared with the prior art, the present invention has the following beneficial effects:

[0033] (1) Significantly improved flexibility and scalability: Based on the adaptive Schema mechanism, it supports real-time adjustment and personalized expansion of business scenarios. It can respond to changes in demand without a fixed structure, allowing the system architecture to evolve rapidly with business development, reducing the number of reconstructions and deployment costs.

[0034] (2) High degree of automation and intelligence: The DSL parsing engine can automatically verify, infer, and generate architecture blueprints, achieving integrated design and implementation, effectively reducing manual operations and error rates, and improving the level of automation in development and operation and maintenance.

[0035] (3) Enhanced maintainability and agility: When an anomaly occurs during the verification process, the DSL parsing engine can locate the anomaly context and automatically generate repair suggestions based on historical data and rule base, which facilitates subsequent maintenance and rapid response to business changes, thus shortening the architecture evolution cycle and reducing maintenance difficulty and risks in the long term.

[0036] (4) Lowering the threshold for communication and collaboration: Business and system DSL modeling is performed through the DSL file definition system, and the architecture blueprint is automatically generated after verification by the DSL parsing engine. Combined with automatic verification and instant feedback, non-technical business personnel can also participate in architecture design efficiently, thereby promoting cross-departmental collaboration, reducing information loss, and accelerating the implementation of requirements.

[0037] (5) Architectural consistency and quality assurance: Strong correlation modeling between elements automatically synchronizes business and system data at all levels, reducing human errors, improving overall system consistency, and enhancing design reliability.

[0038] (6) Strong reusability and industry adaptability: Based on custom element types, templates and reuse library mechanisms, it supports rapid migration and implementation in multiple industries and scenarios; greatly improves the solution reuse rate and reduces the adaptation and development costs of new scenarios.

[0039] (7) Improved collaboration and transparency: By automatically generating visual architecture blueprints and interface documents, supporting multi-source integration and multi-person collaborative editing, project management efficiency is improved and team collaboration transparency is enhanced.

[0040] (8) Good scalability and future compatibility: The DSL parsing engine adopts a plug-in and modular design, which is easy to access new technology stacks, supports continuous system evolution, and reduces technical debt. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 is a flow chart of the method of the present invention;

[0042] Figure 2 A flowchart of a system architecture design method in an embodiment;

[0043] Figure 3Implement and parse flow charts for the DSL parsing engine;

[0044] Figure 4 Iterative flow chart for system engineering. DETAILED DESCRIPTION

[0045] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0046] Example

[0047] This paper provides an automated IT system architecture design method based on a domain-specific language (DSL). This method aims to simplify the design process, improve design efficiency, and facilitate cross-domain team collaboration. Systematic innovations have been made in key aspects such as DSL design philosophy, syntax structure, element coupling, and automated parsing engine, aiming to achieve deep integration of business and technology and automated architecture generation throughout the entire process.

[0048] 1. DSL syntax and structure design

[0049] Using JSON as the syntax for schema structure and Markdown as the DSL description language offers the following advantages: Schema definitions are extended and defined by dedicated system architecture engineers, using a strict syntax to describe model elements, attributes, actions, interactions, and data. Markdown, on the other hand, directly uses these definitions and is defined by business experts to describe existing business needs and scenarios. Combining these two creates a complete DSL-based description file definition system.

[0050] Innovations in syntax and structural design include adaptive schema mechanisms, semantic validation, and automatic generation:

[0051] 1. Adaptive Schema Mechanism

[0052] Traditional DSL designs typically rely on fixed schemas, which limits their applicability in different business scenarios. This paper defines the structure of a DSL through an adaptive schema mechanism. This mechanism allows architects to dynamically define the schema based on specific business requirements, making the DSL text more flexible and scalable.

[0053] 1.1 Dynamic Schema Definition and Version Management

[0054] Schema management mechanism that supports dynamic expansion: Architects can flexibly add, modify, or cancel the schema definitions of domain elements (such as processes, components, interfaces, constraints, etc.) at different stages of the project through a visual interface or DSL commands.

[0055] Supports parallel maintenance of multiple schema versions. Each DSL instance is automatically associated with a unique schema version identifier, and the parsing engine can automatically migrate old DSL text based on historical schema versions to ensure system evolvability.

[0056] The innovation lies in the fact that the Schema data model not only supports structural hierarchical expansion, but also supports the dynamic injection of constraints and data types. For example, it allows the dynamic addition of customized performance constraints and compliance checks to a business process node at runtime.

[0057] For example: Use the `defineSchema` keyword to define a new Schema.

[0058] 1.2. Self-service mapping between schema and business domain

[0059] It allows users to directly declare custom elements in the business DSL and map them to the Schema structure through special tags (such as @custom-type). The parsing engine automatically completes and verifies the mapping relationship.

[0060] The Schema Template Library enables rapid reuse of common industry models. Users only need to incrementally write differentiated elements based on the templates, significantly reducing duplication of effort. This solves the traditional DSL problem of engineers manually extending the schema to meet business changes, enabling seamless collaboration between business and technical teams.

[0061] 2. Specific implementation of semantic verification and automatic generation of system architecture

[0062] The DSL parsing engine automatically verifies the structure of the DSL text and its schema, and generates a corresponding system architecture blueprint. This not only lowers the learning threshold for DSL but also increases the depth of engagement for business experts, allowing business changes to be immediately fed back to the architecture layer. The specific implementation is as follows:

[0063] 2.1. Multi-level semantic verification engine

[0064] The parsing engine is designed as a multi-level pipeline structure: first perform basic syntax analysis → structure verification → semantic reasoning → constraint consistency check.

[0065] During the verification process, the parsing engine will automatically identify the dependencies and constraints between elements (such as step dependencies in business processes, data flow between components, interface call chains, etc.), and highlight and provide correction suggestions for unreasonable configurations (such as circular dependencies, undefined references, and constraint conflicts).

[0066] The introduction of the semantic reasoning module can automatically identify implicit constraints in business logic (such as the requirement that a certain link must be executed serially, the isolation of permissions when certain data is shared between different processes, etc.), and map these high-level business rules into specific implementation logic on the system architecture blueprint.

[0067] 2.2. Automatic Architecture Blueprint Generation

[0068] After grammatical and semantic analysis, the system can automatically generate a multi-perspective architecture blueprint, including: business process diagram, system component interaction diagram, interface association diagram, constraint relationship diagram, etc.

[0069] Blueprint generation uses a pluggable template mechanism, supports output in multiple standard formats (such as UML, BPMN, OpenAPI, etc.), and can be embedded in the version control system to achieve linkage between architecture, code, and deployment documents.

[0070] Supports iterative generation and backtracking of blueprints: After each DSL or Schema update, the parsing engine can automatically compare the change points, generate differentiated blueprints and change suggestions, and assist architects in making quick decisions.

[0071] 3. Real-time feedback and human-machine collaboration mechanism

[0072] A real-time feedback plug-in is integrated into the DSL editor. Every time the user modifies the DSL text, the parsing engine immediately verifies its legality and rationality, and displays the verification results in a visual way.

[0073] It supports automatic repair suggestions and one-click application, greatly improving team collaboration efficiency and DSL usability.

[0074] 2. Core Concept and Element Design

[0075] The design of core concepts and elements requires the design of two sets of core concepts and fields when designing IT system architecture using attributive specific languages.

[0076] BusinessDomain: defines the business domain, including business description, business participants, and business processes;

[0077] SystemArchitectureDomain: defines the system architecture domain, including system description, system components, data flow, and system constraints.

[0078] Based on two sets of core concepts and domains, the following elements are designed:

[0079] Actor: A participant in the business domain, such as an employee or customer. It can also be a group, such as a department or a company.

[0080] Process: A business process consists of a series of steps and actions. Processes can be nested to build a complete business process.

[0081] Step: A step in a business process. Each step consists of a single action and input and output.

[0082] Component: A component in the system. Any element in the system architecture design can be described as a component, such as data, interface, interaction, service, etc.

[0083] Constraint: system constraints, such as data verification, security requirements, performance constraints, etc.

[0084] Interfaces: The interface types provided or required by the component;

[0085] To further enhance creativity and take into account scalability and integration, the present invention introduces the following innovative elements:

[0086] Custom Types: Allows you to define your own types, whether they are business processes, business elements or system design components;

[0087] Libraries: A library of predefined business processes and system components. You can define a designed business process as a library for reuse.

[0088] Integration Point: Define system integration interfaces and protocols

[0089] The coupling and collaborative relationship between these innovative elements is as follows:

[0090] Dynamic mapping of business processes and system components: The `bind` keyword is used to explicitly define the mapping relationship between business process steps and system component interfaces, achieving deep integration of business and technology.

[0091] Cross-domain constraints: Constraints are not limited to static properties, but also support dynamic constraints such as timing, performance, and security. The parsing engine can perform automatic consistency detection.

[0092] System integration points: Standardize the description of system integration points to achieve automatic dependency detection and interface document generation.

[0093] 3. DSL Parsing Engine Design and Implementation

[0094] The DSL parsing engine of the present invention is the core of the entire system. It undertakes and implements syntax and structure design, and uses related concepts and elements. The main design and implementation are:

[0095] 1. Innovation of multi-level analysis architecture

[0096] 1.1 Syntax Parsing

[0097] Adopting an adaptive grammar analyzer, it can instantly generate grammar verification rules based on dynamic Schema descriptions and support DSL grammar expansion in real time.

[0098] An "incremental syntax engine" has been added to support local verification of large-scale DSL documents and rapid location of changes, improving response speed and user experience.

[0099] The original syntax error tracing algorithm can accurately indicate the error context and related Schema fragments, facilitating quick correction.

[0100] 1.2 Semantic Analysis

[0101] Introducing the domain association reasoning module: Through the embedded domain knowledge base, it automatically identifies the implicit coupling relationship between business processes and system components (such as data flow, permissions, dependencies, etc.).

[0102] Supports multi-dimensional constraint verification: not only verifies structural consistency, but also determines complex semantics such as process sequence, data consistency, and interface compatibility.

[0103] For custom elements, custom rule plug-ins are dynamically loaded to ensure accurate semantic parsing in business innovation scenarios.

[0104] 1.3 Model Mapping

[0105] An innovative "bidirectional mapping table" mechanism is adopted: all business processes and system components generate unique mapping relationship tables, and support reverse queries (i.e. inferring business impact from system architecture, and vice versa).

[0106] Automatically maintain the "change tracking chain": For every DSL change, the parsing engine generates a change impact matrix, allowing architects to accurately control the scope of impact.

[0107] Supports "multi-model collaboration": DSL can be automatically converted into multiple modeling specifications (such as UML, BPMN, OpenAPI, etc.) to achieve output diversification.

[0108] 2. Innovative function implementation details

[0109] 2.1 Dynamic Mapping and Backtracking Mechanism

[0110] The parsing engine has a built-in "change sensor" that monitors the addition, deletion, and modification of DSL text and Schema in real time, and automatically identifies impact chains and dependencies.

[0111] For key operations such as process adjustments and component changes, comparison reports and update suggestions are automatically generated, supporting one-click application or rollback to ensure agile architecture evolution.

[0112] Synchronously update dependent interface documents, blueprints, and constraint descriptions to ensure that the documents are consistent with the architecture in real time.

[0113] 2.2. Automated Error Detection and Repair Suggestions

[0114] Adopting the "intelligent conflict detection engine", it automatically identifies complex errors such as circular dependencies, undefined references, and constraint conflicts based on the rule base and historical data.

[0115] For detected errors, the analysis engine can generate context-sensitive repair suggestions and support users to apply them with one click or make custom modifications.

[0116] Supports "self-learning mechanism": As the team uses it, the error detection and suggestion library is continuously enriched, and the intelligence level of the parsing engine is continuously improved.

[0117] 2.3 Multi-source integration and visualization output

[0118] It supports horizontal integration of multiple DSL source files, automatically merges business processes, system components, interface definitions, etc., and solves the problem of distributed team collaboration.

[0119] The built-in "visual generation engine" can automatically convert the parsed architecture model into multiple views such as flowcharts, dependency diagrams, component structure diagrams, etc., and supports exporting to SVG, PNG, PDF and other formats.

[0120] The "output template library" can be customized to meet the output requirements of different industry standards and corporate specifications.

[0121] 3. Technical implementation details and innovations

[0122] 3.1 Rule-based association reasoning

[0123] The parsing engine builds a rule engine subsystem that supports the parallel implementation of domain rules and custom rules, flexibly responding to business innovation scenarios. All associated reasoning processes are traceable, supporting backtracking analysis and model review, facilitating auditing and optimization.

[0124] 3.2 Dependency Graph Generation

[0125] Graph databases (such as Neo4j) are used to automatically manage multi-dimensional dependencies across business processes, components, interfaces, and constraints, enabling visualization and querying of complex structures. Dependency path analysis and critical path highlighting are supported to assist decision makers in identifying bottlenecks and optimization points.

[0126] 3.3 Plug-in design

[0127] The parsing engine adopts a modular and plug-in-based architecture, facilitating the integration of specialized parsing and modeling plug-ins for modern architectural styles such as microservices and serverless. An open API allows third-party developers to extend the domain knowledge base, rule base, or visualization templates, forming a closed ecosystem.

[0128] like Figure 1 and Figure 2 As shown, the automated design method for IT system architecture based on the domain-specific language DSL of this embodiment includes:

[0129] S1. Build a domain-specific language DSL file definition system based on the adaptive Schema mechanism;

[0130] S2. Based on business requirements, the system is defined through description files to perform business DSL modeling. Business domain elements include participants, processes, and process steps.

[0131] S3: Determine whether business domain elements and schemas need to be expanded. If so, expand them and proceed to S4; otherwise, proceed directly to S4. If new elements, processes, or roles emerge in the business scenario, the DSL schema definition can be dynamically expanded. Business elements can be incrementally added through self-service tools or command lines, increasing flexibility.

[0132] S4. After determining the participants, write the logic of the process and process steps: clarify all participants involved in the system (such as users, administrators, third parties), write the business process and each step in detail, and ensure that the business logic is fully expressed.

[0133] S5. Define the system through description files to perform system architecture DSL modeling. The system architecture domain elements include components, interfaces and constraints.

[0134] S6: Determine whether it is necessary to expand the system architecture domain elements or define integration points (such as third-party APIs, microservices, etc.). If necessary, expand or define them and then go to S7. Otherwise, go directly to S7.

[0135] Supports standardized description of integration interfaces and automatic detection of dependencies.

[0136] S7. Write components, interfaces and constraints in detail.

[0137] S8. Bind and map business domain elements and system architecture domain elements: Use keywords such as bind to map business process steps with system components to achieve the integration of business and technology.

[0138] S9: Use the DSL parsing engine to automatically parse, verify, and infer the business DSL file and the system architecture DSL file to generate an architecture blueprint. If there are exceptions in the verification process or if there are changes in business requirements or system architecture, go to S3; otherwise, directly output the architecture blueprint and interface document.

[0139] like Figure 3 As shown in the figure, the implementation and parsing process of the DSL parsing engine specifically include:

[0140] 1) Input business DSL files and system architecture DSL files. Users use an editor or automated process to input business and system architecture DSL files, including participants, processes, process steps, components, interfaces, and constraints.

[0141] 2) Automatically identify and load the schema version corresponding to the DSL file. Each DSL instance is automatically associated with a unique schema version identifier. The engine automatically identifies the schema version referenced by the DSL file, supporting adaptive schema expansion and multi-version coexistence. If business or system domains expand, the latest schema is automatically loaded or schema migration is performed.

[0142] 3) Syntax Verification: An adaptive grammar analyzer is used to check the basic writing standards of DSL files based on the grammatical rules generated by the schema. This allows for local verification and rapid location of change points, improving the efficiency of large-scale document processing.

[0143] 4) Text structure matching verification: Verify whether the text structure of the DSL file is consistent with the Schema definition, including element nesting and attribute integrity. Check the integrity and hierarchical relationships of process, component, and interface elements. Through the embedded domain knowledge base, analyze the semantic relationship between business elements and system elements, automatically identify implicit constraints between business processes and components, and automatically infer data flows, permissions, dependencies, etc.

[0144] 5) Multi-dimensional constraint verification: Comprehensively verify various constraints (timing, data, performance, security, etc.) in the DSL file to check complex business rules such as process sequence, data consistency, and interface compatibility.

[0145] 6) Domain-related reasoning: Through the "domain-related reasoning module", the specific implementation of business rules in the system architecture is automatically identified.

[0146] 7) Model-level mapping: Generates a bidirectional mapping table between business elements and system elements. This allows for business-to-system impacts and vice versa, automatically maintaining a change tracking chain and supporting change backtracking and impact analysis.

[0147] 8) Based on the parsed and verified mapping information, pluggable templates are called to automatically generate a multi-perspective architecture blueprint. The multi-perspective architecture blueprint includes business process diagrams, component interaction diagrams, interface association diagrams, and constraint relationship diagrams. The architecture blueprint can be exported to standard formats such as UML, BPMN, OpenAPI, and embedded in version management.

[0148] 9) Error tracing and intelligent repair suggestions: If an error is detected during parsing (such as circular dependencies, undefined references, and constraint conflicts), the error context is precisely located. Based on historical data and the rule base, repair suggestions are automatically generated, supporting one-click repairs or manual adjustments.

[0149] 10) Output multi-perspective architecture blueprints and interface documentation: After parsing, the system automatically generates and outputs flow charts, component diagrams, interface documentation, and more for development, testing, and maintenance. It also supports horizontal merging of multiple DSL files to enable multi-team collaboration.

[0150] Next, taking the product management system as an example, the system automation architecture design is described, including:

[0151] (1) Element design

[0152] A. Business domain elements:

[0153] Actor: Buyer, Seller, ProductAdmin, OrderProcessor

[0154] Process (business process): Product Management (product management), Order Placement (order placement), Order Processing (order processing)

[0155] Step (process step): such as Browse Product, Create Order, Payment, Shipping

[0156] B. System Architecture Domain Elements:

[0157] Component (system component): ProductService (product service), OrderService (order service), PaymentGateway (payment service)

[0158] Interface: such as GET / products, POST / orders, POST / payments, etc.

[0159] Constraint: data consistency, permission verification, performance requirements, etc.

[0160] C. Extension elements:

[0161] Custom Types: such as special products, coupons, etc.

[0162] Libraries (reuse library): standard order process, general data verification rules

[0163] Integration Point (system integration point): such as third-party payment platform docking

[0164] (2) Design process

[0165] like Figure 4 As shown in Figure 1, the iterative design process of the product management system includes:

[0166] A. Requirements Collection and Review: Organize business parties, technical personnel, and operation and maintenance personnel to conduct demand research, clarify the main requirements for product management, order placement, payment, and order processing, sort out business scenarios and roles, and form preliminary business processes;

[0167] B. Business DSL modeling: Use DSL to formally describe business participants, business processes, and business process steps, and clarify the inputs, outputs, and constraints of each business process;

[0168] C. DSL automated architecture design: Input the business DSL into the architecture design platform to automatically generate an architecture blueprint of system components, interfaces, constraints, and other components, and identify the mapping relationship between processes and system components and interfaces;

[0169] D. Automatic Verification / Inference / Blueprint Output: Automatically verifies the syntax, structure, and semantics of the DSL definition, and infers the dependencies and constraints between components. If any process errors, interface conflicts, or data inconsistencies are found, the system provides detailed feedback and returns to B for revision. After verification, the architecture blueprint is automatically output.

[0170] E. Output architecture blueprint / interface documentation: Generate visual architecture blueprints and interface documentation for use by development teams and business parties. The documentation includes system component structure diagrams, flow charts, and interface specifications.

[0171] F. Development task splitting and assignment: Based on the architecture blueprint and interface documentation, clarify the development tasks and responsible persons for each component and interface, incorporate the tasks into the project management system, and start the division of labor development;

[0172] G. Code development: Developers code based on the architecture blueprint and interface documentation generated by the DSL. The continuous integration system automatically detects code submissions and triggers automated testing.

[0173] H. Automated testing and deployment: Automatically execute unit testing, interface testing, and integration testing. After the tests pass, the system is automatically deployed to the test or pre-production environment.

[0174] I. Production environment release: After multiple rounds of testing and acceptance, the system is officially released to the production environment;

[0175] J. Demand or architecture changes: If there are new business requirements or architecture adjustments, the process will automatically return to B and iterate. If there are no changes, it will go to K.

[0176] K. Enter the project operation and maintenance phase and continuously optimize the system.

[0177] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and such modifications or substitutions are intended to be within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be subject to the scope of protection of the claims.

Claims

1. A system architecture automation design method based on domain specific language, characterized by: include: S1. Build a domain-specific language DSL file definition system based on the adaptive Schema mechanism; S2. Based on business requirements, define the system through description files to perform business DSL modeling. Business domain elements include participants, processes, and process steps. S3: Determine whether the business domain elements and Schema need to be expanded. If so, expand them and then go to S4; otherwise, go directly to S4. S4. After determining the participants, logically write the process and process steps; S5. Define the system through description files to perform system architecture DSL modeling. The system architecture domain elements include components, interfaces and constraints. S6. Determine whether it is necessary to expand the system architecture domain elements or define integration points. If necessary, expand or define them and then go to S7. Otherwise, go directly to S7. S7. Detailed writing of components, interfaces and constraints; S8. Bind and map business domain elements and system architecture domain elements; S9: Use the DSL parsing engine to automatically parse, verify, and infer the business DSL file and system architecture DSL file to generate an architecture blueprint. If there is an exception in the verification process or the business requirements change, go to S3; otherwise, directly output the architecture blueprint and interface document.

2. The method for automated system architecture design based on domain specific language according to claim 1, characterized in that: In the domain-specific language DSL file definition system based on the adaptive Schema mechanism, JSON is used as the structure definition of the syntax Schema, and Markdown text language is used as the description of the domain-specific language DSL.

3. The method for automated system architecture design based on domain specific language according to claim 1, characterized in that: The DSL editor of the domain-specific language (DSL) file definition system based on the adaptive schema mechanism is integrated with a change-aware plug-in for real-time monitoring of the addition, deletion, and modification of DSL text and schema. After each modification of the DSL text, the DSL parsing engine immediately verifies it, and visually displays the verification results and updates the architecture blueprint.

4. The method for automated system architecture design based on domain specific language according to claim 1, characterized in that: The domain-specific language DSL file definition system based on the adaptive Schema mechanism pre-defines a regularly updated participant library, process step library, business process library, component library, interface library and constraint library, which are used for calling during business DSL modeling and system architecture DSL modeling; it allows custom elements to be declared during the DSL modeling process, and the custom elements are mapped to the Schema structure by setting tags. The DSL parsing engine automatically completes and verifies the mapping.

5. The method for automated system architecture design based on domain specific language according to claim 1, characterized in that: The DSL parsing engine adopts a multi-level pipeline setting, and its automatic parsing verification process includes syntax legality verification, text structure matching verification and multi-dimensional constraint verification performed in sequence. The text structure matching verification process also includes implicit constraint identification.

6. The method for automated system architecture design based on domain specific language according to claim 5, characterized in that: The DSL parsing engine is used to automatically parse, verify, and reason about the business DSL file and the system architecture DSL file to generate an architecture blueprint, including: S901. Input the business DSL file and the system architecture DSL file; S902. Automatically identify and load the schema version corresponding to the DSL file; wherein each DSL instance is automatically associated with a unique schema version identifier; S903, Syntax validity check: Use the adaptive grammar analyzer to check the basic writing standards of the DSL file according to the grammatical rules generated by the schema; S904, Text Structure Matching Verification: Verify that the text structure of the DSL file is consistent with the Schema definition, check the integrity and hierarchical relationships of process, component, and interface elements, analyze the semantic relationships between business elements and system elements through the embedded domain knowledge base, and automatically identify implicit constraints between business processes and components; S905, Multi-dimensional constraint verification: Comprehensive verification of various constraints in the DSL file; S906, model layer mapping: generate a bidirectional mapping table between business elements and system elements; S907: Automatically generate a multi-perspective architecture blueprint based on the parsed and verified mapping information, wherein the multi-perspective architecture blueprint includes a business process diagram, a component interaction diagram, an interface association diagram, and a constraint relationship diagram.

7. The method for automated system architecture design based on domain specific language according to claim 6, characterized in that: The implicit constraints between the business processes and system components include data flows, permissions, and dependencies.

8. The method for automated system architecture design based on domain specific language according to claim 1, characterized in that: The process of binding and mapping business domain elements and system architecture domain elements explicitly defines the mapping relationship between business processes and components through the `bind` keyword.

9. The method for automated system architecture design based on domain specific language according to claim 1, characterized in that: If there is an exception in the verification process or the business requirements have changed, then go to S3; otherwise, directly output the architecture blueprint. Specifically, if an exception is detected during the parsing process, locate the exception context, and automatically generate repair suggestions based on the historical domain knowledge base and rule base, then go to S3; if there is no exception in the verification process but the business requirements have changed, then go to S3; otherwise, directly output the architecture blueprint.

10. The method for automated system architecture design based on domain specific language according to claim 1, characterized in that: The DSL parsing engine has a modular and plug-in architecture and an open API interface, allowing third-party developers to extend the domain knowledge base, rule base or visualization templates.

Images