Domain model architecture and adjustment method of blood purification system

Abstract

The present invention relates to a domain model architecture of a blood purification system and an adjustment method thereof, aiming to solve the problems of insufficient system scalability and difficulty in functional integration, maintenance and upgrading in the prior art. The domain model architecture includes a user interface layer, an application layer, a domain layer and a basic layer. The user interface layer is responsible for providing an intuitive UI and operation logic; the application layer implements technical services for specific medical scenarios; the domain layer manages complex business logic by aggregating entities and value objects to reduce module coupling; the basic layer supports technical infrastructure such as data storage, communication, and logging. On the whole, the present invention effectively improves the functional integration and upgrade convenience of the blood purification system through a flexible architecture and adjustment mechanism.

Description

Technical Field

[0001] The present invention relates to the technical field of data processing, and in particular to a domain model architecture of a blood purification system and an adjustment method thereof. Background Art

[0002] In the modern medical system, blood purification is an important treatment method with wide application. However, existing blood purification systems often face the problem of insufficient scalability and flexibility. Existing systems are often difficult to quickly adapt to the needs of new equipment, new technologies or new treatment methods. This is mainly because the system design is too rigid, making it difficult to effectively expand and adjust functions. This limitation makes it difficult for the system to provide timely and efficient solutions in the face of evolving medical needs.

[0003] In addition, as the recognition of functional requirements continues to increase, existing systems are also facing challenges in functional integration. There is a high degree of coupling between the functional modules of the system, which makes it difficult to achieve seamless integration and efficient updates when optimizing and upgrading functions. The complex coupling of functional logic not only makes the maintenance of the system extremely cumbersome, but also requires re-verification of the stability of the overall system after the upgrade, which reduces the security of the system and increases the risk during the upgrade process. This situation often makes the system appear stretched when facing complex business logic and difficult to adapt to changing needs.

[0004] There is currently no effective solution to the technical problems of insufficient system scalability and difficulty in functional integration, maintenance and upgrading in the existing technology. Summary of the invention

[0005] The main purpose of the present invention is to provide a domain model architecture of a blood purification system and an adjustment method thereof, so as to solve the technical problems existing in the prior art of insufficient system scalability and difficulty in functional integration, maintenance and upgrading.

[0006] To achieve the above objectives, the present invention provides a domain model architecture for a blood purification system, the domain model architecture comprising: a user interface layer, an application layer, a domain layer, and a basic layer; the user interface layer is used to provide a UI and operation logic for human-computer interaction to ensure that users can intuitively operate and manage system functions; the application layer is used to implement technical services for specific medical scenarios, assemble and manage various types of treatment applications in the blood purification process; the domain layer is used to organize and manage business logic, and achieve efficient processing of various treatment modes of blood purification by aggregating entities and value objects, thereby reducing the coupling between modules; the basic layer is used to support the system's technical infrastructure, including at least data storage services and communication services.

[0007] The present invention also provides a method for adjusting the domain model architecture of a blood purification system, which is applied to the domain model architecture of the above-mentioned blood purification system, and the method for adjusting the domain model architecture includes: determining a user adjustment instruction, wherein the user adjustment instruction includes at least any one of the following: deleting a target object, adding a target object, and modifying a target object, wherein the target object is an entity and / or a value object; determining the business logic and data storage of the target object to be adjusted, and adjusting the business logic and data storage of the target object to be adjusted based on the user adjustment instruction; determining, according to the business logic of the target object to be adjusted, related target objects that have an association relationship with the target object to be adjusted, and determining a reference dependency path between the target object to be adjusted and the related target objects; based on the reference dependency path, combined with the adjustment content of the business logic and data storage of the target object to be adjusted, adjusting the business logic of the related target object.

[0008] The present invention also provides a computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of any one of the above methods when executing the computer program.

[0009] The present invention also provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned methods are implemented.

[0010] The domain model architecture of the blood purification system provided by the present invention and its adjustment method solve the problems of insufficient system scalability and difficulty in function integration, maintenance and upgrading through clear hierarchical division and flexible adjustment mechanism. The domain model architecture includes a user interface layer, an application layer, a domain layer and a basic layer, wherein the domain layer reduces the coupling between modules by aggregating entities and value objects, thereby improving the flexibility and maintainability of the system. The adjustment method allows the user to flexibly delete, add or modify entities and value objects according to needs, and make corresponding adjustments to business logic and data storage. By identifying the associated target objects and reference dependency paths of the target object, the present invention can ensure the logical consistency and stability of the system after adjustment, thereby improving the scalability and adaptability of the system. The application of computer equipment and storage media further realizes the automated execution of the adjustment method, making system maintenance and upgrading more efficient. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 is a schematic diagram of a domain model architecture of a blood purification system in one embodiment of the present invention; Figure 2 is a flow chart of a method for adjusting a domain model architecture of a blood purification system in one embodiment of the present invention; Figure 3It is a schematic block diagram of the structure of a computer device according to an embodiment of the present invention.

[0012] The realization of the purpose, functional features and advantages of the present invention will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0013] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0014] Reference Figure 1 The embodiment of the present invention provides a domain model architecture of a blood purification system, and the domain model architecture includes: a user interface layer, an application layer, a domain layer, and a basic layer; the user interface layer is used to provide a UI and operation logic for human-computer interaction to ensure that users can intuitively operate and manage system functions; the application layer is used to implement technical services for specific medical scenarios, assemble and manage various treatment applications in the blood purification process; the domain layer is used to organize and manage business logic, and realize efficient processing of various treatment modes of blood purification by aggregating entities and value objects, and reduce the coupling between modules; the basic layer is used to support the technical infrastructure of the system, including at least data storage services and communication services.

[0015] The domain model architecture of the blood purification system provided in the embodiment of the present invention solves many challenges faced by existing systems in terms of functional integration, maintenance and scalability through multi-level design, especially the aggregate entity design of the domain layer. Due to the high coupling between functional modules, it is difficult to achieve seamless integration during optimization and upgrading of existing systems, resulting in reduced system stability and complicated maintenance. This situation is particularly evident when facing complex business logic, because existing systems are often unable to flexibly respond to changing needs and new technological developments, and this limitation is one of the key problems that the domain model architecture is intended to solve.

