Scaffolding Construction Method and Application Development Method Based on Domain-Driven Design

Abstract

The present application discloses a method for building a scaffolding based on domain-driven design and an application development method. The building method includes: constructing multiple groups of functional modules based on domain-driven design that make up the scaffolding; defining the dependencies between each functional module to form multiple logical layers of the scaffolding, thereby obtaining the scaffolding. The multiple logical layers include: a foundation layer, a domain layer, an application layer, and a user interface layer. The present application realizes the rapid construction of a scaffolding based on domain-driven design, unifies the engineering construction specifications, enabling developers who want to use domain-driven design to be able to use it out of the box; and developers only need to focus on the implementation of their own business logic without having to concern themselves with the design of the application architecture, significantly reducing the time for building the application framework, improving the efficiency of application development, and reducing the human and time costs of application development.

Description

Technical Field

[0001] This application relates to the field of computer technology, and particularly to a method for building a scaffolding based on domain-driven design and an application development method. Background Art

[0002] With the deepening of business complexity and the three-high requirements of high availability, high concurrency, and high performance for applications, the corresponding application system architectures have also evolved from single-machine and centralized architectures to distributed microservice architectures. With the rise of distributed technologies, application systems have entered the era of microservice architectures.

[0003] To address the issues of boundary delineation and complex separation of technical implementations faced in the microservice design process, in 2004, Eric Evans published the book "Domain-Driven Design - Tackling Complexity in the Heart of Software", which proposed Domain-Driven Design (abbreviated as DDD).

[0004] However, the book only provides an architectural design methodology without a specific implementation architecture design. When external companies use DDD, they need to implement their own architectural scaffolding. In actual use, there are problems such as the lack of a specific implementation for building the scaffolding and a unified engineering construction specification, and the inability to quickly build the scaffolding. Developers not only need to focus on their own business logic but also have to build a software architecture based on DDD from scratch, which seriously consumes human and time costs.

[0005] It should be noted that the above description is only a background example and does not necessarily constitute prior art. Summary of the Invention

[0006] In view of the above problems, the embodiments of this application provide a method for building a scaffolding based on domain-driven design and an application development method, which can achieve the rapid construction of the scaffolding and a unified engineering construction specification.

[0007] In a first aspect, the embodiments of this application provide a method for building a scaffolding based on domain-driven design, the method including:

[0008] Constructing a plurality of domain-driven design-based functional modules that make up the scaffolding;

[0009] Defining the dependencies between the respective functional modules to form multiple logical layers of the scaffolding, obtaining the scaffolding, and the multiple logical layers include: a basic layer, a domain layer, an application layer, and a user interface layer.

[0010] Second aspect, an embodiment of the present application further provides a scaffolding building device based on domain-driven design, and the device includes:

[0011] A module construction unit, configured to construct a plurality of functional modules based on domain-driven design that make up the scaffolding;

[0012] A relationship definition unit, configured to define the dependency relationships between the respective functional modules to form a plurality of logical layers of the scaffolding, and obtain the scaffolding, where the plurality of logical layers include: a basic layer, a domain layer, an application layer, and a user interface layer.

[0013] Third aspect, an embodiment of the present application further provides an application development method based on domain-driven design, and the method includes:

[0014] Invoking a pre-set scaffolding based on domain-driven design, where the scaffolding is built by using a scaffolding building method based on domain-driven design and stored in a code repository;

[0015] Obtaining domain business logic rules;

[0016] Integrating the domain business logic rules into the scaffolding to obtain a target application.

[0017] Fourth aspect, an embodiment of the present application further provides an application development device based on domain-driven design, and the device includes:

[0018] An invocation unit, configured to invoke a pre-set scaffolding based on domain-driven design, where the scaffolding is built by using a scaffolding building method based on domain-driven design and stored in a code repository;

[0019] An obtaining unit, configured to obtain domain business logic rules;

[0020] A generating unit, configured to integrate the domain business logic rules into the scaffolding to obtain a target application.

[0021] Fifth aspect, an embodiment of the present application further provides an electronic device, including: a processor; and a memory arranged to store computer-executable instructions, and the executable instructions, when executed, cause the processor to execute any of the above methods.

