Domain-driven design method oriented to production and warehouse management businesses

Abstract

The invention provides a production and warehouse management business-oriented domain-driven design method. The method comprises the following steps of S1, constructing a domain design standard to divide a domain and a sub-domain; and S2, carrying out aggregation division through a domain design standard. S3, realizing limit context identification through a domain design standard, dividing a service boundary based on aggregation information, and identifying a limit context; a micro service is split into an aggregation service layer and an atomic service layer, and a domain design standard is used as a division basis of the aggregation service and the atomic service. And S4, using a four-layer code architecture to develop the atomic service. And S5, realizing a cross-domain business process through micro-service arrangement. The method has the beneficial effects that by introducing an aggregation + atomic service architecture, the high-cohesion and low-coupling service design is realized, so that the system can more flexibly respond to the change of service requirements. The unified domain model is constructed by emphasizing the domain driving design, so that the data consistency among the business modules is ensured, and the integration difficulty is reduced.

Description

Technical Field

[0001] The present invention relates to the field of production and warehouse management, and more particularly to a domain-driven design method for production and warehouse management services. Background Art

[0002] At present, the project has built a certain information foundation based on the business and information status of CNOOC's smart factory development. The existing technical architecture mainly supports the operation of core businesses such as production management, warehouse management, energy and carbon management, and safety management. In terms of production management, the system can handle key business links such as demand planning, production scheduling, production dispatching, production reporting and quality inspection. Warehousing management covers raw material procurement, warehousing, inventory counting, shipping and other businesses. Energy and carbon management focuses on carbon emission management, emission reduction plan execution and cost monitoring. Safety management involves the safety management of hazardous chemicals in the production, storage, transportation and other links. On the technical level, the system adopts a traditional three-tier or multi-tier architecture, including a user interface layer, a business logic layer and a data access layer, and stores and manages data through a relational database management system (RDBMS).

[0003] Although existing technologies have supported business operations to a certain extent, they still have the following shortcomings:

[0004] 1. Lack of flexibility and scalability: Under the traditional architecture, business logic and data access are tightly coupled, making it difficult for the system to quickly respond to changes in business needs and making maintenance and upgrades highly complex.

[0005] 2. Lack of unified domain model design: Data inconsistency between business modules makes integration difficult, affecting the overall system performance and user experience.

[0006] 3. Unreasonable service granularity: Some services are too large, violating the design principles of high cohesion and low coupling, affecting the performance and maintainability of the system.

[0007] 4. The advantages of microservice architecture and domain-driven design are not fully utilized: the boundaries between system modules are blurred and the division of responsibilities is unclear, which increases the complexity of the system and the operation and maintenance costs.

[0008] Therefore, there is an urgent need for a domain-driven design method for production and warehouse management business, which effectively solves the shortcomings of existing technologies by introducing advanced architectural design and methodology. Summary of the Invention

[0009] The present invention overcomes the deficiencies in the prior art and provides a domain-driven design method for production and warehouse management services.

[0010] The purpose of the present invention is achieved through the following technical solutions.

[0011] The domain-driven design method for production and warehouse management business includes the following steps:

[0012] S1. Construct domain design standards to divide domains and subdomains.

[0013] The domain design standard stipulates that the domain is divided into core domain, general domain and support domain.

[0014] The domain design standard stipulates that the core domain is divided into four core domains: production management, warehouse management, energy and carbon management, and safety management.

[0015] The domain design standard stipulates that the general domain contains unified interfaces for related technical components. The general domain includes technical components for notifications, process management, and document management.

[0016] The domain design standard stipulates that the support domain is a general-purpose basic data service, which includes user management and master data management;

[0017] The domain design standard stipulates that each core domain must be divided into subdomains according to the domain design standard, based on the rules defined in the domain design standard for subdomain division;

[0018] S2, aggregate and divide by domain design standards. Domain design standards are divided into two stages:

[0019] In the first phase, we extract the main business links and identify domain objects using the four-color modeling method defined by the domain design standard. Domain objects include entity models, value objects, domain events, and domain services.

[0020] In the second phase, the aggregation and partitioning of domain objects is achieved through the defined aggregation and partitioning method, and the business logic is encapsulated through domain services;

[0021] S3. Identify bounded contexts through domain design standards. Delineate business boundaries based on aggregated information and identify bounded contexts. Split microservices into aggregate service layers and atomic service layers, using domain design standards as the basis for dividing aggregate services and atomic services.

[0022] Aggregation services meet complex business needs by orchestrating atomic services, enabling rapid assembly and flexible orchestration of atomic services.

[0023] S4. Develop atomic services using a four-layer code architecture, which includes the user interface layer, application layer, domain layer, and infrastructure layer.

[0024] S5. Implement cross-domain business processes through microservice orchestration. Cross-domain business processes include production planning and scheduling, quality inspection execution feedback, and dynamic updates of warehouse inventory.

[0025] The subdomain division rules in S1 specifically include:

[0026] Each subdomain can solve independent business problems and is operated by an independent department, organization or position;

[0027] There are clear, one-way functional or data dependencies and call relationships between subdomains;

[0028] Each subdomain only has one clear business responsibility and is reflected in the system design as one or several independent first-level functional items.

[0029] The subdomains in S1 are divided as follows:

[0030] The production management subdomain includes production planning management, production execution management, production quality inspection management, and production process management;

[0031] The warehouse management subdomain includes procurement management and inventory management;

[0032] The energy and carbon management subdomain includes basic library management, energy business management, carbon emission business management, and carbon asset management;

[0033] The security management subdomain includes alarm strategies, basic security information, operation management, security prevention management, security situation awareness, and emergency assistance management.

[0034] The four-color modeling implementation standards for domain design standards in S2 include:

[0035] The time-scale object of four-color modeling must be a specific business activity that can generate entity objects as participants;

[0036] Participants are specific entity objects used to reflect business products.

[0037] The rules for clustering and partitioning entities identified by the four-color modeling method in S2 include:

[0038] Entity objects that have direct associations are grouped into the same aggregate;

[0039] Entity objects are divided into different aggregates through business objects. Different entities divided by specific businesses belong to different aggregates. The aggregate root is directly connected to the business object, and the business object generates domain services for adding, deleting, modifying and checking.

[0040] The methods for dividing bounded contexts in S3 include:

[0041] Divide bounded contexts into subdomains, and mark derivative or subordinate associations within subdomains based on the business logic relationship between aggregations;

[0042] The association method is marked according to the business logic relationship between aggregations. The business logic relationship includes business derivation and business affiliation; the core nodes of core node business derivation and business affiliation are found.

[0043] The granularity of atomic services meets the principles of high cohesion and low coupling. Atomic services expose service capabilities through Restful interfaces; aggregate services implement business logic orchestration by calling atomic service interfaces.