[0016] First, the domain model architecture greatly reduces the coupling degree between the functional modules through the hierarchical design of the user interface layer, application layer, domain layer and basic layer, thereby realizing the advantages of modular design. In traditional systems, the various functional modules are often tightly coupled, so that the upgrade or change of any function may trigger a chain reaction, and even require re-verification of the stability of the entire system. For example, in the existing blood purification system, if a certain treatment mode needs to be optimized, such as modifying the pre-filling method of a specific treatment mode, it may affect the logical structure of other treatment modes, resulting in overall instability of the system. In the domain model architecture of the present invention, the domain layer ensures low coupling and high cohesion between the various functional modules through the separation design of aggregate entities, entities and value objects. In this way, when a module needs to be optimized or adjusted, the logical structure of other modules will not be affected, making the maintenance and upgrade of the system more efficient.

[0017] Specifically, the domain layer is the core of the architecture, and the use of domain services and aggregate entities greatly improves the flexibility and scalability of the system. The concept of aggregate entities emphasizes the processing of business logic by combining related business objects (i.e., entities and value objects). Entities are business objects with unique identifiers, responsible for managing the status of various types of business data in the blood purification system, such as the management of different treatment modes (such as CVVH, CVVHD, CVVHDF); while value objects are used to represent business data and behaviors without unique identifiers, such as specific parameter configurations in the pre-filling mode (fast pre-filling, manual pre-filling, etc.). This design enables business logic to be efficiently processed and organized through the domain layer, thereby reducing the interdependence between modules. For example, when a new treatment mode needs to be integrated into the system, or the parameters of an existing mode need to be adjusted, the system can coordinate different entities and value objects through domain services and quickly make corresponding adjustments without making large-scale structural changes to the entire system. This greatly reduces the risks brought about by functional optimization and upgrading, and avoids the maintenance difficulties caused by functional coupling in traditional systems.

[0018] In addition, the custom adjustment mechanism introduced in the domain layer further improves the flexibility of the system. By allowing users to customize the entities and value objects in the aggregate entity, the system can be flexibly configured according to different patient needs or new treatment plans. This means that the blood purification system can better adapt to the personalized treatment needs of different patients and quickly adjust treatment parameters, thereby improving the accuracy and efficiency of medical services. For example, when a patient's condition requires a specific treatment mode, and this mode needs to be adjusted for a specific pathological state, the system can add or modify the business logic and behavior of the entity through the custom adjustment function without significantly changing the existing system structure. This flexibility is difficult to achieve in traditional systems, because traditional systems often require the redesign or modification of multiple functional modules, and even affect the core logical structure, resulting in system instability.

[0019] The design of the basic layer provides technical infrastructure support to ensure the effectiveness of data storage, communication, and system integration. For example, database and cache services can efficiently store and manage large amounts of medical data generated during the blood purification process in the background, ensuring that the system can respond to user operation requests in real time. Communication services ensure data exchange between the system and external devices or other medical systems, thereby achieving seamless data sharing. In a blood purification system, data sharing and integration are particularly important because it is related to the patient's treatment effect and the accuracy of the system's decision-making. With the support of the basic layer, the system can achieve data sharing between different medical devices and platforms, ensuring that the patient's medical information is fully integrated and analyzed, thereby providing accurate decision-making support for medical staff.

[0020] In summary, the domain model architecture of the present invention solves the technical problems of insufficient system scalability and difficulty in functional integration and maintenance in the prior art by introducing multi-level design and flexible management mechanisms for aggregated entities, entities and value objects. Through the low-coupling and high-cohesion design of the domain layer, the system can flexibly respond to changing needs, achieve rapid adjustment and seamless integration, and avoid the upgrade risks caused by functional coupling in traditional systems. In addition, the basic layer provides strong technical support for the system, ensuring the secure management and efficient transmission of data, so that medical data can be fully shared and applied. In this way, the blood purification system of the present invention not only improves scalability and flexibility, but also greatly reduces the complexity of maintenance and upgrades, thereby improving the safety and stability of the system.

[0021] In one example, the domain layer includes: domain services and multiple aggregate entities, the domain services are used to implement business logic in the domain layer, the business logic at least includes complex logic that is not suitable for being placed directly in entities or value objects, and is used to coordinate different entities and value objects to complete business operations; the aggregate entities are used to combine and manage related business objects, wherein the business objects are implemented through entities and value objects.

[0022] In the design of the domain layer, domain services and aggregate entities are its core components. Domain services are responsible for implementing business logic, especially those complex logics that are not suitable for being placed directly in entities or value objects. Usually, these complex logics involve coordination between multiple business objects, and operations may need to be performed across multiple aggregate entities. For example, in a blood purification system, different treatment modes (such as CVVH, CVVHD) involve multiple entities and value objects. Domain services can coordinate these modes and dynamically adjust parameters to meet the personalized needs of patients. Domain services can also manage complex business processes, such as from patient information acquisition to automatic adjustment of treatment parameters. These logics are relatively complex and are not suitable for being placed in a single entity or value object.

[0023] Aggregate entities are used to combine and manage related business objects. Entities in aggregate entities have unique identifiers and are responsible for managing and tracking important data states in the system, while value objects are used to describe business data without unique identifiers. For example, in the blood purification process, entities can be specific treatment modes, while value objects may be parameter configurations under each treatment mode. By aggregating entities, these objects can work together efficiently, achieve modular management, and reduce coupling.

[0024] It should be noted that: compared with entities and value objects, domain services focus on logical operations that cannot be simply attributed to a single entity or value object. Specifically, in some business scenarios, the logic becomes more complex and may involve coordination and interaction between multiple entities and value objects. For example, treatment mode management in a blood purification system requires coordination of data flow and behavioral interaction between multiple entities and value objects such as device status, treatment parameters, and patient information. In this case, relying solely on the business logic of an entity or value object cannot fully implement complex operations.