[0022] Sixth aspect, an embodiment of the present application further provides a computer-readable storage medium, where the computer-readable storage medium stores one or more programs, and when the one or more programs are executed by an electronic device including a plurality of application programs, the electronic device is caused to execute any of the above methods.

[0023] The above at least one technical solution adopted in the embodiments of the present application can achieve the following beneficial effects:

[0024] Based on the methodology of domain-driven design, this application constructs multiple groups of functional modules that make up the scaffold, and defines the dependencies between each functional module, thus forming multiple logical layers of the scaffold, including: the basic layer, the domain layer, the application layer, and the user interface layer, obtaining a scaffold based on domain-driven design DDD. This application realizes the rapid construction of a scaffold based on domain-driven design, unifies the engineering construction specifications, enabling developers who want to use domain-driven design to be able to use it out of the box; and developers only need to focus on the implementation of their own business logic, without having to pay attention to the design of the application architecture, significantly reducing the time for building the application framework, improving the efficiency of application development, and reducing the human and time costs of application development. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The drawings described herein are used to provide a further understanding of the present application and form a part of the present application. The schematic embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation of the present application. In the drawings:

[0026] Figure 1 shows a schematic structural diagram of a four-layer architecture proposed in "Domain-Driven Design" according to the prior art;

[0027] Figure 2 shows a schematic flowchart of a method for building a scaffold based on domain-driven design according to an embodiment of the present application;

[0028] Figure 3 shows a schematic structural diagram of a scaffold based on domain-driven design according to some embodiments of the present application;

[0029] Figure 4 shows a building device for a scaffold based on domain-driven design according to an embodiment of the present application;

[0030] Figure 5 shows a flowchart of a method for application development based on domain-driven design according to an embodiment of the present application;

[0031] Figure 6 shows a schematic structural diagram of an application development device based on domain-driven design according to an embodiment of the present application;

[0032] Figure 7 is a schematic structural diagram of an electronic device in an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0033] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments of this application and the corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in this application without creative efforts belong to the scope of protection of this application.

[0034] The following will detail the technical solutions provided by each embodiment of this application in conjunction with the drawings.

[0035] In the prior art, "Domain-Driven Design" only provides the design methodology of the architecture without a specific implementation architecture design. When developers use DDD, they need to implement their own architecture scaffolding by themselves. For this reason, this application is specifically proposed. Developers only need to focus on the implementation of their own business logic and do not need to pay attention to the design of the application architecture, which significantly reduces the time for building the application framework and improves the efficiency of application development; and it unifies the engineering construction specifications.

[0036] Figure 1 The structural schematic diagram of the four-layer architecture proposed according to "Domain-Driven Design" in the prior art is shown. From Figure 1 It can be seen that the four-layer architecture proposed by "Domain-Driven Design" includes, from bottom to top: the basic layer, the domain layer, the application layer, and the user interface layer. However, "Domain-Driven Design" only proposes the Figure 1 shown architecture and does not give how to specifically implement the construction scaffolding nor a unified engineering construction specification.

[0037] Figure 2 The flowchart of the method for building a scaffolding based on domain-driven design according to an embodiment of this application is shown. From Figure 2 It can be seen that this application at least includes steps S210 to S220:

[0038] Step S210: Construct multiple domain-driven design-based functional modules that make up the scaffolding.

[0039] To quickly build a scaffolding based on domain-driven design DDD, this application constructs multiple domain-driven design-based functional modules that make up the scaffolding. That is to say, this application modularizes each function to form multiple componentized functional modules.

[0040] These functional modules are all based on the methodology of domain-driven design and have unified engineering construction specifications, such as writing specifications and interface specifications, etc.

[0041] In some embodiments of the present application, these functional modules include but are not limited to the bpay-common-utils module, cbpay-common-share module, bpay-common-db module, cbpay-common-cache module, cbpay-common-config module, cbpay-common-file module, cbpay-common-mq module, cbpay-common-rpc module, cbpay-common-domain module, cbpay-common-application module, cbpay-common-facade module, cbpay-common-access module, cbpay-common-web module, cbpay-common-test module, and cbpay-common-runner module.