[0044] The infrastructure layer interacts with the database through MyBatis, the domain layer isolates business logic and data persistence through the storage interface, and the application layer calls domain services to complete business orchestration.

[0045] Microservice orchestration implements cross-service calls through the Feign client. The production execution service calls the process management service to obtain recipe parameters and triggers the quality inspection execution service to generate a quality inspection report.

[0046] The beneficial effects of the present invention are as follows: This solution realizes a high-cohesion, low-coupling service design by introducing an aggregation + atomic service architecture, enabling the system to respond more flexibly to changes in business needs. By emphasizing domain-driven design and building a unified domain model, the consistency of data between business modules is ensured, reducing the difficulty of integration. Furthermore, this solution adopts a four-layer code architecture design to achieve the separation of business logic and data access, thereby improving the readability and maintainability of the code. At the same time, through the extraction of common components and the construction of the industrial Internet business middle platform, business components in the fields of production, warehousing, energy, and security are precipitated, forming public service components for support domains and general domains, thereby improving the code reuse rate and development efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Figure 1 It is a schematic diagram of the process of the present invention;

[0048] Figure 2 A diagram showing a method for dividing subdomains, i.e., aggregated services, of the present invention;

[0049] Figure 3 This is the production domain microservice orchestration diagram of the present invention;

[0050] Figure 4 This is the warehouse domain microservice orchestration diagram of the present invention;

[0051] Figure 5 This is the energy carbon domain microservice orchestration diagram of the present invention;

[0052] Figure 6 This is the security domain microservice orchestration diagram of the present invention;

[0053] Figure 7 This is the four-layer architecture code design diagram of the present invention. DETAILED DESCRIPTION

[0054] like Figure 1 As shown in the figure, the domain-driven design method for production and warehouse management business includes the following steps:

[0055] S1. Construct domain design standards to divide domains and subdomains.

[0056] The domain design standard stipulates that the domain is divided into core domain, general domain and support domain.

[0057] The domain design standard stipulates that the core domain is divided into four core domains: production management, warehouse management, energy and carbon management, and safety management.

[0058] The domain design standard stipulates that the general domain contains unified interfaces for related technical components. The general domain includes technical components for notifications, process management, and document management.

[0059] The domain design standard stipulates that the supporting domain is a general basic data service, which includes user management and master data management; the domain design standard stipulates that each core domain must be divided into subdomains through the domain design standard, based on the rules defined for subdomain division in the domain design standard.

[0060] like Figure 2 The subdomain division rules in S1 specifically include:

[0061] Each subdomain can solve independent business problems (such as planning, execution, and quality control) and is operated by an independent department, organization, or position;

[0062] There are clear, one-way functional or data dependencies and call relationships between subdomains;

[0063] Each subdomain only has one clear business responsibility and is reflected in the system design as one or several independent first-level functional items.

[0064] Through the above method, the subdomains in S1 are divided as follows:

[0065] The production management subdomain includes production planning management, production execution management, production quality inspection management, and production process management;

[0066] The warehouse management subdomain includes procurement management and inventory management;

[0067] The energy and carbon management subdomain includes basic library management, energy business management, carbon emission business management, and carbon asset management;

[0068] The security management subdomain includes alarm strategies, basic security information, operation management, security prevention management, security situation awareness, and emergency assistance management.

[0069] S2, aggregate and divide by domain design standards. Domain design standards are divided into two stages:

[0070] In the first phase, we extract the main business links and identify domain objects using the four-color modeling method defined by the domain design standard. Domain objects include entity models, value objects, domain events, and domain services.

[0071] In the second stage, the aggregation and division of domain objects is realized through the defined aggregation and division method, and the business logic is encapsulated through domain services.

[0072] In this embodiment, the four-color modeling method sets the time-scale object to pink, the role object to orange, the participant to green, and the description to blue.

[0073] The four-color modeling implementation standards for domain design standards in S2 include:

[0074] The time-scale object of the four-color modeling must be a specific business activity that can generate entity objects as participants and use the time-scale object as a business object;

[0075] The participant is a specific entity object used to reflect the business generated, and the participant is regarded as the entity object.

[0076] S2. Identify business entities and aggregation relationships based on the four-color modeling method, use the aggregation pattern architecture to design bounded contexts, define aggregate roots, entity models, value objects and domain events for each subdomain, and encapsulate business logic through domain services.

[0077] The rules for clustering and partitioning entities identified by the four-color modeling method in S2 include:

[0078] Entity objects that have a direct association relationship are classified as the same aggregate; that is, entity objects that are directly connected together are an aggregate, and one of the entities in the same aggregate is the aggregate root.

[0079] Among them, the direct association relationship between entity objects includes relationships, causal relationships, etc., which are reflected as direct connections in four-color modeling.

[0080] Entity objects are divided into different aggregates through business objects. Different entities divided by specific businesses belong to different aggregates. The aggregate root is directly connected to the business object, and the business object generates domain services for adding, deleting, modifying and checking.

[0081] S3. Identify bounded contexts through domain design standards. Delineate business boundaries based on aggregated information and identify bounded contexts. Split microservices into aggregate service layers and atomic service layers, using domain design standards as the basis for dividing aggregate services and atomic services.

[0082] Aggregation services meet complex business needs by orchestrating atomic services, enabling rapid assembly and flexible orchestration of atomic services.

[0083] The methods for dividing bounded contexts in S3 include:

[0084] Divide bounded contexts into subdomains, and mark derivative or subordinate associations within subdomains based on the business logic relationship between aggregations;

[0085] The association method is marked based on the business logic relationship between aggregates. Business logic relationships include business derivation and business affiliation. Business derivation is indicated by an arrow pointing to the derived aggregate.

[0086] Business affiliation is indicated by an arrow pointing to the subordinate aggregation. For example, if aggregation A is subordinate to aggregation B, the arrow points from A to B.

[0087] Find the core nodes from which core node businesses are derived and to which businesses belong.

[0088] S4. Develop atomic services using a four-layer code architecture, which includes the user interface layer, application layer, domain layer, and infrastructure layer.

[0089] S5. Implement cross-domain business processes through microservice orchestration. Cross-domain business processes include production planning and scheduling, quality inspection execution feedback, and dynamic updates of warehouse inventory.

[0090] The granularity of atomic services meets the principles of high cohesion and low coupling. Atomic services expose service capabilities through Restful interfaces; aggregate services implement business logic orchestration by calling atomic service interfaces.

[0091] The infrastructure layer interacts with the database through MyBatis, the domain layer isolates business logic and data persistence through the storage interface, and the application layer calls domain services to complete business orchestration.

[0092] Microservice orchestration implements cross-service calls through the Feign client. The production execution service calls the process management service to obtain recipe parameters and triggers the quality inspection execution service to generate a quality inspection report.