[0025] Domain services exist to solve such complex business needs. They are located in the domain layer and act as a coordinator. Through domain services, business interactions between multiple entities and value objects can be effectively coordinated and managed. For example, in the blood purification process, when the system needs to adjust the operating parameters of the equipment according to the patient's treatment progress, the domain service will coordinate multiple objects such as the equipment entity, the treatment parameter value object, and the treatment mode entity to ensure the consistency of data transmission and operation between these objects. This complex logic across entities and value objects cannot be placed directly in a certain entity or value object, otherwise it will lead to excessive coupling, making the system difficult to maintain and expand.

[0026] In addition, domain services are flexible. They can dynamically handle business operations of different entities and value objects, which means that domain services can not only simplify the complex business logic in the system, but also improve the maintainability and scalability of the system by reducing the coupling between entities and value objects. In the face of changing business needs, domain services can be adjusted without frequently modifying specific entities or value objects. This architectural design can better adapt to changing requirements in complex business scenarios and improve the overall performance and stability of the system.

[0027] In one example, the aggregate entity includes: an entity and a value object, wherein the entity is used in the domain layer to represent a business object with a unique identifier, includes at least entity data and business logic and behavior related to the entity data, and is used to track and manage the status of the business data; the value object is used to describe business data without a unique identifier, includes at least a set of attribute data and business behavior related to the attribute data, is used to provide a detailed description and processing method of the business data, and is used to support the business logic and behavior of the entity.

[0028] In this example, the aggregate entity includes entities and value objects, which are used to represent different business objects and data processing methods in the system. Entities are core business objects in the domain layer. They have unique identifiers and represent elements with independent business significance in the system. Entities not only contain specific data content, but also have business logic and behaviors related to these data. For example, in a blood purification system, an entity can be a specific treatment mode (such as CVVH, CVVHD, etc.), which is responsible for managing the operating status, parameter configuration, and related treatment processes of the treatment mode. The core function of an entity is that it can track and manage all business data related to the treatment mode and ensure the uniqueness and consistency of these data in the system.

[0029] On the other hand, value objects do not have unique identifiers and are used to describe business data that does not require unique identification. Value objects are mainly used to define a set of attribute data in a business process and the behaviors associated with these attributes. The essence of a value object is a data structure that can describe the content and processing methods of business data in detail. For example, in a blood purification system, a value object can represent specific parameter settings for different treatment modes, such as flow rate, pressure, pre-filled liquid type, etc. Although these data are critical to the treatment process, they do not need to be individually identified. Value objects usually exist as part of an entity collaboration to support the business logic and behavior of the entity and help achieve detailed management and processing of business data.

[0030] Through this design, entities and value objects can collaborate efficiently. Entities are responsible for managing high-level business logic and data status, while value objects provide detailed descriptions and operations on business data. This separation design enhances the flexibility and scalability of the system while maintaining data consistency and integrity.

[0031] In one example, the aggregate entity can be customized in the domain model architecture, wherein the customized adjustment of the aggregate entity includes: deleting, adding and modifying target objects, and the target objects include: the aggregate entity, the entity and the value object.

[0032] In this example, the architecture of the domain model has the ability to customize aggregate entities, which means that users or system administrators can flexibly adjust aggregate entities according to specific business needs. Aggregate entities are key structures in the domain model, responsible for combining and managing related business objects. Therefore, the ability to customize aggregate entities can greatly improve the flexibility and adaptability of the system, ensuring that it can respond and adjust in a timely manner in the face of changing needs.

[0033] The specific operations for customizing aggregate entities include deleting, adding, and modifying target objects. These target objects are not only the aggregate entity itself, but also the specific elements in the aggregate entity: entities and value objects. The delete operation can remove the aggregate entity that is no longer needed or one of the entities and value objects in it to simplify the system architecture and avoid unnecessary redundancy. The add operation allows new business objects to be added to the existing aggregate entity, supporting the expansion of the system and meeting the needs of new business scenarios. The modify operation is used to update an object in the aggregate entity. Whether it is the data attributes of the entity, the business logic, or the specific parameters of the value object, it can be flexibly adjusted according to the needs.

[0034] For example, in a blood purification system, when a new treatment mode is introduced, the system administrator can add the entities and value objects corresponding to the treatment mode to the existing aggregate entity through the add operation to expand the system function. Similarly, if a treatment mode has been eliminated, the delete operation can remove the corresponding entity and value object from the aggregate entity to ensure that the system remains simple and efficient. Through this custom adjustment mechanism, the system can more flexibly respond to complex business scenarios and changing functional requirements.

[0035] In one example, the entities include at least a treatment mode entity, a device entity, a patient entity, and a treatment record entity, wherein the treatment mode entity includes at least: a continuous veno-venous hemofiltration entity, a continuous veno-venous hemodialysis entity, and a continuous veno-venous hemofiltration dialysis, and the device entity includes at least: a blood purification machine entity and a filter entity.

[0036] In this example, entities are used to represent business objects with unique identifiers, ensuring that the system can track and manage key data related to blood purification. Specifically, entities include treatment mode entities, equipment entities, patient entities, and treatment record entities. Each entity carries different categories of business information, and through these entities, the system can efficiently organize and manage blood purification operations.

[0037] First, the treatment mode entity is used to represent the different treatment methods used in the blood purification process. It includes at least three types: continuous venovenous hemofiltration entity (CVVH), continuous venovenous hemodialysis entity (CVVHD), and continuous venovenous hemofiltration dialysis entity (CVVHDF). Each treatment mode entity contains specific treatment parameters and operation logic to handle different treatment needs. For example, the CVVH entity may contain key parameters such as filtration rate and blood flow rate, while the CVVHD entity mainly involves the use of dialysate.

[0038] Secondly, the equipment entity includes the actual equipment used to perform blood purification, such as the blood purification machine entity and the filter entity. The blood purification machine entity represents the core equipment for operating blood purification, controlling all processes and operating parameters. The filter entity represents the filtering device used to remove waste and toxins from the blood, and each filter has a specific filtering efficiency and lifespan. In the system, these equipment entities allow the system to monitor and manage the status, maintenance information, and operation records of the equipment.