[0042] It should be noted that not every one of the above modules is necessary. For example, the cbpay-common-cache module adds a caching function to improve the performance of the system, and it can be added or removed according to needs.

[0043] It should also be noted that each functional module is independent and decoupled.

[0044] Step S220: Define the dependency relationships before each functional module to form multiple logical layers of the scaffold, and obtain the scaffold. The multiple logical layers include: a basic layer, a domain layer, an application layer, and a user interface layer.

[0045] In the process of forming the scaffold, each module needs to cooperate with each other and has certain dependency relationships. Therefore, the scaffold can be formed by defining these dependency relationships, which can be understood as forming multiple logical layers of the scaffold. These logical layers include but are not limited to a basic layer, a domain layer, an application layer, and a user interface layer. Since there are dependency relationships between the functional modules, the relationships between the logical layers are naturally formed.

[0046] Among them, the basic layer can be used for but not limited to providing basic tools and interacting with external third parties; the domain layer can be used for but not limited to implementing core business logics; the application layer can be used for but not limited to coordinating and aggregating multiple services and implementing the orchestration and combination of domain objects; the user interface layer can be used for but not limited to providing user interfaces to implement the external call of the scaffold.

[0047] In an actual scenario, a scaffolding can be generated through the maven command, mvn archetype:create-from-project. After the scaffolding is built, it can be stored in a code repository for calling when needed.

[0048] From Figure 2 As can be seen from the method shown, this application is based on the methodology of domain-driven design, constructs multiple groups of functional modules that make up the scaffolding, and defines the dependencies between each functional module, thereby forming multiple logical layers of the scaffolding, including: a basic layer, a domain layer, an application layer, and a user interface layer, obtaining a scaffolding based on domain-driven design DDD. This application realizes the rapid construction of a scaffolding based on domain-driven design, unifies the engineering construction specifications, enabling developers who want to use domain-driven design to be able to use it out of the box; and developers only need to focus on the implementation of their own business logic without having to pay attention to the design of the application architecture, significantly reducing the time for building the application framework, improving the efficiency of application development, and reducing the human and time costs of application development.

[0049] In some embodiments of this application, in the above method, the step of defining the dependencies between each functional module to form multiple logical layers of the scaffolding and obtaining the scaffolding includes: dividing multiple functional modules into multiple groups, defining that there are no dependencies between each functional module within each group; defining the dependencies between each group and / or between the functional modules of each group to form multiple logical layers of the scaffolding.

[0050] To facilitate the definition of the dependencies between each functional module, multiple functional modules can be divided into multiple groups. Usually, there are no dependencies between each functional module within each group, and then the dependencies between the functional modules of each group can be defined. When specifically defining, the dependencies between each group can be directly defined, that is, the dependencies between a group of functional modules and other groups of functional modules, or the dependencies between a certain or some functional modules in one group and a certain or some functional modules in other groups can be defined.

[0051] In some embodiments of the present application, in the above method, a plurality of functional modules are divided into a basic tool group, an infrastructure group, a domain group, an application group, an interface group, a startup group, and a test group; wherein, the basic tool group includes: bpay-common-utils module, cbpay-common-share module; the infrastructure group includes: bpay-common-db module, cbpay-common-cache module, cbpay-common-config module, cbpay-common-file module, cbpay-common-mq module, cbpay-common-rpc module; the domain group includes: cbpay-common-domain module; the application group includes: cbpay-common-application module; the interface group includes: cbpay-common-access module, cbpay-common-web module; the startup group includes: cbpay-common-runner module, cbpay-common-facade module; the test group includes: cbpay-common-test module.

[0052] Among them, the cbpay-common-utils module and the cbpay-common-share module can be comprehensively understood as the share&util module, which is mainly used to store basic tools such as date, json, monitoring, exception, errorCode, etc.

[0053] The cbpay-common-db module, cbpay-common-cache module, cbpay-common-config module, cbpay-common-file module, cbpay-common-mq module, and cbpay-common-rpc module are some infrastructures, which can mainly be responsible for exchanging with external third parties, including external services, databases, files, cache centers, configuration centers, and message centers.

[0054] The cbpay-common-domain module can implement core business logics.