[0093] The following embodiments are specific design examples of each sub-domain.

[0094] Example 1

[0095] like Figure 3 As shown, this embodiment takes the production domain microservice design as an example.

[0096] Implementation steps and methods

[0097] Define the underlying atomic microservices

[0098] In the production domain, the underlying atomic microservices are primarily responsible for handling single, specific business functions. These services form the foundation for upper-level business microservices. For example:

[0099] Planning management services: responsible for the formulation and adjustment of production plans to ensure the orderly progress of production activities.

[0100] Planning and scheduling services: Carry out specific production scheduling and arrange production resources according to the production plan.

[0101] Work reporting service: Processes work reporting information, such as recording workers' working hours, completed tasks, etc.

[0102] Shift handover service: Manage the shift handover process of the team to ensure the continuity and accuracy of production information.

[0103] Define upper-level business microservices

[0104] Upper-level business microservices implement more complex business logic and processes by orchestrating underlying atomic microservices. In the production domain, these services include:

[0105] Production planning service: responsible for the formulation and management of the overall production plan, and ensures the rationality and feasibility of the production plan through the arrangement of planning management services and planning and scheduling services.

[0106] Production Execution Services: Manage the production execution process, including reporting and shift handovers. By orchestrating reporting and shift handover services, the production execution process is automated and efficient.

[0107] Combined into upper-level business microservices through the aggregation service layer

[0108] The aggregation service layer is responsible for combining the underlying atomic microservices into upper-level business microservices to form a complete business process. In the production domain, the aggregation service layer performs the following operations:

[0109] Receiving user requests: Users submit production-related requests through the front-end interface or API interface.

[0110] Calling upper-layer business microservices: The aggregation service layer calls the corresponding upper-layer business microservices for processing based on user requests. For example, when a user requests to view the production plan, the aggregation service layer calls the production planning service; when a user requests to report production hours, the aggregation service layer calls the production execution service.

[0111] Data persistence: Data generated during the production process (such as production plans, work report information, etc.) needs to be persisted in the database through the services of the infrastructure layer for subsequent query and analysis.

[0112] Return processing results: The aggregation service layer returns the processing results of the upper-layer business microservices to the user. The user can view the processing results in the front-end interface or API interface.

[0113] Example

[0114] Taking the work reporting business as an example, the underlying atomic microservices include work reporting service and shift handover service; the upper-level business microservices include production execution service; the aggregation service layer is responsible for receiving user requests, calling the production execution service for processing, and returning the processing results to the user.

[0115] Through the above steps and methods, the production domain microservice design can achieve refined management and efficient operation of the production process, thereby improving production efficiency and product quality.

[0116] Example 2

[0117] like Figure 4 As shown, this embodiment takes the warehousing domain microservice design as an example.

[0118] Implementation steps and methods

[0119] Define the underlying atomic microservices

[0120] In the warehousing domain, the underlying atomic microservices are mainly responsible for handling specific procurement and inventory management functions. These services include:

[0121] Procurement management services: used to maintain information such as long-term contracts, procurement plans, and arrival plans to ensure timely supply of raw materials.

[0122] Inventory Management Services: Responsible for the inbound and outbound management of raw materials, finished products, and semi-finished products, as well as real-time inventory updates and inventory checks. They also handle related tasks such as shipping returns and shipping plans.

[0123] Define upper-level business microservices

[0124] The upper-layer business microservices implement the overall functionality of the warehousing business by orchestrating the underlying atomic microservices. In the warehousing domain, the main upper-layer business microservices are:

[0125] Warehouse Management Service: This service implements the overall procurement and inventory management process by invoking the Procurement Management Service and the Inventory Management Service. It coordinates key processes such as raw material procurement, inventory monitoring, and finished product warehousing. It also enables interaction between the Warehouse Management Service and other services, such as the Production Planning Service and the Production Execution Service.

[0126] The close interaction between warehouse management services, production planning services, and production execution services is key to ensuring effective management of raw materials and finished products. The specific interaction process is as follows:

[0127] Interaction of Production Planning Service:

[0128] The production planning service formulates a production plan based on production demand and sends the required raw material types and quantities to the warehouse management service.

[0129] The Warehouse Management Service queries inventory to check whether the required raw materials are available. If so, it locks the inventory and notifies the Production Planning Service that production can begin. If insufficient, it triggers the procurement process, which involves replenishing inventory through the Procurement Management Service.

[0130] Interaction with the Production Execution Service: The Production Execution Service executes production tasks according to the production plan and sends a material picking request to the Warehouse Management Service when material picking is required.

[0131] After receiving the picking request, the Warehouse Management Service verifies the picking list information and arranges for shipment. The Inventory Management Service executes the shipment operation, updates the inventory record, and generates a shipment order.

[0132] The Warehouse Management Service feeds the Outbound Order information back to the Production Execution Service, confirming the material's shipment. During the production process, if the Production Execution Service needs to replenish materials or process scrap or leftover material, it will interact with the Warehouse Management Service again. Upon completion, the Production Execution Service notifies the Warehouse Management Service to receive the finished product. The Inventory Management Service executes the receipt and updates the inventory records.

[0133] Through the above steps and methods, the warehousing domain microservice design achieves refined control over procurement and inventory management, ensures the effective management of raw materials and finished products, and provides strong support for the smooth progress of production.

[0134] Example 3

[0135] like Figure 5 As shown, this embodiment takes the energy carbon domain microservice design as an example.

[0136] Implementation steps and methods

[0137] Define the underlying atomic microservices

[0138] In the energy and carbon domain microservice design, the underlying atomic microservices are the foundation for implementing specific business functions. These services are responsible for different aspects of energy and carbon management, including:

[0139] Carbon accounting management service: used to maintain basic enterprise information, accounting boundaries, data reporting levels, etc., and provide the basic data management and accounting plan generation capabilities required for carbon accounting.

[0140] Carbon emission management service: used to report relevant emission sources and activity levels, automatically calculate carbon emissions and generate reports, and support real-time monitoring of carbon emissions.

[0141] Carbon emission reduction management services: Manage the entire life cycle of carbon emission reduction, from planning to execution tracking, to ensure the achievement of emission reduction targets.

[0142] Carbon quota management service: Manage the company's carbon quota to ensure that the company's emissions are within the compliance range.

[0143] Carbon compliance management services: Based on the relevant rules of national carbon market compliance, online compliance plans are formulated to support enterprises in fulfilling their carbon market compliance obligations.

[0144] Define upper-level business microservices

[0145] The upper-layer business microservices implement complex business logic and processes by orchestrating the underlying atomic microservices. In the Energy Carbon Domain, these services include:

[0146] Dual carbon management service: used for dual carbon basic information and carbon accounting management, calling carbon accounting management service to obtain enterprise basic information and accounting data.

[0147] Carbon emission management service: used for carbon emission and carbon emission reduction management. The carbon emission management service is called to collect and calculate carbon emission data, and the carbon emission reduction management service is called to formulate and implement emission reduction plans.

[0148] Carbon asset management service: used for carbon quota and carbon compliance management. Carbon quota management service is used to manage the company's carbon quota, and carbon compliance management service is used to ensure that the company fulfills its compliance obligations.

[0149] Integrate data on carbon emissions, carbon reduction, etc. to predict carbon emissions and calculate costs.

[0150] By integrating carbon emission and carbon reduction data, the third embodiment can predict carbon emissions and calculate costs, providing decision support for carbon management. The specific process includes:

[0151] Data integration: Integrate data from emission sources, activity levels, and energy consumption data through carbon emission management services; integrate emission reduction planning, implementation, and tracking data through carbon reduction management services; and integrate government-approved carbon quota data through carbon quota management services.

[0152] Forecasting Process: Based on historical emissions data and current production plans, we use the "historical intensity reduction method" and integrate adjustment coefficients with pre-set unit emission reduction targets to calculate and forecast future carbon emissions. Simultaneously, based on emission reduction plans and implementation data, we predict the impact of emission reduction measures on carbon emissions and evaluate their effectiveness.

[0153] Cost calculation: Based on the prediction of carbon emissions and carbon reduction effects, combined with factors such as market prices, calculate and analyze the costs related to carbon management.

[0154] Through the above steps and methods, Example 3 constructs a complete energy-carbon management microservice architecture to support enterprises in achieving dual carbon goals and ensure the compliance and sustainability of carbon emissions.

[0155] Example 4

[0156] like Figure 6 As shown, this embodiment takes the security domain microservice design as an example.

[0157] Implementation steps and methods

[0158] Define the underlying atomic microservices

[0159] In the security domain microservice design, the underlying atomic microservices are responsible for different aspects of security management. These services include:

[0160] Smart Inspection Service: This service provides comprehensive smart inspection capabilities, encompassing everything from inspection standard library management, inspection point management, inspection route planning, and task execution. Tasks are automatically acquired through smart terminals, and based on personnel location and data collection, the system determines whether inspections have been completed as required.

[0161] Alarm management service: Receives alarm information from inside and outside the system, including alarm events, alarm locations, alarm times, alarm contents, etc., and supports alarm escalation strategy configuration to ensure that alarm information is handled promptly and effectively.

[0162] Define upper-level business microservices

[0163] The upper-layer business microservices implement complex business logic and processes by orchestrating the underlying atomic microservices. In the security domain, these services include:

[0164] Security Situation Awareness Service: This service is used for campus management, including pedestrian, vehicle, and video security, as well as inspection route planning, inspection logging, and alarm management. By orchestrating intelligent inspection services and alarm management services, comprehensive monitoring and early warning of campus security are achieved.

[0165] Operation Management Services: Responsible for the development, execution, and monitoring of operation plans to ensure the safety and efficiency of the operation process. Through intelligent inspection services and alarm management services, real-time monitoring and early warning of enterprise safety are achieved.

[0166] Real-time monitoring and early warning of intelligent inspection services:

[0167] Inspection task allocation: Based on the predefined inspection plan and inspection route, the intelligent inspection service allocates inspection tasks to corresponding inspection personnel or intelligent terminals.

[0168] Inspection execution: Inspection personnel or intelligent terminals conduct inspections at designated times and locations according to task requirements and collect relevant data.

[0169] Data upload and analysis: After the inspection is completed, the smart terminal uploads the inspection data to the smart inspection service. The service analyzes the uploaded data to determine whether the inspection was completed as required.

[0170] Early warning processing: If an inspection anomaly is found or abnormal data is collected, the intelligent inspection service will trigger the early warning mechanism, generate an alarm message, and notify relevant personnel to handle it.

[0171] Real-time monitoring and early warning of alarm management services:

[0172] Receiving alarm information: The alarm management service receives alarm information from inside or outside the system.

[0173] Alarm information analysis: Analyze the received alarm information, determine the severity and impact scope of the alarm, and perform graded processing.

[0174] Alarm notification and escalation: Based on the severity and impact of an alarm, the Alarm Management Service notifies the appropriate personnel or roles of the alarm. If the alarm is not promptly addressed, it will be escalated according to the predefined escalation policy.

[0175] Alarm processing tracking: The alarm management service tracks the alarm processing process, records information such as the processing personnel, processing time, and processing results, to ensure that alarms are handled in a timely and effective manner.

[0176] Through the above steps and methods, Example 4 constructs a comprehensive security domain microservice architecture, realizes real-time monitoring and early warning of enterprise security, and provides strong protection for the safe production of the enterprise.

[0177] Example 5

[0178] This embodiment takes the general domain microservice design as an example.

[0179] Implementation steps and methods

[0180] Define the underlying atomic microservices

[0181] In the general domain microservice design, the underlying atomic microservices are responsible for different aspects of general business management. These services include:

[0182] User management service: provides functions such as user registration, login, information modification, role assignment, etc., and supports multiple authentication methods and permission management.

[0183] Permission management service: A role- and permission-based access control mechanism ensures that users can only access resources for which they have permissions.

[0184] Data query service: provides a flexible data query interface, supports multiple query conditions and sorting methods, and meets users' data query needs.

[0185] Define upper-level business microservices

[0186] The upper-level business microservices implement complex business logic and processes by orchestrating the underlying atomic microservices. In the general domain, these services include:

[0187] Comprehensive Business Management Service: This service orchestrates underlying services such as user management, permissions management, and data query, enabling comprehensive management of user information, permissions, and data. This service allows users to conveniently manage their user information and permissions while efficiently querying required data.

[0188] Realize real-time monitoring and early warning of general domains

[0189] Real-time monitoring and early warning of user management services: Real-time monitoring of user behaviors, such as login, logout, information modification, etc. If abnormal behavior is found (such as multiple login failures, illegal access, etc.), the early warning mechanism will be triggered, an alarm message will be generated, and relevant personnel will be notified for processing.

[0190] Real-time monitoring and early warning of rights management services: monitor the allocation and use of rights. If any abnormality in rights is found (such as unauthorized access, abuse of rights, etc.), timely early warning will be issued and relevant personnel will be notified to handle the matter.

[0191] Real-time monitoring and early warning of data query services: Data query behaviors are monitored and analyzed. If abnormal queries are found (such as frequent queries for sensitive data, sudden increases in query volume, etc.), an early warning mechanism will be triggered to ensure data security.

[0192] Through the above steps and methods, this embodiment builds a comprehensive universal domain microservice architecture, realizes real-time monitoring and early warning of universal business management, and provides strong protection for the enterprise's information management and data security.