[0039] Through the definition of these entities, the system can flexibly manage different treatment modes and equipment in complex treatment scenarios. The treatment mode entity can select different treatment methods according to the patient's condition, and the equipment entity ensures the efficient operation of the equipment while maintaining the accuracy of the treatment records. This design ensures the orderliness of business logic and data processing, so that the system can provide accurate data support when processing various treatment modes and ensure the normal operation of the equipment.

[0040] In one example, the value object includes at least: a pre-charge value object, a treatment parameter value object, a device configuration value object, and a treatment status value object. The pre-charge value object includes: a fast pre-charge attribute value, a manual pre-charge attribute value, and an arteriovenous pot liquid level adjustment value. The treatment parameters include: filtration parameters and dialysis parameters. The device configuration includes: device setting parameters and filter specification parameters. The treatment status includes: treatment progress parameters and treatment process parameters.

[0041] In this example, value objects are used to represent business data without unique identifiers. They are mainly a collection of attributes and parameters required for various operations and processes in the system. These value objects provide support for the operation of entities and describe the specific data content required for the system to perform specific operations or settings. Specifically, value objects include pre-charge objects, treatment parameter value objects, device configuration value objects, and treatment status value objects.

[0042] First, the pre-fill object contains values ​​used to initialize or adjust pre-treatment settings. In the blood purification process, pre-filling is to adjust the liquid level in the device before the treatment begins to ensure the safety and smooth progress of the treatment. The pre-fill object contains three main attribute values: the fast pre-fill attribute value, which represents the option to quickly complete the liquid filling in the device; the manual pre-fill attribute value, which is used to manually adjust the liquid filling; and the arteriovenous pot liquid level adjustment value, which is used to fine-tune the liquid level height in the arteriovenous circuit. Through these pre-fill attribute values, the system can quickly or manually complete the pre-fill operation according to different treatment requirements to ensure that the device and patient status are ready.

[0043] Secondly, the treatment parameter value object covers the key parameters that need to be set during the treatment process, including at least filtration parameters and dialysis parameters. Filtration parameters indicate the rate or efficiency of waste filtration during blood purification, while dialysis parameters involve the flow rate and concentration of the dialysate. In different treatment modes of blood purification (such as CVVH, CVVHD, etc.), these parameters are dynamically adjusted to ensure the effectiveness and safety of the treatment.

[0044] Next, the device configuration value object is used to manage the device's setting parameters and configuration properties. It includes at least device setting parameters and filter specification parameters. The device setting parameters describe the blood purification machine's operating settings, such as pump speed, alarm settings, etc., while the filter specification parameters indicate the specific model of the filter, its filtering capacity, and its replacement cycle. These value objects allow the system to flexibly configure the device to adapt to the treatment needs of different patients and the maintenance cycle of the device.

[0045] Finally, the treatment status value object is used to describe the relevant information about the treatment process and treatment progress, including at least treatment progress parameters and treatment process parameters. Treatment progress parameters are used to track the completion of the entire treatment, such as whether the treatment is completed within the scheduled time; treatment process parameters record various states during treatment, such as the operation of the equipment, the flow of fluids, etc. These value objects help the system track the progress of treatment in real time and provide key data for operators or medical staff to refer to.

[0046] In general, these value objects provide detailed and specific parameter and attribute support for the blood purification system, ensuring the flexibility and accuracy of the system. They play an important role in parameter setting, equipment adjustment and status monitoring in complex treatment processes, ensuring the accuracy and efficiency of each treatment.

[0047] It should be noted that in the actual research and development process, after building the domain model architecture of the above-mentioned blood purification system, how to allocate entities, value objects and domain services still requires overcoming many difficulties.

[0048] For example, in a blood purification system, business requirements are complex and diverse, and the business logic needs to be reasonably split and mapped to the domain model. In particular, when determining which logic should be handled by entities and which by value objects, it is often necessary to comprehensively consider the stability of the business, the frequency of changes, and the relationship between logics. If the allocation is inappropriate, it will lead to rigid or unnecessary complexity of the code structure, affecting the maintainability of the system.

[0049] For example, the boundary division of aggregate entities is crucial in domain-driven design, which involves how to combine interrelated business objects to form independent consistent units. In the blood purification system, there are complex dependencies between different treatment modes, equipment, patient information, etc., and the boundaries need to be reasonably divided to reduce the coupling between aggregate entities while ensuring the integrity and consistency of the system's business logic. In this process, a balance needs to be struck between reducing the complexity of aggregate entities and ensuring system performance.

[0050] For example, the design of domain services needs to coordinate the interactions between different entities and value objects to realize the core business functions of the system. In the blood purification system, the treatment process involves real-time dynamic interactions between multiple devices and patient data. Therefore, domain services must not only accurately schedule the behavior of each entity, but also ensure the flexibility and scalability of business logic. How to maintain the simplicity and scalability of domain services when the business logic is highly complex is a difficult problem that needs to be solved urgently.

[0051] For example, when building a blood purification system, the domain layer needs to avoid directly relying on the implementation details of the base layer, such as databases, communication services, etc. However, in actual R&D, domain logic is often inevitably coupled with the infrastructure, especially when dealing with device communication and data storage, which can easily lead to changes in business logic causing large-scale adjustments to the underlying implementation. This coupling will affect the system's expansion and maintenance capabilities, and it is necessary to find an effective way to isolate business logic from technical details.

[0052] In order to solve these difficulties, this application introduces intelligent diagnosis and dynamic dependency management mechanisms, refines the division of responsibilities of domain services, and enhances the flexibility and scalability of the system. In the domain layer, by introducing the strategy model, the selection and adjustment of treatment modes are more flexible; the event-driven module can automatically respond to internal and external events in the system, improving the automation level of business processing; through the intelligent diagnosis module, auxiliary decision support is provided to medical personnel, thereby effectively alleviating the difficulties in the allocation process of entities, value objects and domain services, and improving the overall robustness and intelligence level of the system.