[0055] The cbpay-common-application module is responsible for coordinating with multiple aggregation services and domain objects to complete service orchestration and combination, and collaborating to complete business operations.

[0056] The module can provide its own remote service interface, and the cbpay-common-web module can provide RESTFUL-style interfaces.

[0057] The cbpay-common-access module is the interface implementation of the module; the cbpay-common-runner module is the service startup module.

[0058] The cbpay-common-test module is the unified test module.

[0059] Based on the above grouping, define the dependencies between each functional module, including: define that the cbpay-common-domain module of the domain group depends on each functional module in the basic tool group and the infrastructure group; the cbpay-common-application module of the application group depends on the cbpay-common-domain module of the domain group; each functional module of the interface group depends on the cbpay-common-application module of the application group; the cbpay-common-access module of the interface group also depends on the cbpay-common-facade module of the startup group; the cbpay-common-runner module of the startup group depends on each functional module of the interface group; the cbpay-common-test module of the test group depends on the cbpay-common-runner module of the startup group.

[0060] Figure 3 Shows a schematic structural diagram of a scaffolding based on domain-driven design according to some embodiments of the present application, Figure 3 showing a scaffolding based on domain-driven design obtained by the above grouping and dependency definition method. From Figure 3 it can be seen that Figure 3 the scaffolding based on domain-driven design shown includes: a basic layer, a domain layer, an application layer, and a user interface layer. The relationships between each logical layer are described below from bottom to top. However, during the process of defining dependencies, it can be from bottom to top or from top to bottom. In this regard, the present application makes no limitation.

[0061] Among them, the basic layer includes a basic tool group and an infrastructure group. Among them, the basic tool group includes: the bpay-common-utils module and the cbpay-common-share module; the infrastructure group includes: the bpay-common-db module, the cbpay-common-cache module, the cbpay-common-config module, the cbpay-common-file module, the cbpay-common-mq module, and the cbpay-common-rpc module.

[0062] The domain layer includes a domain group, specifically including the cbpay-common-domain module. The domain layer depends on the basic layer, that is, the cbpay-common-domain module in the domain layer depends on each functional module in the basic tool group and the infrastructure group.

[0063] The application group includes an application group, specifically including the cbpay-common-application module. The application group depends on the domain layer, and the cbpay-common-application module in the application group depends on the domain layer, specifically depending on the cbpay-common-domain module in the domain group.

[0064] The user interface layer includes an interface group, a startup group, and a test group. Among them, the cbpay-common-access module and the cbpay-common-web module in the interface group respectively depend on the cbpay-common-application module in the application group.

[0065] In addition, the cbpay-common-access module in the interface group also depends on the cbpay-common-facade module in the startup group. The cbpay-common-access module is the interface implementation of the module.

[0066] The cbpay-common-runner module in the startup group respectively depends on the cbpay-common-access module and the cbpay-common-web module in the interface group.

[0067] The cbpay-common-test module in the test group depends on the cbpay-common-runner module in the startup group.

[0068] If a group includes multiple functional modules and there is no dependency relationship between the functional modules, there is no need to define them; of course, in some other embodiments, there may also be a dependency relationship between the functional modules within a group, and this application does not make any limitation in this regard.

[0069] It should be noted that the grouping of multiple functional modules and the definition method of the dependency relationship are not limited to the embodiments shown above. Any reasonable division and establishment of the dependency relationship are acceptable, and this application does not make any limitation.

[0070] Figure 4 Shows a scaffolding building device based on domain-driven design according to an embodiment of the present application. Starting from Figure 4 As can be seen, the scaffolding building device 400 based on domain-driven design includes:

[0071] A module construction unit 410, configured to construct multiple functional modules based on domain-driven design that make up the scaffolding;

[0072] A relationship definition unit 420, configured to define the dependency relationship between each functional module, form multiple logical layers of the scaffolding, and obtain the scaffolding. The multiple logical layers include: a basic layer, a domain layer, an application layer, and a user interface layer.