[0193] Example 6

[0194] This embodiment takes the microservice design of the support domain as an example.

[0195] In the support domain, we define the following underlying atomic microservices to support basic data services and technical support:

[0196] Personnel Permission Service: Provides maintenance and management of personnel, permissions, roles, and organizational structures. This service supports user registration, login, information modification, and role assignment, ensuring system security and accurate management of user permissions. Factory Information Management Service: Provides maintenance and management of factory, workshop, production line, equipment, and job position information. This service supports the addition, deletion, modification, and query of factory information, as well as the associated management of equipment and production line information, providing accurate data support for production activities.

[0197] Supply Chain Information Management Service: This service maintains and manages basic information such as product classification, product model, and unit of measurement, as well as information on raw materials and tanks. This service provides comprehensive data support for a company's supply chain management.

[0198] Technical Details

[0199] Domain model design: We designed a detailed domain model based on business requirements. For example, in the personnel organization aggregate, we defined the organization as the aggregate root, personnel and positions as entities, and position categories as value objects. We also provided corresponding domain services, such as personnel information creation, modification, query, and deletion.

[0200] Code Structure Design: We adopted a four-tier architecture to implement atomic services, consisting of the infrastructure layer, domain layer, application layer, and interface layer. The domain layer contains domain objects and services, the application layer is responsible for orchestrating and invoking domain services, the interface layer provides a RESTful interface to receive user requests, and the infrastructure layer provides infrastructure services such as data storage, message queues, and caching. For aggregate services, we adopted an MVC structure, consisting of a control layer and a service layer. The control layer is responsible for receiving front-end requests and invoking the service layer to process business logic.

[0201] Implementation steps

[0202] To build the support domain, the following implementation steps will be followed:

[0203] Demand analysis: Clarify the business needs of the supporting domain, including personnel authority management, factory information management, supply chain information management, etc.

[0204] Domain model design: Design the domain model according to business requirements, including aggregate roots, entities, value objects and domain services.

[0205] Microservice design: Design the microservice architecture based on the domain model and clarify the functions and interfaces of each microservice.

[0206] Code implementation: Implement atomic services according to the four-tier architecture, and build aggregate services to call atomic services to complete business logic processing.

[0207] Testing and verification: Perform unit testing, integration testing, and system testing on microservices to ensure functional correctness and performance meet requirements.

[0208] Deployment and rollout: Deploy microservices to the production environment and monitor and maintain them to ensure stable system operation. Through these implementation steps, a stable and reliable microservice architecture for the supporting domain will be built, providing strong support for the company's basic data services and technical support.

[0209] Example 7

[0210] In this embodiment, bounded context design is taken as an example.

[0211] Domain Bounded Context Design

[0212]

[0213]

[0214] This embodiment uses the design of the production domain object as an example for specific disclosure. Summary of the production domain object design:

[0215]

[0216]

[0217] Production process context: aggregate / entity / domain event / domain service design

[0218] Solid / Aggregate Model Production Process Aggregation:

[0219] The aggregate roots and entity models of production process aggregation include: process (aggregate root), procedure, and equipment parameters.

[0220] The value objects aggregated by the production process are: process materials.

[0221] The domain events of production process aggregation are: None.

[0222] The field services of production process aggregation include: process creation, process modification, process query, process deletion, process creation, process modification, process query, and process deletion.

[0223] process

[0224] Attribute Identifier Property Name Data Type Value Object / Description processCode Process Code String processName Process Name String productType Applicable product models Object productType recipe formula Object recipe processContent Process content String processTime Processing time (h) Int sequences Process List <object> < / object> sequence disc describe String

[0225] process sequence

[0226] Attribute Identifier Property Name Data Type Value Object / Description id Logo String sequenceNo Process number Int sequenceName Process Name String deviceType Device Type Object deviceType deviceParameters Device parameters List <object> < / object> deviceParameter sequenceMaterials Process Materials List <object> < / object> sequenceMaterial disc describe String

[0227] Process material sequenceMaterial

[0228]

[0229]

[0230] Device Parameter deviceParameter

[0231] Attribute Identifier Property Name Data Type Value Object / Description id Logo String paramName Parameter name String paramType Parameter Type Enum setValue Setting value String minValue Minimum String maxValue Maximum String disc describe String

[0232] Plan management context: aggregate / entity / domain event / domain service design

[0233] Inventory Planning Aggregation:

[0234] The aggregate roots and entity models of inventory planning aggregation are: demand planning (aggregate root).

[0235] The value objects of inventory planning aggregation are: demand items.

[0236] The domain events for inventory planning aggregation are: None.

[0237] The domain services of inventory plan aggregation include: demand plan creation, demand plan modification, demand plan query, and demand plan deletion.

[0238] Demand plan monthlyRequirement

[0239] Attribute Identifier Property Name Data Type Value Object / Description id Logo String month month Int zone Area String requirementItems Wish List List <object> < / object> requirementItem

[0240] requirementItem

[0241] Attribute Identifier Property Name Data Type Value Object / Description product product Object Product quantity quantity Float

[0242] Production planning aggregation:

[0243] The aggregate roots and entity models of production plan aggregation are: production plan (aggregate root), weekly plan, and daily plan.

[0244] The domain events aggregated by production planning are: None.

[0245] The domain services of production plan aggregation include: production plan creation, production plan query, and production plan deletion.

[0246] Production Plan

[0247] Attribute Identifier Property Name Data Type Value Object / Description weeklyPlan Weekly Plan List <object> < / object> weeklyPlan dailyPlan Daily Plan List <object> < / object> dailyPlan

[0248] Weekly Plan

[0249] Attribute Identifier Property Name Data Type Value Object / Description planCode Plan Coding String monthlyRequirement Demand Planning Object monthlyRequirement requirementItems Wish List List <object> < / object> requirementItem productionLine production line Object productionLine recipe formula Object Recipe

[0250] Daily Plan

[0251] Attribute Identifier Property Name Data Type Value Object / Description planCode Plan Coding String date date Date weeklyPlan Weekly Plan Object weeklyPlan requirementItems Wish List List <object> < / object> requirementItem productionLine production line Object productionLine recipe formula Object Recipe

[0252] Planning and Scheduling Context: Aggregate / Entity / Domain Event / Domain Service Design

[0253] Production scheduling aggregation:

[0254] The aggregate roots and entity models of the production scheduling aggregate are: production scheduling, daily production scheduling, and team production scheduling.

[0255] The domain events for production scheduling aggregation are: None.

[0256] The services in the field of production scheduling aggregation include: daily production schedule creation, daily production schedule modification, daily production schedule query, daily production schedule deletion, team production schedule creation, team production schedule modification, team production schedule query, and team production schedule deletion.