[0053] Specifically, the following method can be used to build the domain model architecture of the blood purification system: Step 1: Determine the key business objects in the blood purification system, model the key business objects in the blood purification system, construct a basic business object model, and obtain a basic business object set including treatment mode entity, equipment entity, patient entity and treatment record entity.

[0054] That is, the construction of the basic business object model is the basis of domain modeling. By conducting a detailed analysis of the key business objects in the blood purification system, the roles and functions of each object in the system are clarified, thus forming a stable set of entities and value objects. In this way, not only can the responsibilities of each business object be clearly defined, but also the coupling between system modules can be effectively reduced. For example, the treatment mode entity is used to describe different types of treatment plans, the equipment entity contains equipment information such as blood purification machines and filters, the patient entity is responsible for recording the patient's personal information and treatment status, and the treatment record entity is used to track and store detailed records of the entire treatment process. This design can ensure the scalability and maintainability of the system in subsequent steps.

[0055] Step 2: Perform strategy pattern introduction processing on the basic business object set to obtain a strategy set for dynamically selecting and switching treatment modes.

[0056] Specifically, the treatment mode analysis and processing is performed on the basic business object set to obtain the key business logic set corresponding to each treatment mode; the policy interface definition processing is performed on the key business logic set to obtain the policy interface for encapsulating different treatment logics; the policy interface is processed for treatment mode implementation to obtain a specific policy class set for different treatment modes; the specific policy class set is abstracted to obtain a policy abstract factory for dynamic selection; the policy abstract factory is processed for treatment demand input to obtain a treatment strategy instance suitable for the current treatment scenario; the treatment strategy instance is dynamically switched to obtain a final treatment strategy set for realizing dynamic selection and switching of treatment modes.

[0057] In other words, in the process of introducing the strategy pattern into the basic business object set, it is first necessary to analyze the key business logic of each treatment mode and obtain the business logic set of different treatment modes. Then, a corresponding strategy interface is defined for each treatment mode to encapsulate the implementation details of the specific treatment logic. Through the definition of this interface, it can be ensured that different treatment modes can be flexibly switched in the actual treatment process to adapt to the different needs of patients. On this basis, the strategy interface is further implemented to form a set of different treatment mode strategy classes, such as the continuous veno-venous hemofiltration (CVVH) strategy class and the continuous veno-venous hemodialysis (CVVHD) strategy class. Then, these specific strategy classes are abstracted to obtain a strategy abstract factory for dynamic selection. Through this factory, according to the actual patient needs during the treatment process, the corresponding parameters are input to dynamically generate suitable treatment strategy instances. Finally, these instances are dynamically switched to form the final strategy set, which can flexibly respond to the needs of different treatment scenarios. This design makes the entire system more flexible in processing complex business logic and can efficiently respond to the personalized treatment needs of patients.

[0058] Step 3: Perform domain service definition processing on the policy set, refine the responsibilities of the domain service, and obtain the domain service component that coordinates the basic business object set and the policy set to execute the core business functions.

[0059] Specifically, perform core business demand analysis on the policy set to obtain the core business operation set involved in the policy set; perform service responsibility division on the core business operation set to obtain a preliminary domain service list corresponding to different core business operations; perform dependency analysis on the preliminary domain service list to obtain a dependency graph between domain services; perform responsibility adjustment on the dependency graph to obtain an optimized domain service responsibility allocation plan; perform service interface definition on the domain service responsibility allocation plan to obtain a domain service interface that coordinates the basic business object set and the policy set; perform specific implementation on the domain service interface to obtain a final domain service component for executing core business functions.

[0060] In other words, when the policy set is processed for domain service definition, the core business requirements in the policy set need to be analyzed in detail first, and the core business operation set involved is extracted. These operation sets need to be effectively executed in the system, so the responsibilities of each core business operation are divided to form a preliminary domain service list. Through this division of responsibilities, it can be ensured that each domain service has a clear task in the system to avoid repeated or ambiguous responsibility allocation. Next, the dependency analysis is performed on the preliminary domain service list to obtain the dependency graph between domain services to ensure that the cooperation relationship between each service is clear and reasonable. According to the dependency graph, the responsibilities of each domain service can be further optimized and adjusted to ensure that the responsibility allocation of each service is optimal. Then, the service interface definition is performed for the optimized responsibility allocation scheme to form a domain service interface that can coordinate the basic business object set and the policy set. Finally, by implementing these interfaces, the final domain service component is obtained to perform the core business functions. In this way, it is ensured that the domain service component can effectively coordinate the business objects and the policy set, thereby efficiently completing the core operations in the blood purification process.

[0061] Step 4: introduce a dynamic dependency management mechanism into the domain service component to obtain dynamic dependency management rules for adjusting the dependency between entities and value objects in the basic business object set.

[0062] Specifically, the domain service component is subjected to dependency identification processing to obtain a dependency list of entities and value objects involved in the domain service component; the dependency list is subjected to dependency type classification processing to obtain a dependency classification set of different types; the dependency classification set is subjected to dynamic adjustment demand analysis processing to obtain a dependency set that needs to be dynamically adjusted; the dependency set that needs to be dynamically adjusted is subjected to management strategy design processing to obtain a management strategy for dynamically managing dependencies; the management strategy is subjected to rule definition processing to obtain dependency management rules for dynamically adjusting dependencies; the dependency management rules are integrated to obtain the final dynamic dependency management rules, which are used to adjust the dependencies between entities and value objects in the basic business object set.

[0063] In other words, when the dynamic dependency management mechanism is introduced into the domain service component, the dependency relationships in the domain service component must first be identified to obtain the dependency list of the entities and value objects involved. These dependencies may be fixed or may need to be dynamically adjusted according to business needs, so the dependency list needs to be classified to form different types of dependency sets. Next, the dynamic adjustment requirements of these dependency sets are analyzed to determine which dependencies need to be dynamically adjusted in different situations. Then, for these dependencies that need to be dynamically adjusted, corresponding management strategies are designed to ensure that the system can automatically adjust the dependencies to adapt to changing needs in different business scenarios. Next, these management strategies are defined by rules to form specific dependency management rules to ensure that dynamic adjustment can be achieved during system operation. Finally, these dependency management rules are integrated into the domain service component to form the final dynamic dependency management rules, which are used to dynamically adjust the dependencies between entities and value objects in the basic business object set. In this way, the system can automatically adjust the dependencies according to the actual situation at runtime, which improves the flexibility and ability of the system to cope with changes.