[0073] In some embodiments of the present application, in the above device, the module construction unit 410 is configured to construct multiple functional modules based on the methodology of domain-driven design. The multiple functional modules include: bpay-common-utils module, cbpay-common-share module, bpay-common-db module, cbpay-common-cache module, cbpay-common-config module, cbpay-common-file module, cbpay-common-mq module, cbpay-common-rpc module, cbpay-common-domain module, cbpay-common-application module, cbpay-common-facade module, cbpay-common-access module, cbpay-common-web module, cbpay-common-test module, and cbpay-common-runner module.

[0074] In some embodiments of the present application, in the above device, the relationship definition unit 420 is configured to divide multiple functional modules into multiple groups, define that there is no dependency relationship between the functional modules within each group; define the dependency relationship between each group and / or between the functional modules of each group to form multiple logical layers of the scaffolding.

[0075] In some embodiments of the present application, in the above-mentioned device, the relationship definition unit 420 is configured to divide multiple functional modules into a basic tool group, an infrastructure group, a domain group, an application group, an interface group, a startup group, and a test group; wherein, the basic tool group includes: the bpay-common-utils module and the cbpay-common-share module; the infrastructure group includes: the bpay-common-db module, the cbpay-common-cache module, the cbpay-common-config module, the cbpay-common-file module, the cbpay-common-mq module, and the cbpay-common-rpc module; the domain group includes: the cbpay-common-domain module; the application group includes: the cbpay-common-application module; the interface group includes: the cbpay-common-access module and the cbpay-common-web module; the startup group includes: the cbpay-common-runner module and the cbpay-common-facade module; the test group includes: the cbpay-common-test module.

[0076] In some embodiments of the present application, in the above-mentioned device, the relationship definition unit 420 is configured to define that the cbpay-common-domain module in the domain group depends on each functional module in the basic tool group and the infrastructure group; the cbpay-common-application module in the application group depends on the cbpay-common-domain module in the domain group; each functional module in the interface group depends on the cbpay-common-application module in the application group; the cbpay-common-access module in the interface group also depends on the cbpay-common-facade module in the startup group; the cbpay-common-runner module in the startup group depends on each functional module in the interface group; the cbpay-common-test module in the test group depends on the cbpay-common-runner module in the startup group.

[0077] It should be noted that the above-mentioned construction device for the domain-driven design scaffolding can implement the foregoing construction method for the domain-driven design scaffolding one by one, which will not be elaborated here.

[0078] Figure 5 shows a flowchart of an application development method based on domain-driven design according to an embodiment of the present application, starting fromFigure 5 It can be seen that this embodiment includes steps S510 to S530:

[0079] Step S510: calling a preset domain-driven design-based scaffold, wherein the scaffold is built using the domain-driven design-based scaffold building method of the present application and is stored in a code repository.

[0080] Step S520: Acquire domain business logic rules.

[0081] Step S530: Integrate the domain business logic rules into the scaffolding to obtain a target application.

[0082] In the process of developing applications based on domain-driven design, developers can directly call the scaffolding based on domain-driven design built by any of the above methods from the code repository. The scaffolding has a unified engineering construction specification. After obtaining the domain business logic rules edited by the developer, it is integrated into the scaffolding according to the specified format to obtain the target application.

[0083] This application has built a set of scaffolding based on domain-driven design and with unified engineering construction specifications, so that developers who want to use domain-driven design can use it out of the box, so that developers only need to focus on the implementation of their own business logic without having to pay attention to the design of the application architecture, which significantly reduces the time to build the application framework, improves the efficiency of application development, and reduces the manpower and time costs of application development.

[0084] Figure 6 A schematic diagram of the structure of an application development device based on domain-driven design according to an embodiment of the present application is shown. Figure 6 It can be seen that the application development device 600 based on domain-driven design includes:

[0085] A calling unit 610 is used to call a preset scaffold based on domain-driven design, wherein the scaffold is built using a method for building a scaffold based on domain-driven design and is stored in a code repository;

[0086] An acquisition unit 620 is used to acquire domain business logic rules;

[0087] The generating unit 630 is used to integrate the domain business logic rules into the scaffolding to obtain a target application.

[0088] It should be noted that the above-mentioned application development device based on domain-driven design can implement the above-mentioned application development method based on domain-driven design one by one, which will not be repeated here.