[0257] Production Schedule

[0258] Attribute Identifier Property Name Data Type Value Object / Description dailySchedule Daily production schedule List <object> < / object> dailySchedule teamSchedule Team production scheduling List <object> < / object> teamSchedule

[0259] Daily production schedule

[0260] Attribute Identifier Property Name Data Type Value Object / Description date date Date dailyPlan Daily Plan Object dailyPlan teamSchedules Production Scheduling Unit List <object> < / object> teamSchedule

[0261] Team production scheduling steamSchedule

[0262] Attribute Identifier Property Name Data Type Value Object / Description team team Object Team class Flights Object Class poductionLine production line Object poductionLine

[0263] Wireside library management context: aggregate / entity / domain event / domain service design

[0264] Material Receiving Aggregation:

[0265] The aggregate roots and entity models of material receiving aggregation are: material requisition form and material receiving record (aggregate root).

[0266] The value objects of material receipt aggregation are: material unit.

[0267] The domain events of material receiving aggregation are: materials arrive at the line-side warehouse.

[0268] The field methods of the Material Receipt aggregation are: Material Receipt, Material Receipt Record Query.

[0269] Material Requisition

[0270] Attribute Identifier Property Name Data Type Value Object / Description materialRequisitionCode Material requisition number String materialList Bill of Materials List <object> < / object> materialUnit picker Material Receiver Object Employee materialRequisitionTime Material collection time DateTime

[0271] Material Unit materialUnit

[0272]

[0273]

[0274] Material Receive Record materialReceiveRecord

[0275] Attribute Identifier Property Name Data Type Value Object / Description id Logo String materialRequisitionCode Material requisition number String materialList Bill of Materials List <object> < / object> materialUnit receiver Recipient Object employee materialReceiveTime Receiving time DateTime

[0276] Line-edge library aggregation:

[0277] The aggregate roots and entity models of line-side warehouse aggregation are: line-side warehouse (aggregate root), line-side inventory, line-side warehousing operation, and line-side outbound operation.

[0278] The domain events for the Material Receiving aggregate are: None.

[0279] The field methods of material receiving aggregation are: line-side raw material warehousing, line-side raw material warehousing, line-side inventory query, line-side inventory creation, line-side inventory modification, and line-side inventory deletion.

[0280] Line Storage

[0281]

[0282] Line Inventory lineInventory

[0283] Attribute Identifier Property Name Data Type Value Object / Description id Logo String lineStorage Lineside Library Object lineStorage materialList Bill of Materials List <object> < / object> materialUnit

[0284] Line side storage operation LineReceiptRecord

[0285] Attribute Identifier Property Name Data Type Value Object / Description id Logo String lineStorage Lineside Library Object lineStorage materialList Bill of Materials List <object> < / object> materialUnit

[0286] LineOutboundRecord

[0287] Attribute Identifier Property Name Data Type Value Object / Description id Logo String lineStorage Lineside Library Object lineStorage materialList Bill of Materials List <object> < / object> materialUnit

[0288] Production Work Order Context: Aggregate / Entity / Domain Event / Domain Service Design

[0289] Production work order aggregation:

[0290] The aggregate roots and entity models of production work order aggregation are: work order basic information and work order (aggregate root).

[0291] The value objects aggregated by production work orders are: work order materials.

[0292] The domain events aggregated by production work orders include: start and completion.

[0293] The domain services for production work order aggregation include: work order generation, work order information query, work order information modification, and work order deletion.

[0294] WorkorderBasicInfo

[0295] Attribute Identifier Property Name Data Type Value Object / Description workorderType Work Order Type Enum workorderNo Work order number String workorderState Work Order Status Enum dailyPlan Daily plan logo Object dailyPlan plannedStartTime Planned start time DateTime plannedEndTime Planned end time DateTime plannedOutput Planned output Float batchNo Product batch number String productionLine production line Object productionLine process Production process Object process

[0296] work order

[0297] Attribute Identifier Property Name Data Type Value Object / Description id Logo String workorderBasicInfo Basic work order information Object workorderBasicInfo actualStartTime Actual start time DateTime actualEndTime Actual end time DateTime actualOutput Actual output Float team Team identification Object team employees Personnel identification List <object> < / object> employee devices production equipment List <object> < / object> device workorderMaterials Work order materials List <object> < / object> workorderMaterial

[0298] workorderMaterial

[0299] Attribute Identifier Property Name Data Type Value Object / Description material materials Object material quantity quantity Float

[0300] Production process polymerization:

[0301] The aggregate roots and entity models of production process aggregation include: production process records (aggregate roots), production operation records, and production accident records.

[0302] The value objects aggregated in the production process include: operation items and accident items.

[0303] The domain events aggregated in the production process include: production operations and production accidents.

[0304] The domain services aggregated in the production process include: production operation record creation, production operation record modification, production operation record query, production operation record deletion, production accident record creation, production accident record modification, production accident record query, and production accident record deletion.

[0305] Production process record productionRecord

[0306] Attribute Identifier Property Name Data Type Value Object / Description opsRecords Production operation records List <object> < / object> opsRecord accidentRecords Production accident records List <object> < / object> accidentRecord

[0307] Production operation record opsRecord

[0308] Attribute Identifier Property Name Data Type Value Object / Description id Logo String workorder Work Order Object workorder

[0309]

[0310] Operation item opsItem

[0311] Attribute Identifier Property Name Data Type Value Object / Description device equipment Object device employee Operator Object employee manipulation Production Operations Enum remark Remark String

[0312] Production accident record accidentRecord

[0313] Attribute Identifier Property Name Data Type Value Object / Description id Logo String workorder Work Order Object workorder accidentItems Operation content List <object> < / object> accidentItem

[0314] accidentItem

[0315] Attribute Identifier Property Name Data Type Value Object / Description device equipment Object device employee Operator Object employee accidentType Accident Type Enum remark Remark String

[0316] Device Operation Context: Aggregate / Entity / Domain Event / Domain Service Design

[0317] Device operation aggregation:

[0318] The aggregate roots and entity models of equipment operation aggregation include: equipment operation record (aggregate root), equipment operation status record, single equipment output record, and operation parameter record.

[0319] The domain events of device operation aggregation include: device startup, device shutdown, and device failure.

[0320] The field services of equipment operation aggregation include: equipment output entry, equipment operation status recording, and equipment operation parameter recording.

[0321] Device running record deviceRunningRecord

[0322]

[0323] Device Status Record deviceStatusRecord

[0324] Attribute Identifier Property Name Data Type Value Object / Description id Logo String device equipment Object device deviceStatus Device Status Enum

[0325] Single device production record deviceProductionRecord