[0064] Step 5, integrate the dynamic dependency management rules into an event-driven module to obtain an event-driven module for monitoring and responding to internal and external events in the system, and automatically triggering the domain service component to execute the corresponding business logic.

[0065] Specifically, the dynamic dependency management rules are analyzed for event types to obtain a list of internal and external system events that need to be monitored; the event list is processed for event priority definition to obtain an event priority table sorted by importance; the event processing flow design is performed on the event priority table to obtain a set of processing flows for different events; the processing flow set is processed for event triggering conditions to obtain event triggering rules for automatic response; the event triggering rules are modularly integrated to obtain a preliminary event-driven module architecture; the event-driven module architecture is subjected to system integration testing to obtain the final event-driven module, which is used to monitor and respond to internal and external events of the system and automatically trigger domain service components to execute corresponding business logic.

[0066] In other words, when integrating dynamic dependency management rules into the event-driven module, it is first necessary to analyze the types of internal and external events that may occur in the system to form a list of events that need to be monitored. Next, define the priority of these event lists and determine the processing order according to the importance of the events to ensure that the system can give priority to key events when multiple events occur. Then, define the corresponding processing flow for each event to form a processing flow set to clarify the response measures for each event. On this basis, set the trigger conditions for the processing flow set and define the trigger rules for each event to ensure automatic response when the event occurs. Next, modularize these trigger rules to form a preliminary event-driven module architecture, and perform system integration testing on it to ensure that the module can correctly monitor and respond to events. Finally, the final event-driven module is obtained, which is used to monitor and respond to various events in the system and automatically trigger the domain service component to execute the corresponding business logic. In this way, the system can achieve automatic response to internal and external events and improve the automation and real-time performance of business processing.

[0067] Step 6, construct an intelligent diagnosis module for the basic business object set, strategy set, domain service component and event-driven module to obtain an intelligent diagnosis module, which is used to generate optimization suggestions through data analysis and feed back to the domain service component to further adjust the treatment strategy and dependency management.

[0068] Specifically, the data collection demand analysis is performed on the basic business object set, strategy set, domain service component and event-driven module to obtain the data collection plan required by the intelligent diagnosis module; the data source integration is performed on the data collection plan to obtain a unified data input interface for collecting key business data in system operation; the data input interface is preprocessed to obtain a cleaned and standardized data set to ensure the accuracy and consistency of data analysis; the data set is processed for diagnostic algorithm selection to obtain an intelligent diagnosis algorithm model suitable for treatment optimization; the intelligent diagnosis algorithm model is processed for optimization suggestion generation to obtain an optimization suggestion set for treatment strategies and dependencies; the optimization suggestion set is processed for feedback integration to obtain an intelligent diagnosis module, which is used to generate optimization suggestions through data analysis and feed back to the domain service component to further adjust the treatment strategy and dependency management.

[0069] In other words, when building the intelligent diagnosis module, firstly, the data collection requirements of the basic business object set, strategy set, domain service component and event-driven module are analyzed to form the data collection scheme required by the intelligent diagnosis module to ensure that the key data in the system operation can be collected. Then, the data source is integrated and processed for the data collection scheme to form a unified data input interface so that the intelligent diagnosis module can smoothly obtain various types of data in the system operation. After acquiring the data, the data are preprocessed, and after cleaning and standardization, a data set with good consistency is formed to ensure that the subsequent data analysis is accurate and reliable. Then, based on the preprocessed data set, a diagnostic algorithm model suitable for treatment optimization is selected to ensure that the system operation status can be effectively evaluated during the analysis process. Next, the diagnostic algorithm model is used to generate a set of optimization suggestions for treatment strategies and dependencies. These suggestions can provide data support and optimization direction for subsequent system adjustments. Finally, these optimization suggestions are integrated with the domain service components for feedback to form a complete intelligent diagnosis module, so that the system can continuously optimize treatment strategies and dependency management through data analysis, improve treatment effects and the intelligence level of the system.

[0070] In summary, in the domain model architecture of the blood purification system, by gradually building basic business objects, introducing strategy patterns, refining domain services, introducing dynamic dependency management mechanisms, integrating event-driven modules, and finally building intelligent diagnosis modules, an efficient, flexible, and intelligent analysis-capable system solution is formed. The innovation of this solution is reflected in many aspects. First, through the introduction of strategy patterns, flexible selection and switching of treatment modes are achieved, ensuring that the system can adapt to a variety of complex treatment needs. Secondly, by refining the responsibilities of domain services and introducing dynamic dependency management mechanisms, the flexibility of the system in business logic processing is enhanced, the coupling between modules is reduced, and the system is easier to maintain and expand. In addition, the integration of event-driven modules enables the system to automatically respond to internal and external events, further improving the system's real-time processing capabilities and automation level. The introduction of intelligent diagnosis modules enables the system to continuously optimize and improve the treatment process, thereby improving the overall treatment effect and the auxiliary ability of medical decision-making. Such a design takes into account the complexity of business logic, the scalability and intelligence requirements of the system, and overcomes the problems of excessive coupling between system modules and excessive dependence on infrastructure, providing a solid technical foundation for the realization of an efficient and reliable blood purification system.

[0071] In one example, the basic layer also includes: a database, a log, a CAN bus, a cache, peripherals and middleware. The database is used to store all persistent data in the system, including at least patient information, treatment records and equipment status; the log is used to record various events and operations during the operation of the system to facilitate system maintenance and troubleshooting; the CAN bus is used to achieve real-time communication between devices and support data exchange between blood purification equipment and other medical equipment; the cache is used to improve the response speed of the system and reduce the load on the database by temporarily storing commonly used data and calculation results; the peripherals include input devices and output devices for collecting and displaying medical data; the middleware is used to provide communication and coordination services between components within the system and realize data transmission and service calls between different modules.