[0089] Figure 7It is a schematic structural diagram of an electronic device according to an embodiment of the present application. Please refer to Figure 7 , at the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and a memory. Among them, the memory may include a memory, such as a high-speed random access memory (Random-Access Memory, RAM), and may also include a non-volatile memory, such as at least one disk memory, etc. Of course, the electronic device may also include other hardware required for other services.

[0090] The processor, network interface, and memory can be interconnected through an internal bus, and the internal bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of representation, Figure 7 only a bidirectional arrow is used in

[0091] but it does not mean that there is only one bus or one type of bus.

[0092] The memory is used to store programs. Specifically, the program may include program code, and the program code includes computer operation instructions. The memory can include a memory and a non-volatile memory, and provide instructions and data to the processor.

[0093] The above is as in the present application Figure 4The method executed by the scaffolding construction based on domain-driven design / the application development device based on domain-driven design disclosed in the embodiment shown in or 6 can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, the steps of the above method can be completed by the integrated logic circuit in the hardware of the processor or instructions in software form. The above-mentioned processor may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. It can implement or execute the various methods, steps and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. The steps of the method disclosed in combination with the embodiments of the present application can be directly embodied as being executed and completed by the hardware decoding processor, or executed and completed by a combination of the hardware and software modules in the decoding processor. The software module may be located in a mature storage medium in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory, and the processor reads the information in the memory and combines its hardware to complete the steps of the above method.

[0094] The electronic device can also execute Figure 4 the method executed by the scaffolding construction based on domain-driven design / the application development device based on domain-driven design in or 6, and implement the scaffolding construction based on domain-driven design / the application development device based on domain-driven design in Figure 4 the functions of the embodiment shown in or 6. The embodiments of the present application will not be elaborated herein.

[0095] The embodiments of the present application also propose a computer-readable storage medium. The computer-readable storage medium stores one or more programs. The one or more programs include instructions that, when executed by an electronic device including multiple application programs, can enable the electronic device to execute Figure 4 the method executed by the scaffolding construction based on domain-driven design / the application development device based on domain-driven design in the embodiment shown in or 6, and is specifically used to execute the foregoing method.

[0096] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memory, CD-ROM, optical memory, etc.) that contain computer-usable program code.

[0097] The present application is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to the embodiments of the present application. It should be understood that each flow and / or block in the flowchart and / or block diagram, as well as the combination of flows and / or blocks in the flowchart and / or block diagram, can be realized by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing devices generate means for realizing the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0098] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, such that the instructions stored in the computer-readable memory generate a manufactured article including instruction means that realize the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0099] These computer program instructions can also be loaded onto a computer or other programmable data processing device, such that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process, and thus the instructions executed on the computer or other programmable device provide steps for realizing the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0100] In a typical configuration, a computing device includes one or more processors (CPUs), an input / output interface, a network interface, and a memory.

[0101] The memory may include non-permanent memory in the computer-readable medium, in the form of random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). The memory is an example of a computer-readable medium.

[0102] A computer-readable medium includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium that can store information accessible by a computing device. As defined herein, a computer-readable medium does not include transitory computer-readable media such as modulated data signals and carrier waves.

[0103] It should also be noted that the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, such that a process, method, article or apparatus comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article or apparatus. Without further limitation, an element defined by the statement "comprising an..." does not exclude the presence of additional identical elements in the process, method, article or apparatus comprising the element.

[0104] Those skilled in the art will appreciate that the embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0105] The above description is only for the embodiments of the present application and is not intended to limit the present application. For those skilled in the art, various changes and modifications can be made to the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included within the scope of the claims of the present application.

Claims