[0326] Attribute Identifier Property Name Data Type Value Object / Description id Logo String device equipment Object device startTime Start time DateTime endTime End Time DateTime

[0327]

[0328] Run parameter records parameterRecords

[0329] Attribute Identifier Property Name Data Type Value Object / Description id Logo String device equipment Object device startTime Start time DateTime endTime End Time DateTime parameterName Parameter name String parameterValue Parameter value String

[0330] Parameter delivery aggregation:

[0331] The aggregate roots and entity models of parameter delivery aggregation include: equipment point table, parameter delivery record (aggregate root), and parameter setting value.

[0332] The value objects of parameter delivery aggregation are: point table unit

[0333] The domain events of parameter delivery aggregation include: parameter setting and parameter delivery.

[0334] The domain services of parameter delivery aggregation include: device point table creation, device point table modification, device point table query, device point table deletion, parameter delivery record creation, parameter delivery record modification, parameter delivery record query, and parameter delivery record deletion.

[0335] DevicePropertyList

[0336] Attribute Identifier Property Name Data Type Value Object / Description id Logo String device equipment Object device propertyUnits Point table List <object> < / object> propertyUnit

[0337] Point table unit propertyUnit

[0338] Attribute Identifier Property Name Data Type Value Object / Description propertyName variable name String OPCNodeId OPC Address String

[0339] Parameter delivery record deviceOpsRecord

[0340] Attribute Identifier Property Name Data Type Value Object / Description id Logo String device equipment Object device setValues Parameter setting value List <object> < / object> parameterSetValue

[0341] parameterSetValue

[0342] Attribute Identifier Property Name Data Type Value Object / Description propertyName variable name String setValue Setting Values String timeStamp Timestamp Timestamp

[0343] Quality management context: aggregate / entity / domain event / domain service design

[0344] Quality inspection configuration aggregation:

[0345] The aggregate roots and entity models of quality inspection configuration aggregation are: quality inspection items and quality inspection templates (aggregate roots).

[0346] The domain events aggregated by quality inspection configuration are: None.

[0347] The domain services of quality inspection configuration aggregation include: quality inspection item creation, quality inspection item modification, quality inspection item query, quality inspection item deletion, quality inspection template creation, quality inspection template modification, quality inspection template query, and quality inspection template deletion.

[0348] Quality Inspection Item

[0349] Attribute Identifier Property Name Data Type Value Object / Description id Logo String QCItemName Quality inspection item name String testMethod Inspection methods String referenceValue Reference value String referenceMaxValue Reference value upper limit String referenceMinValue Reference value lower limit String unit unit Enum

[0350] Quality inspection template QCTemplate

[0351] Attribute Identifier Property Name Data Type Value Object / Description id Logo String QCTemplateVersion Quality inspection template version String material materials Object material QCItems Quality inspection items List <object> < / object> QCItem

[0352] Quality inspection application aggregation:

[0353] The aggregate roots and entity models of the quality inspection application aggregation are: quality inspection sample, quality inspection application (aggregate root).

[0354] The domain events aggregated by quality inspection application include: quality inspection application.

[0355] The services in the field of quality inspection application aggregation include: quality inspection sample creation, quality inspection sample modification, quality inspection sample query, quality inspection sample deletion, quality inspection application creation, quality inspection application modification, quality inspection application query, quality inspection application approval, quality inspection application rejection, and quality inspection application withdrawal.

[0356] Quality inspection sample QCSample

[0357] Attribute Identifier Property Name Data Type Value Object / Description QCSampleCode Sample code String material materials Object material workorder Work Order Object workorder samplingTime Sampling time DateTime samplingQuantity Sampling quantity Float validityDeadline Validity expiration date DateTime QCTemplate Quality Inspection Template Object QCTemplate

[0358] Quality Inspection Application QCApply

[0359] Attribute Identifier Property Name Data Type Value Object / Description QCApplyCode Application Code String QCType Quality inspection type Enum QCSamples Quality inspection samples List <object> < / object> QCSample isRetest Whether to re-examine Enum priority Quality inspection priority Enum

[0360] Quality inspection record aggregation:

[0361] The aggregate roots and entity models of quality inspection record aggregation are: quality inspection record (aggregate root).

[0362] The value objects of quality inspection record aggregation include: single quality inspection results.

[0363] The domain events aggregated by quality inspection records include: quality inspection result generation.

[0364] The domain services for quality inspection record aggregation include: quality inspection record creation, quality inspection record modification, quality inspection record query, and quality inspection record deletion.

[0365] Single item quality inspection result QCItemResult

[0366] Attribute Identifier Property Name Data Type Value Object / Description QCItem Quality inspection items Object QCResult Quality inspection results Enum resultDisc Result description String

[0367] Quality Inspection Record QCRecord

[0368] Attribute Identifier Property Name Data Type Value Object / Description id Logo String QCNo Quality inspection order number String QCApply Quality inspection application Object QCApply QCTime Quality inspection time DateTime QCType Quality inspection type Enum Product quality inspection QCState Quality inspection status Enum Not quality inspected employee Quality Inspector Object employee QCItemResults Quality inspection results of quality inspection items List <object> < / object> QCItemResult QCResult Quality inspection results Enum resultDisc Result description String handleMethod Treatment Enum handleRemarks Processing Notes String isFinalTest Whether final inspection Enum

[0369] Quality inspection report context: aggregate / entity / domain event / domain service design

[0370] Quality inspection report aggregation:

[0371] The entity models of quality inspection report aggregation are: quality inspection report template, quality inspection report (aggregate root).

[0372] The aggregate roots and domain events of the quality inspection report aggregation are: quality inspection result generation.

[0373] The domain services of quality inspection report aggregation include: quality inspection report import, quality inspection report export, quality inspection record creation, quality inspection record modification, quality inspection report query, and quality inspection report deletion.

[0374] Quality Inspection Report Template QCReportTemplate

[0375] Attribute Identifier Property Name Data Type Value Object / Description id Logo String QCReportTemplateVersion Quality inspection report template version String QCReportTemplateName Quality inspection report template name String disc illustrate String QCReportTemplateDoc Quality inspection report template file Text

[0376] Quality Inspection Report QCReport

[0377] Attribute Identifier Property Name Data Type Value Object / Description QCReportCode Quality inspection report number String QCReportTemplate Quality inspection report template Object QCReportTemplate QCReportName Quality inspection report name String QCRecord Quality inspection records Object QCRecord

[0378] Example 8

[0379] like Figure 7 As shown, in this embodiment, a four-layer code architecture is used to develop atomic services.

[0380] Implementation steps and methods

[0381] Establish a four-tier architecture

[0382] In the code design, a four-tier architecture consisting of infrastructure layer, domain layer, application layer, and user interface layer was established. This architecture helps to achieve a highly cohesive and loosely coupled code structure, improving the maintainability and scalability of the code.