[0072] In this example, the base layer is designed to support the overall operation of the blood purification system, provide the necessary underlying technical infrastructure, and ensure the stability, efficiency, and scalability of the system. The base layer contains several key components, which are used to handle data storage, system logs, device communication, performance optimization, peripheral management, and inter-module coordination.

[0073] First of all, the database is the core component for storing all persistent data in the system. It is responsible for saving important data such as patient information, treatment records, and equipment status. For example, the patient's medical history, treatment plan, and detailed records of each blood purification (such as treatment mode, parameter settings, etc.) will be saved in the database. The equipment status includes information such as the current operating status of the equipment and maintenance records. The persistent storage of these data ensures that the data is still available after the system is restarted or the equipment is replaced, and supports the query and analysis of historical data.

[0074] Next, the log system is used to record various events and operations during the operation of the system. These log files record various types of system operation information, such as the operating status of the equipment, the operation records of the operator, and system alarms. The role of the log is not only to help operators and system maintenance personnel track the operating status of the system, but also to quickly find the root cause of the problem when a fault occurs, perform troubleshooting and system repair. The log is an important tool for system maintenance and security monitoring, and can improve the reliability of the system.

[0075] CAN bus is a key communication mechanism in the basic layer, which is used to achieve real-time communication between different devices in the system. CAN bus supports fast and stable data exchange between blood purification equipment and other medical equipment (such as monitoring equipment, infusion pumps, etc.). This communication method can ensure the coordinated operation between different devices and ensure the real-time transmission of data when the devices are linked, thereby improving the overall efficiency and interoperability of the system.

[0076] The cache component plays an important role in optimizing the performance of the system. It reduces frequent access to the database by temporarily storing common data and calculation results, thereby reducing the load on the database. This enables the system to significantly improve the response speed when processing some high-frequency requests, thereby improving the user experience. For example, the system may frequently query the patient's basic information and common treatment parameters during operation. The cache can accelerate these queries and avoid direct access to the database every time.

[0077] Peripherals include input devices and output devices in the system, which are used to collect and display medical data. Input devices may include keyboards, touch screens, etc., for operators to input patient information or adjust treatment parameters; output devices may include display screens or printers to display real-time treatment data, device status, or output treatment reports. These peripherals ensure the interaction between the system and the operator and provide a convenient operation interface.

[0078] Finally, middleware provides communication and coordination services between components within the system. It acts as a "bridge" between different modules of the system, ensuring that data can be smoothly transferred between modules and supporting service calls between modules. For example, the business logic module in the domain layer needs to interact with the database of the base layer, and middleware can ensure that these calls are smoothly implemented between different modules. Middleware enables the various parts of the system to work better in coordination, reduces the coupling between modules, and improves the maintainability and scalability of the system.

[0079] In short, these basic layer components together constitute the technical infrastructure of the blood purification system, ensuring that the system can operate stably and efficiently, while providing necessary support for the expansion and maintenance of the system.

[0080] like Figure 2 As shown, an embodiment of the present invention further provides a method for adjusting the domain model architecture of a blood purification system. The method for adjusting the domain model architecture is applied to the domain model architecture of the blood purification system in the above embodiment. Specifically, the method for adjusting the domain model architecture includes: S1. Determine a user adjustment instruction, wherein the user adjustment instruction includes at least any one of the following: deleting a target object, adding a target object, and modifying a target object, and the target object is an entity and / or a value object.

[0081] S2, determining the business logic and data storage of the target object to be adjusted, and adjusting the business logic and data storage of the target object to be adjusted based on the user adjustment instruction.

[0082] S3, determining, according to the business logic of the target object to be adjusted, related target objects that are associated with the target object to be adjusted, and determining a reference dependency path between the target object to be adjusted and the related target objects.

[0083] S4: Based on the reference dependency path, combined with the business logic of the target object to be adjusted and the adjustment content of the data storage, the business logic of the relevant target object is adjusted.

[0084] That is, the embodiment of the present invention provides a method for adjusting the domain model architecture for a blood purification system, which aims to flexibly adjust the domain model in the system so that it can better adapt to changes in user needs and the complexity of business logic. The method optimizes business logic and expands system functions by dynamically adjusting entities and value objects in the system. Specifically, the method includes the following steps: First, in step S1, the system receives adjustment instructions from the user. These adjustment instructions can be operations to delete, add or modify target objects, where the target objects refer to entities and / or value objects in the system. Entities and value objects represent business data with unique identifiers and business data without unique identifiers in the system, respectively. For example, the user may want to delete a specific treatment mode entity or add a new device configuration value object.

[0085] Next, in step S2, the system determines the specific business logic and data storage content of the target object to be adjusted. Business logic involves the functional implementation of the target object, such as how an entity interacts with other entities, how to process data, etc. Data storage includes persistent data of the entity or value object, such as treatment parameters or device status. Based on the user's adjustment instructions, the system will make corresponding adjustments to these business logics and data storage. For example, if the user adds a new device configuration value object, the system needs to determine the attributes of the value object and its relationship with other objects, and store them correctly.

[0086] In step S3, the system analyzes the association relationship between the target object to be adjusted and other objects. Usually, the entities and value objects in the system are interrelated, and there are reference dependency paths between them. These paths describe how different business objects call or depend on each other. For example, the treatment mode entity may depend on a specific device configuration or treatment parameter value object. Therefore, when adjusting a target object, the system needs to determine the related target objects associated with it and identify the reference dependency paths between them to ensure that the adjusted business logic is still valid and does not destroy the functionality of the existing system.

[0087] Finally, in step S4, the system will adjust the business logic of the relevant target objects based on these reference dependency paths, combined with the previously determined business logic and data storage adjustment content. For example, if a user modifies certain attributes of a treatment parameter value object, the treatment mode entity associated with the value object may also need to synchronously update its business logic to ensure that it can continue to process these modified parameters normally. In this way, the system can maintain the coherence and consistency of the business logic and avoid system dysfunction due to the adjustment of a certain object.