1. A method for building a scaffolding based on domain-driven design, characterized in that, The method includes: Constructing a plurality of functional modules based on domain-driven design that make up the scaffold; Dividing the plurality of functional modules into a basic tool group, an infrastructure group, a domain group, an application group, an interface group, a startup group, and a test group; Among them, the basic tool group includes: bpay-common-utils module, cbpay-common-share module; the infrastructure group includes: bpay-common-db module, cbpay-common-cache module, cbpay-common-config module, cbpay-common-file module, cbpay-common-mq module, cbpay-common-rpc module; the domain group includes: cbpay-common-domain module; the application group includes: cbpay-common-application module; the interface group includes: cbpay-common-access module, cbpay-common-web module; the startup group includes: cbpay-common-runner module, cbpay-common-facade module; the test group includes: cbpay-common-test module; Defining the dependencies between the respective functional modules to form multiple logical layers of the scaffold, obtaining the scaffold, and the multiple logical layers include: a basic layer, a domain layer, an application layer, and a user interface layer; Among them, the defining the dependencies between the respective functional modules to form multiple logical layers of the scaffold, obtaining the scaffold, includes: Defining that the cbpay-common-domain module of the domain group depends on the functional modules in the basic tool group and the infrastructure group; The cbpay-common-application module of the application group depends on the cbpay-common-domain module of the domain group; The functional modules of the interface group depend on the cbpay-common-application module of the application group; the cbpay-common-access module of the interface group also depends on the cbpay-common-facade module of the startup group; The cbpay-common-runner module of the startup group depends on the functional modules of the interface group; The cbpay-common-test module of the test group depends on the cbpay-common-runner module of the startup group.

2. The method according to claim 1, characterized in that The defining the dependencies between the respective functional modules to form multiple logical layers of the scaffold, obtaining the scaffold, includes: Dividing the plurality of functional modules into multiple groups and defining that there are no dependencies between the functional modules within each group; Defining the dependencies between the groups and / or between the functional modules of each group to form multiple logical layers of the scaffold.

3. An application development method based on domain-driven design, characterized in that, The method includes: Invoke a pre-set scaffolding based on domain-driven design, where the scaffolding is built using the scaffolding building method described in any one of claims 1 to 2 and stored in a code repository; Obtain domain business logic rules; Integrate the domain business logic rules into the scaffolding to obtain a target application.

4. A scaffolding device based on domain-driven design, characterized in that The device includes: A module construction unit for constructing a plurality of function modules based on domain-driven design that make up the scaffolding; A relationship definition unit for dividing the plurality of function modules into a basic tool group, an infrastructure group, a domain group, an application group, an interface group, a startup group, and a test group; where the basic tool group includes: bpay-common-utils module, cbpay-common-share module; the infrastructure group includes: bpay-common-db module, cbpay-common-cache module, cbpay-common-config module, cbpay-common-file module, cbpay-common-mq module, cbpay-common-rpc module; the domain group includes: cbpay-common-domain module; the application group includes: cbpay-common-application module; the interface group includes: cbpay-common-access module, cbpay-common-web module; the startup group includes: cbpay-common-runner module, cbpay-common-facade module; the test group includes: cbpay-common-test module; A relationship definition unit for defining the dependency relationships between the respective function modules to form a plurality of logical layers of the scaffolding, obtaining the scaffolding, and the plurality of logical layers include: a basic layer, a domain layer, an application layer, and a user interface layer; A relationship definition unit for defining that the cbpay-common-domain module of the domain group depends on the function modules in the basic tool group and the infrastructure group; the cbpay-common-application module of the application group depends on the cbpay-common-domain module of the domain group; the function modules of the interface group depend on the cbpay-common-application module of the application group; the cbpay-common-access module of the interface group also depends on the cbpay-common-facade module of the startup group; the cbpay-common-runner module of the startup group depends on the function modules of the interface group; the cbpay-common-test module of the test group depends on the cbpay-common-runner module of the startup group.

5. An application development device based on domain-driven design, characterized in that, The device includes: A calling unit, configured to call a pre-set domain-driven design-based scaffolding, wherein the scaffolding is built by using the method described in any one of claims 1 to 2 and stored in a code repository; An obtaining unit, configured to obtain domain business logic rules; A generating unit, configured to integrate the domain business logic rules into the scaffolding to obtain a target application.

6. An electronic device, comprising: A processor; And A memory arranged to store computer-executable instructions that, when executed, cause the processor to execute the method described in any one of claims 1 to 3.

7. A computer-readable storage medium storing one or more programs that, when executed by an electronic device including a plurality of application programs, cause the electronic device to execute the method described in any one of claims 1 to 3.

Images