[0383] Infrastructure layer: Provides technical capabilities such as data operations, message sending and consumption, caching, etc., providing technical support for the upper layer.

[0384] The domain layer (domain): Responsible for expressing business concepts and business logic, it is the core of the system. This layer does not contain code that interacts with the user interface, database, etc., and focuses only on the implementation of business logic.

[0385] Application layer: As the coordinator of the domain layer, it is responsible for orchestrating complex business scenarios. It does not contain business rules, but implements business functions by calling the domain layer.

[0386] User interface layer (interface): calls the application layer to complete specific user requests and interact with users.

[0387] Definition of Hierarchical Domain Model Specification

[0388] In order to ensure the correct transmission and storage of data, a hierarchical domain model specification is defined, including DTO (data transfer object), PO (persistent object) and DO (domain object).

[0389] DTO: used for data transmission between Service layers and usually does not contain business logic.

[0390] PO: corresponds one-to-one with the database table structure, and transmits the data source object upward through the Mapper layer.

[0391] DO: Domain object, which encapsulates business logic and business status and is the core of the domain layer.

[0392] Implementation of domain layer business logic

[0393] Implementing business logic in the domain layer ensures that business logic is separated from data access. This helps improve code testability and maintainability.

[0394] Use Domain Services to handle cross-aggregate business logic.

[0395] Following object-oriented principles, related entities and value objects are organized through aggregation to form aggregate roots.

[0396] Writing application services and aggregation services

[0397] Application services are written at the application layer and act as coordinators for the domain layer. They are primarily responsible for orchestrating and distributing work to the domain layer, ensuring the correct execution of business logic.

[0398] Aggregation service: used to interact with the front-end and act as the coordinator of atomic services. It is mainly responsible for orchestrating and allocating work to atomic services and forwarding front-end requests to the corresponding atomic services for processing.

[0399] Through the above steps and methods, Example 8 constructs a clear, maintainable, and extensible engineering code architecture, providing strong support for system development and maintenance.

[0400] The embodiments of the present invention are described in detail above, but the contents described are only preferred embodiments of the present invention and should not be considered to limit the scope of the present invention. All equivalent changes and improvements made within the scope of the present invention should still fall within the scope of the patent coverage of the present invention.

Claims

1. The domain-driven design method for production and warehouse management business is characterized by: The specific steps include: S1. Construct domain design standards to divide domains and subdomains: The domain design standard stipulates that the domain should be divided into core domain, general domain and supporting domain; Domain division is achieved by analyzing the main business functions. The domain-driven design method for production and warehouse management business is divided into four core domains: production management, warehouse management, energy and carbon management, and safety management. The domain design standard stipulates that the general domain contains unified interfaces for related technical components. The general domain includes technical components for notifications, process management, and document management. The domain design standard stipulates that the supporting domain is a general-purpose basic data service, which includes user management and master data management. The domain design standard stipulates that each core domain must be divided into subdomains based on the domain design standard, based on the rules defined in the domain design standard for subdomain division. S2. Aggregate and divide by domain design standards. Domain design standards are divided into two stages: In the first phase, we extract the main business links and identify domain objects using the four-color modeling method defined by the domain design standard. Domain objects include entity models, value objects, domain events, and domain services. In the second phase, the aggregation and partitioning of domain objects is achieved through the defined aggregation and partitioning method, and the business logic is encapsulated through domain services; S3. Identify bounded contexts through domain design standards. This standard divides microservices into the aggregate service layer and the atomic service layer. The domain design standard specifies the specific basis for the division of aggregate services and atomic services. Aggregation services meet complex business needs by orchestrating atomic services, enabling rapid assembly and flexible orchestration of atomic services. S4. Develop atomic services using a four-layer code architecture, which includes the user interface layer, application layer, domain layer, and infrastructure layer. S5. Implement cross-domain business processes through microservice orchestration. Cross-domain business processes include production planning and scheduling, quality inspection execution feedback, and dynamic updates of warehouse inventory.

2. The domain-driven design method for production and warehouse management business according to claim 1 is characterized in that: The subdomain division rules in S1 specifically include: Each subdomain can solve independent business problems and is operated by an independent department, organization or position; There are clear, one-way functional or data dependencies and call relationships between subdomains; Each subdomain only has one clear business responsibility and is reflected in the system design as one or several independent first-level functional items.

3. The domain-driven design method for production and warehouse management business according to claim 2 is characterized in that: The subdomains in S1 are divided as follows: The production management subdomain includes production planning management, production execution management, production quality inspection management, and production process management; The warehouse management subdomain includes procurement management and inventory management; The energy and carbon management subdomain includes basic library management, energy business management, carbon emission business management, and carbon asset management; The security management subdomain includes alarm strategies, basic security information, operation management, security prevention management, security situation awareness, and emergency assistance management.

4. The domain-driven design method for production and warehouse management business according to claim 2 is characterized in that: The four-color modeling implementation standards for domain design standards in S2 include: The time-scale object of the four-color modeling must be a specific business activity that can generate entity objects as participants and use the time-scale object as a business object; The participant is a specific entity object used to reflect the business generated, and the participant is regarded as the entity object.

5. The domain-driven design method for production and warehouse management business according to claim 4 is characterized in that: The rules for clustering and partitioning entities identified by the four-color modeling method in S2 include: Entity objects that have direct associations are grouped into the same aggregate; Entity objects are divided into different aggregates through business objects. Different entities divided by specific businesses belong to different aggregates. The aggregate root is directly connected to the business object, and the business object generates domain services for adding, deleting, modifying and checking.

6. The domain-driven design method for production and warehouse management business according to claim 4 is characterized in that: The methods for dividing bounded contexts in S3 include: Divide bounded contexts into subdomains, and mark derivative or subordinate associations within subdomains based on the business logic relationship between aggregations; The association method is marked according to the business logic relationship between aggregations. The business logic relationship includes: business derivation and business affiliation; find the core nodes of core node business derivation and business affiliation.

7. The domain-driven design method for production and warehouse management services according to claim 1, characterized in that: The granularity of atomic services meets the principles of high cohesion and low coupling. Atomic services expose service capabilities through Restful interfaces; aggregate services implement business logic orchestration by calling atomic service interfaces.

8. The domain-driven design method for production and warehouse management services according to claim 1, characterized in that: The infrastructure layer interacts with the database through MyBatis, the domain layer isolates business logic and data persistence through the storage interface, and the application layer calls domain services to complete business orchestration.

9. The domain-driven design method for production and warehouse management services according to claim 1, characterized in that: Microservice orchestration implements cross-service calls through the Feign client. The production execution service calls the process management service to obtain recipe parameters and triggers the quality inspection execution service to generate a quality inspection report.

Images