[0088] In general, this adjustment method realizes the dynamic adjustment of the blood purification system domain model, ensuring that the system can flexibly adapt to new requirements and business changes. At the same time, by managing the reference dependency path, it ensures that the dependency relationship between various business objects remains correct after adjustment, enhancing the stability and scalability of the system.

[0089] In this embodiment, for the specific implementation of each unit in the above device embodiment, please refer to the above method embodiment, which will not be repeated here.

[0090] Reference Figure 3 In an embodiment of the present invention, a computer device is also provided. The computer device may be a server, and its internal structure may be as follows: Figure 3 As shown. The computer device includes a processor, a memory, a display screen, an input device, a network interface and a database connected through a system bus. Among them, the processor designed by the computer is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store the corresponding data in this embodiment. The network interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, the above method is implemented.

[0091] Those skilled in the art will understand that Figure 3 The structure shown in the figure is merely a block diagram of a portion of the structure related to the solution of the present invention, and does not constitute a limitation on the computer device to which the solution of the present invention is applied.

[0092] An embodiment of the present invention further provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, the above method is implemented. It can be understood that the computer-readable storage medium in this embodiment can be a volatile readable storage medium or a non-volatile readable storage medium.

[0093] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media provided by the present invention and used in the embodiments may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double-speed data rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM.

[0094] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, device, article or method including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, device, article or method. In the absence of further restrictions, an element defined by the sentence "includes a ..." does not exclude the presence of other identical elements in the process, device, article or method including the element.

[0095] The above description is only a preferred embodiment of the present invention, and does not limit the patent scope of the present invention. Any equivalent structure or equivalent process transformation made by using the contents of the present invention specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A domain model architecture for a blood purification system, characterized in that: The domain model architecture includes: user interface layer, application layer, domain layer, and basic layer; the user interface layer is used to provide UI and operation logic for human-computer interaction to ensure that users can intuitively operate and manage system functions; the application layer is used to implement technical services for specific medical scenarios, assemble and manage various treatment applications in the blood purification process; the domain layer is used to organize and manage business logic, and achieve efficient processing of various treatment modes of blood purification by aggregating entities and value objects, reducing the coupling between modules; the basic layer is used to support the system's technical infrastructure, including at least data storage services and communication services.

2. The domain model architecture according to claim 1, characterized in that: The domain layer includes: domain services and multiple aggregate entities. The domain services are used to implement the business logic in the domain layer. The business logic at least includes complex logic that is not suitable to be placed directly in entities or value objects, and is used to coordinate different entities and value objects to complete business operations; the aggregate entities are used to combine and manage related business objects, wherein the business objects are implemented through entities and value objects.

3. The domain model architecture according to claim 2, characterized in that: The aggregate entity includes: an entity and a value object. The entity is used in the domain layer to represent a business object with a unique identifier, and includes at least entity data and business logic and behavior related to the entity data, and is used to track and manage the status of the business data; the value object is used to describe business data without a unique identifier, and includes at least a set of attribute data and business behavior related to the attribute data, and is used to provide a detailed description and processing method of the business data, and is used to support the business logic and behavior of the entity.

4. The domain model architecture according to claim 3, characterized in that: The aggregate entity can be customized and adjusted in the domain model architecture, wherein the customized adjustment of the aggregate entity includes: deleting, adding and modifying target objects, and the target objects include: the aggregate entity, the entity and the value object.

5. The domain model architecture according to claim 3, characterized in that: The entities include at least a treatment mode entity, a device entity, a patient entity and a treatment record entity, wherein the treatment mode entity includes at least: a continuous veno-venous hemofiltration entity, a continuous veno-venous hemodialysis entity and a continuous veno-venous hemofiltration dialysis entity, and the device entity includes at least: a blood purification machine entity and a filter entity.

6. The domain model architecture according to claim 3, characterized in that: The value object at least includes: a pre-charge value object, a treatment parameter value object, a device configuration value object, and a treatment status value object. The pre-charge value object includes: a fast pre-charge attribute value, a manual pre-charge attribute value, and an arteriovenous pot liquid level adjustment value. The treatment parameters include: filtration parameters and dialysis parameters. The device configuration includes: device setting parameters and filter specification parameters. The treatment status includes: treatment progress parameters and treatment process parameters.

7. The domain model architecture according to claim 1, characterized in that: The basic layer also includes: database, log, CAN bus, cache, peripherals and middleware. The database is used to store all persistent data in the system, including at least patient information, treatment records and equipment status; the log is used to record various events and operations during the operation of the system to facilitate system maintenance and troubleshooting; the CAN bus is used to achieve real-time communication between devices and support data exchange between blood purification equipment and other medical equipment; the cache is used to improve the response speed of the system and reduce the load on the database by temporarily storing commonly used data and calculation results; the peripherals include input devices and output devices for collecting and displaying medical data; the middleware is used to provide communication and coordination services between components within the system and realize data transmission and service calls between different modules.

8. A method for adjusting the domain model architecture of a blood purification system, characterized in that: The domain model architecture adjustment method is applied to the domain model architecture of the blood purification system according to any one of claims 1 to 7, and the domain model architecture adjustment method comprises: Determine a user adjustment instruction, wherein the user adjustment instruction includes at least any one of the following: deleting a target object, adding a target object, and modifying a target object, wherein the target object is an entity and / or a value object; Determine the business logic and data storage of the target object to be adjusted, and adjust the business logic and data storage of the target object to be adjusted based on the user adjustment instruction; According to the business logic of the target object to be adjusted, determining a related target object that has an association relationship with the target object to be adjusted, and determining a reference dependency path between the target object to be adjusted and the related target object; Based on the reference dependency path, combined with the business logic of the target object to be adjusted and the adjustment content of the data storage, the business logic of the related target object is adjusted.

9. A computer device comprising a memory and a processor, wherein a computer program is stored in the memory, wherein: When the processor executes the computer program, the steps of the method according to claim 8 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to claim 8 are implemented.

Images