CN115016769A - 基于领域驱动设计的脚手架的搭建方法以及应用开发方法 - Google Patents
基于领域驱动设计的脚手架的搭建方法以及应用开发方法 Download PDFInfo
- Publication number
- CN115016769A CN115016769A CN202210734677.2A CN202210734677A CN115016769A CN 115016769 A CN115016769 A CN 115016769A CN 202210734677 A CN202210734677 A CN 202210734677A CN 115016769 A CN115016769 A CN 115016769A
- Authority
- CN
- China
- Prior art keywords
- module
- common
- scaffold
- group
- domain
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/20—Software design
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/35—Creation or generation of source code model driven
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本申请公开了一种基于领域驱动设计的脚手架的搭建方法以及应用开发方法,其搭建方法包括:构建组成所述脚手架的基于领域驱动设计的多组功能模块;定义各个功能模块之间的依赖关系,形成所述脚手架的多个逻辑层,得到所述脚手架,所述多个逻辑层包括:基础层、领域层、应用层以及用户接口层。本申请实现了基于领域驱动设计的脚手架的快速搭建,统一了工程构建规范,使得想用领域驱动设计的开发人员能够开箱即用;且开发人员只需关注自身的业务逻辑的实现,无需关注对应用架构的设计,显著降低了应用框架的搭建时间,提高了应用开发的效率,降低了应用开发的人力和时间成本。
Description
技术领域
本申请涉及计算机技术领域,具体涉及一种基于领域驱动设计的脚手架的搭建方法以及应用开发方法。
背景技术
随着业务的复杂度加深,以及对应用的高可用、高并发、高性能的三高要求,对应的应用系统架构也经历了从单机、集中式到分布式微服务架构的演进。随着分布式技术的兴起,应用系统进入了微服务的架构时代。
为了解决微服务设计过程中面临的边界划定,以及分离技术实现复杂的问题,2004年埃里克.埃文斯(Eric Evans)发表了《领域驱动设计》(Domain-Driven Design-Tackling Complexity in the Heart of software)这本书,提出了领域驱动设计(DomainDriven Design简称DDD)。
但是,书中只是提供了架构的设计方法论,没有具体的落地架构设计,外部公司在使用DDD时,需要各自实现自己的架构脚手架。是实际使用中存在着没有具体的落地构建脚手架,也没有统一工程构建规范的问题,且不能快速的构建脚手架,开发人员不单关注自身业务逻辑,也要从零开始搭建基于DDD设计的软件架构,严重消耗人力和时间成本。
需要说明的是,上述说明仅作为背景示例,而不必然的成为现有技术。
发明内容
针对上述问题,本申请实施例提供了一种基于领域驱动设计的脚手架的搭建方法以及应用开发方法,实现脚手架的快速搭建以及统一工程构建规范。
第一方面,本申请实施例提供了一种基于领域驱动设计脚手架的搭建方法所述方法包括:
构建组成所述脚手架的基于领域驱动设计的多个功能模块;
定义各个功能模块之间的依赖关系,形成所述脚手架的多个逻辑层,得到所述脚手架,所述多个逻辑层包括:基础层、领域层、应用层以及用户接口层。
第二方面,本申请实施例还提供了一种基于领域驱动设计的脚手架的搭建装置,所述装置包括:
模块构建单元,用于构建组成所述脚手架的基于领域驱动设计的多个功能模块;
关系定义单元,用于定义各个功能模块之间的依赖关系,形成所述脚手架的多个逻辑层,得到所述脚手架,所述多个逻辑层包括:基础层、领域层、应用层以及用户接口层。
第三方面,本申请实施例还提供了一种基于领域驱动设计的应用开发方法,所述方法包括:
调用预置的基于领域驱动设计的脚手架,其中,所述脚手架是采用基于领域驱动设计的脚手架的搭建方法搭建,并存储于代码仓库中的;
获取领域业务逻辑规则;
将所述领域业务逻辑规则融合于所述脚手架中,得到目标应用。
第四方面,本申请实施例还提供了一种基于领域驱动设计的应用开发装置,所述装置包括:
调用单元,用于调用预置的基于领域驱动设计的脚手架,其中,所述脚手架是采用基于领域驱动设计的脚手架的搭建方法搭建,并存储于代码仓库中的;
获取单元,用于获取领域业务逻辑规则;
生成单元,用于将所述领域业务逻辑规则融合于所述脚手架中,得到目标应用。
第五方面,本申请实施例还提供了一种电子设备,包括:处理器;以及被安排成存储计算机可执行指令的存储器,所述可执行指令在被执行时使所述处理器执行上述任一的方法。
第六方面,本申请实施例还提供了一种计算机可读存储介质,所述计算机可读存储介质存储一个或多个程序,所述一个或多个程序当被包括多个应用程序的电子设备执行时,使得所述电子设备执行上述任一的方法。
本申请实施例采用的上述至少一个技术方案能够达到以下有益效果:
本申请基于领域驱动设计的方法论,构建组成所述脚手架的的多组功能模块,并定义各个功能模块之前的依赖关系,从而形成了脚手架的多个逻辑层,包括:基础层、领域层、应用层以及用户接口层,得到了基于领域驱动设计DDD的脚手架。本申请实现了基于领域驱动设计的脚手架的快速搭建,统一了工程构建规范,使得想用领域驱动设计的开发人员能够开箱即用;且开发人员只需关注自身的业务逻辑的实现,无需关注对应用架构的设计,显著降低了应用框架的搭建时间,提高了应用开发的效率,降低了应用开发的人力和时间成本。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1示出了根据现有技术中《领域驱动设计》提出的四层架构的结构示意图;
图2示出了根据本申请的一个实施例的基于领域驱动设计的脚手架的搭建方法的流程示意图;
图3示出了根据本申请的一些实施例的基于领域驱动设计的脚手架的结构示意图;
图4示出了根据本申请的一个实施例的基于领域驱动设计脚手架的搭建装置;
图5示出了根据本申请的一个实施例的基于领域驱动设计的应用开发方法的流程图;
图6示出了根据本申请的一个实施例的基于领域驱动设计的应用开发装置的结构示意图;
图7为本申请实施例中一种电子设备的结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
以下结合附图,详细说明本申请各实施例提供的技术方案。
针对现有技术中,《领域驱动设计》中只是提供了架构的设计方法论,没有具体的落地架构设计,开发人员在使用DDD时,需要自行实现自己的架构脚手架。对此特提出本申请,开发人员只需关注自身的业务逻辑的实现,无需关注对应用架构的设计,显著降低了应用框架的搭建时间,提高了应用开发的效率;且统一了工程构建规范。
图1示出了根据现有技术中《领域驱动设计》提出的四层架构的结构示意图,从图1可以看出,《领域驱动设计》提出的四层架构从下到上依次包括:基础层、领域层、应用层、用户接口层。但是《领域驱动设计》仅提出了图1示出的架构,并没有给出如何具体落地的构建脚手架,也没有统一的工程构建规范。
图2示出了根据本申请的一个实施例的基于领域驱动设计的脚手架的搭建方法的流程示意图,从图2可以看出,本申请至少包括步骤S210~步骤S220:
步骤S210:构建组成所述脚手架的基于领域驱动设计的多个功能模块。
为了实现快速搭建基于领域驱动设计DDD的脚手架,本申请构建了组成所述脚手架的基于领域驱动设计的多个功能模块,也就是说,本申请将各个功能都进行模块化处理,形成了多个组件化的功能模块。
这些功能模块都是基于领域驱动设计的方法论的,具有统一的工程构建规范,如编写规范以及接口规范等。
在本申请的一些实施例中,这些功能模块包括但不限于bpay-common-utils模块、cbpay-common-share模块、bpay-common-db模块、cbpay-common-cache模块、cbpay-common-config模块、cbpay-common-file模块、cbpay-common-mq模块、cbpay-common-rpc模块、cbpay-common-domain模块、cbpay-common-application模块、cbpay-common-facade模块、cbpay-common-access模块、cbpay-common-web模块、cbpay-common-test模块、以及cbpay-common-runner模块。
需要说明的是,上述的模块不是每一个都是必要的,如cbpay-common-cache模块是增加了缓存功能,提高系统的性能,可以根据需要进行增减。
另需要说明的是,各个功能模块是相互独立的,且解耦合的。
步骤S220:定义各个功能模块之前的依赖关系,形成所述脚手架的多个逻辑层,得到所述脚手架,所述多个逻辑层包括:基础层、领域层、应用层以及用户接口层。
在形成脚手架的过程中,各个模块需要配合在一起,具有一定的依赖关系,因此可通过定义这种依赖关系来形成脚手架,可以理解为形成脚手架的多个逻辑层。这些逻辑层包括但不限于基础层、领域层、应用层以及用户接口层。由于各功能模块之间具有了依赖关系,逻辑层之间的关系即自然形成。
其中,所述基础层可用于但不限于提供基础工具以及与外部三方交互;所述领域层可用于但不限于实现核心业务逻辑;所述应用层可用于但不限于协调和聚合多个服务以及实现领域对象的编排和组合;所述用户接口层可用于但不限于提供用户接口,以实现所述脚手架的外部调用。
在实际场景中,可通过maven命令,mvn archetype:create-from-project生成脚手架,当脚手架搭建完毕后,可以存储于代码仓库中,以便使用时调用。
由图2所示的方法可以看出,本申请基于领域驱动设计的方法论,构建组成所述脚手架的的多组功能模块,并定义各个功能模块之前的依赖关系,从而形成了脚手架的多个逻辑层,包括:基础层、领域层、应用层以及用户接口层,得到了基于领域驱动设计DDD的脚手架。本申请实现了基于领域驱动设计的脚手架的快速搭建,统一了工程构建规范,使得想用领域驱动设计的开发人员能够开箱即用;且开发人员只需关注自身的业务逻辑的实现,无需关注对应用架构的设计,显著降低了应用框架的搭建时间,提高了应用开发的效率,降低了应用开发的人力和时间成本。
在本申请的一些实施例中,在上述方法中,所述定义各个功能模块之间的依赖关系,形成所述脚手架的多个逻辑层,得到所述脚手架,包括:将多个功能模块分为多组,定义每组内的各功能模块没有依赖关系;定义各组之间和/或各组的功能模块之间的依赖关系,以形成所述脚手架的多个逻辑层。
为了方便定义各个功能模块之间的依赖关系,可以将多个功能模块分为多组,在每组内的各个功能模块通常是相互没有依赖关系的,在之后可以定义各组功能模块之间的依赖关系。在具体进行定义时,可以直接定义各组之间的依赖关系,即一组功能模块与其他组功能模块之间的依赖关系,也可以定义一组中的某个或者某些功能模块与其他组的某个或者某些功能模块之间的依赖关系。
在本申请的一些实施例中,在上述方法中,将多个功能模块分为基础工具组、基础设施组、域组、应用组、接口组、启动组以及测试组;其中,所述基础工具组包括:bpay-common-utils模块、cbpay-common-share模块;所述基础设施组包括:bpay-common-db模块、cbpay-common-cache模块、cbpay-common-config模块、cbpay-common-file模块、cbpay-common-mq模块、cbpay-common-rpc模块;所述域组包括:cbpay-common-domain模块;所述应用组包括:cbpay-common-application模块;所述接口组包括:cbpay-common-access模块、cbpay-common-web模块;所述启动组包括:cbpay-common-runner模块、cbpay-common-facade模块;所述测试组包括:cbpay-common-test模块。
其中,cbpay-common-utils模块和cbpay-common-share模块可以综合理解为share&util模块,主要用于存放date,json,监控,exception,errorCode等基础工具。
cbpay-common-db模块、cbpay-common-cache模块、cbpay-common-config模块、cbpay-common-file模块、cbpay-common-mq模块、cbpay-common-rpc模块为一些基础设施,主要可以负责和外部三方交换,包括外部服务、数据库、文件、缓存中心、配置中心、消息中心。
cbpay-common-domain模块可以实现核心的业务逻辑。
cbpay-common-application模块负责协调和多个聚合服务和领域对象完成服务编排和组合,协作完成业务操作。
cbpay-common-test模块为统一测试模块。
基于上述的分组情况,定义各个功能模块之间的依赖关系,包括:定义所述域组的cbpay-common-domain模块依赖所述基础工具组以及所述基础设施组中的各功能模块;所述应用组的cbpay-common-application模块依赖所述域组的cbpay-common-domain模块;所述接口组的各功能模块依赖所述应用组的cbpay-common-application模块;所述接口组的cbpay-common-access模块还依赖于所述启动组的cbpay-common-facade模块;所述启动组的cbpay-common-runner模块依赖所述接口组的各功能模块;所述测试组的cbpay-common-test模块依赖所述启动组的cbpay-common-runner模块。
图3示出了根据本申请的一些实施例的基于领域驱动设计的脚手架的结构示意图,图3示出了的是基于上述分组以及依赖关系定义方法得到的基于领域驱动设计的脚手架,从图3可以看出,图3所示的基于领域驱动设计的脚手架包括:基础层、领域层、应用层以及用户接口层,以下自下而上对各个逻辑层之间的关系进行说明,但是在依赖关系定义的过程中,可以是自下而上的,也可以是自上而下的,对此,本申请不作限定。
其中,基础层包括基础工具组和基础设施组,其中,所述基础工具组包括:bpay-common-utils模块、cbpay-common-share模块;所述基础设施组包括:bpay-common-db模块、cbpay-common-cache模块、cbpay-common-config模块、cbpay-common-file模块、cbpay-common-mq模块、cbpay-common-rpc模块。
领域层包括域组,具体包括cbpay-common-domain模块,领域层依赖于基础层,即领域层中的cbpay-common-domain模块依赖于基础工具组和基础设施组中的各个功能模块。
应用组包括应用组,具体包括cbpay-common-application模块,应用组依赖于领域层,领域层的cbpay-common-application模块依赖领域层,具体的依赖域组的cbpay-common-domain模块。
用户接口层包括接口组、启动组以及测试组,其中,接口组的cbpay-common-access模块、cbpay-common-web模块分别依赖应用组的cbpay-common-application模块。
启动组的cbpay-common-runner模块分别依赖接口组的cbpay-common-access模块和cbpay-common-web模块。
测试组的cbpay-common-test模块依赖启动组的cbpay-common-runner模块。
上述如果一组之内包括多个功能模块,各功能模块之间没有依赖关系,无需进行定义;当然了,在另外一些实施例中,一个组之内的功能模块也可以存在依赖关系,对此,本申请不作限定。
需要说明的是,多个功能模块的分组以及依赖关系定义的方式并不局限于上述示出的实施例,凡是合理的划分以及依赖关系的建立均可以,本申请不作限定。
图4示出了根据本申请的一个实施例的基于领域驱动设计脚手架的搭建装置,从图4可以看出,该基于领域驱动设计脚手架的搭建装置400包括:
模块构建单元410,用于构建组成所述脚手架的基于领域驱动设计的多个功能模块;
关系定义单元420,用于定义各个功能模块之间的依赖关系,形成所述脚手架的多个逻辑层,得到所述脚手架,所述多个逻辑层包括:基础层、领域层、应用层以及用户接口层。
在本申请的一些实施例中,在上述装置中,模块构建单元410,用于基于领域驱动设计的方法论,构建多个功能模块,所述多个功能模块包括:bpay-common-utils模块、cbpay-common-share模块、bpay-common-db模块、cbpay-common-cache模块、cbpay-common-config模块、cbpay-common-file模块、cbpay-common-mq模块、cbpay-common-rpc模块、cbpay-common-domain模块、cbpay-common-application模块、cbpay-common-facade模块、cbpay-common-access模块、cbpay-common-web模块、cbpay-common-test模块、以及cbpay-common-runner模块。
在本申请的一些实施例中,在上述装置中,关系定义单元420,用于将多个功能模块分为多组,定义每组内的各功能模块没有依赖关系;定义各组之间和/或各组的功能模块之间的依赖关系,以形成所述脚手架的多个逻辑层。
在本申请的一些实施例中,在上述装置中,关系定义单元420,用于将多个功能模块分为基础工具组、基础设施组、域组、应用组、接口组、启动组以及测试组;其中,所述基础工具组包括:bpay-common-utils模块、cbpay-common-share模块;所述基础设施组包括:bpay-common-db模块、cbpay-common-cache模块、cbpay-common-config模块、cbpay-common-file模块、cbpay-common-mq模块、cbpay-common-rpc模块;所述域组包括:cbpay-common-domain模块;所述应用组包括:cbpay-common-application模块;所述接口组包括:cbpay-common-access模块、cbpay-common-web模块;所述启动组包括:cbpay-common-runner模块、cbpay-common-facade模块;所述测试组包括:cbpay-common-test模块。
在本申请的一些实施例中,在上述装置中,关系定义单元420,用于定义所述域组的cbpay-common-domain模块依赖所述基础工具组以及所述基础设施组中的各功能模块;所述应用组的cbpay-common-application模块依赖所述域组的cbpay-common-domain模块;所述接口组的各功能模块依赖所述应用组的cbpay-common-application模块;所述接口组的cbpay-common-access模块还依赖于所述启动组的cbpay-common-facade模块;所述启动组的cbpay-common-runner模块依赖所述接口组的各功能模块;所述测试组的cbpay-common-test模块依赖所述启动组的cbpay-common-runner模块。
需要说明的是,上述的基于领域驱动设计脚手架的搭建装置可一一实现前述的基于领域驱动设计脚手架的搭建方法,这里不再赘述。
图5示出了根据本申请的一个实施例的基于领域驱动设计的应用开发方法的流程图,从图5可以看出,本实施例包括步骤S510~步骤S530:
步骤S510:调用预置的基于领域驱动设计的脚手架,其中,所述脚手架是采用本申请的基于领域驱动设计的脚手架的搭建方法搭建,并存储于代码仓库中的。
步骤S520:获取领域业务逻辑规则。
步骤S530:将所述领域业务逻辑规则融合于所述脚手架中,得到目标应用。
开发人员在基于领域驱动设计进行应用开发的过程中,可以从代码仓库中,直接调用采用前述任一方法搭建的基于领域驱动设计的脚手架。该脚手架具有统一的工程构建规范,在获取了开发人员编辑的领域业务逻辑规则后,将其按照指定格式融合于所述脚手架中,即可得到目标应用。
本申请搭建了一套基于领域驱动设计、且具有的统一工程构建规范脚手架,使得想用领域驱动设计的开发人员能够开箱即用,使得开发人员只需关注自身的业务逻辑的实现,无需关注对应用架构的设计,显著降低了应用框架的搭建时间,提高了应用开发的效率,降低了应用开发的人力和时间成本。
图6示出了根据本申请的一个实施例的基于领域驱动设计的应用开发装置的结构示意图,从图6可以看出,该基于领域驱动设计的应用开发装置600包括:
调用单元610,用于调用预置的基于领域驱动设计的脚手架,其中,所述脚手架是采用基于领域驱动设计的脚手架的搭建方法搭建,并存储于代码仓库中的;
获取单元620,用于获取领域业务逻辑规则;
生成单元630,用于将所述领域业务逻辑规则融合于所述脚手架中,得到目标应用。
需要说明的是,上述的基于领域驱动设计的应用开发装置可一一实现前述的基于领域驱动设计的应用开发方法,这里不再赘述。
图7是本申请的一个实施例电子设备的结构示意图。请参考图7,在硬件层面,该电子设备包括处理器,可选地还包括内部总线、网络接口、存储器。其中,存储器可能包含内存,例如高速随机存取存储器(Random-Access Memory,RAM),也可能还包括非易失性存储器(non-volatile memory),例如至少1个磁盘存储器等。当然,该电子设备还可能包括其他业务所需要的硬件。
处理器、网络接口和存储器可以通过内部总线相互连接,该内部总线可以是ISA(Industry Standard Architecture,工业标准体系结构)总线、PCI(PeripheralComponent Interconnect,外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture,扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示,图7中仅用一个双向箭头表示,但并不表示仅有一根总线或一种类型的总线。
存储器,用于存放程序。具体地,程序可以包括程序代码,所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器,并向处理器提供指令和数据。
处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行,在逻辑层面上形成基于领域驱动设计脚手架的搭建/基于领域驱动设计的应用开发装置。处理器,执行存储器所存放的程序,并具体用于执行上述方法。
上述如本申请图4或6所示实施例揭示的基于领域驱动设计脚手架的搭建/基于领域驱动设计的应用开发装置执行的方法可以应用于处理器中,或者由处理器实现。处理器可能是一种集成电路芯片,具有信号的处理能力。在实现过程中,上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器,包括中央处理器(Central Processing Unit,CPU)、网络处理器(NetworkProcessor,NP)等;还可以是数字信号处理器(Digital Signal Processor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成,或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器,处理器读取存储器中的信息,结合其硬件完成上述方法的步骤。
该电子设备还可执行图4或6中基于领域驱动设计脚手架的搭建/基于领域驱动设计的应用开发装置执行的方法,并实现基于领域驱动设计脚手架的搭建/基于领域驱动设计的应用开发装置在图4或6所示实施例的功能,本申请实施例在此不再赘述。
本申请实施例还提出了一种计算机可读存储介质,该计算机可读存储介质存储一个或多个程序,该一个或多个程序包括指令,该指令当被包括多个应用程序的电子设备执行时,能够使该电子设备执行图4或6所示实施例中基于领域驱动设计脚手架的搭建/基于领域驱动设计的应用开发装置执行的方法,并具体用于执行前述方法。
本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。
Claims (10)
1.一种基于领域驱动设计的脚手架的搭建方法,其特征在于,所述方法包括:
构建组成所述脚手架的基于领域驱动设计的多个功能模块;
定义各个功能模块之间的依赖关系,形成所述脚手架的多个逻辑层,得到所述脚手架,所述多个逻辑层包括:基础层、领域层、应用层以及用户接口层。
2.根据权利要求1所述的方法,其特征在于,所述构建组成所述脚手架的基于领域驱动设计的多个功能模块,包括:
基于领域驱动设计的方法论,构建多个功能模块,所述多个功能模块包括:bpay-common-utils模块、cbpay-common-share模块、bpay-common-db模块、cbpay-common-cache模块、cbpay-common-config模块、cbpay-common-file模块、cbpay-common-mq模块、cbpay-common-rpc模块、cbpay-common-domain模块、cbpay-common-application模块、cbpay-common-facade模块、cbpay-common-access模块、cbpay-common-web模块、cbpay-common-test模块、以及cbpay-common-runner模块。
3.根据权利要求2所述的方法,其特征在于,所述定义各个功能模块之间的依赖关系,形成所述脚手架的多个逻辑层,得到所述脚手架,包括:
将多个功能模块分为多组,定义每组内的各功能模块没有依赖关系;
定义各组之间和/或各组的功能模块之间的依赖关系,以形成所述脚手架的多个逻辑层。
4.根据权利要求3所述的方法,其特征在于,所述将多个功能模块分为多组,包括:
将多个功能模块分为基础工具组、基础设施组、域组、应用组、接口组、启动组以及测试组;
其中,所述基础工具组包括:bpay-common-utils模块、cbpay-common-share模块;所述基础设施组包括:bpay-common-db模块、cbpay-common-cache模块、cbpay-common-config模块、cbpay-common-file模块、cbpay-common-mq模块、cbpay-common-rpc模块;所述域组包括:cbpay-common-domain模块;所述应用组包括:cbpay-common-application模块;所述接口组包括:cbpay-common-access模块、cbpay-common-web模块;所述启动组包括:cbpay-common-runner模块、cbpay-common-facade模块;所述测试组包括:cbpay-common-test模块。
5.根据权利要求4所述的方法,其特征在于,所述定义各个功能模块之间的依赖关系,形成所述脚手架的多个逻辑层,得到所述脚手架,包括:
定义所述域组的cbpay-common-domain模块依赖所述基础工具组以及所述基础设施组中的各功能模块;
所述应用组的cbpay-common-application模块依赖所述域组的cbpay-common-domain模块;
所述接口组的各功能模块依赖所述应用组的cbpay-common-application模块;所述接口组的cbpay-common-access模块还依赖于所述启动组的cbpay-common-facade模块;
所述启动组的cbpay-common-runner模块依赖所述接口组的各功能模块;
所述测试组的cbpay-common-test模块依赖所述启动组的cbpay-common-runner模块。
6.一种基于领域驱动设计的应用开发方法,其特征在于,所述方法包括:
调用预置的基于领域驱动设计的脚手架,其中,所述脚手架是采用权利要求1~5中任意一项所述的基于领域驱动设计的脚手架的搭建方法搭建,并存储于代码仓库中的;
获取领域业务逻辑规则;
将所述领域业务逻辑规则融合于所述脚手架中,得到目标应用。
7.一种基于领域驱动设计脚手架的搭建装置,其特征在于,所述装置包括:
模块构建单元,用于构建组成所述脚手架的基于领域驱动设计的多个功能模块;
关系定义单元,用于定义各个功能模块之间的依赖关系,形成所述脚手架的多个逻辑层,得到所述脚手架,所述多个逻辑层包括:基础层、领域层、应用层以及用户接口层。
8.一种基于领域驱动设计的应用开发装置,其特征在于,所述装置包括:
调用单元,用于调用预置的基于领域驱动设计的脚手架,其中,所述脚手架是采用权利要求1~5中任意一项所述的方法搭建,并存储于代码仓库中的;
获取单元,用于获取领域业务逻辑规则;
生成单元,用于将所述领域业务逻辑规则融合于所述脚手架中,得到目标应用。
9.一种电子设备,包括:
处理器;以及
被安排成存储计算机可执行指令的存储器,所述可执行指令在被执行时使所述处理器执行所述权利要求1~5或6所述方法。
10.一种计算机可读存储介质,所述计算机可读存储介质存储一个或多个程序,所述一个或多个程序当被包括多个应用程序的电子设备执行时,使得所述电子设备执行所述权利要求1~5或6所述方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210734677.2A CN115016769A (zh) | 2022-06-27 | 2022-06-27 | 基于领域驱动设计的脚手架的搭建方法以及应用开发方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210734677.2A CN115016769A (zh) | 2022-06-27 | 2022-06-27 | 基于领域驱动设计的脚手架的搭建方法以及应用开发方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN115016769A true CN115016769A (zh) | 2022-09-06 |
Family
ID=83076615
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210734677.2A Pending CN115016769A (zh) | 2022-06-27 | 2022-06-27 | 基于领域驱动设计的脚手架的搭建方法以及应用开发方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115016769A (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116679910A (zh) * | 2023-05-23 | 2023-09-01 | 中电金信软件有限公司 | 基于领域驱动设计的工程脚手架生成方法、装置和设备 |
-
2022
- 2022-06-27 CN CN202210734677.2A patent/CN115016769A/zh active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116679910A (zh) * | 2023-05-23 | 2023-09-01 | 中电金信软件有限公司 | 基于领域驱动设计的工程脚手架生成方法、装置和设备 |
CN116679910B (zh) * | 2023-05-23 | 2024-04-05 | 中电金信软件有限公司 | 基于领域驱动设计的工程脚手架生成方法、装置和设备 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN111176802B (zh) | 任务处理方法、装置、电子设备及存储介质 | |
CN107450981B (zh) | 一种区块链共识方法及设备 | |
CN111967849A (zh) | 一种任务处理流程编排方法、装置及电子设备 | |
CN108108239A (zh) | 一种业务功能的提供方法、装置及计算机可读存储介质 | |
CN109032590B (zh) | 一种可视化开发环境的配置方法、装置、终端及存储介质 | |
CN112698822B (zh) | 应用软件开发方法、装置、系统架构及工作方法 | |
US20190392349A1 (en) | Simplified product configuration using table-based rules, rule conflict resolution through voting, and efficient model compilation | |
CN113094028B (zh) | 一种Windows桌面程序开发系统、方法及相关组件 | |
CN113778445A (zh) | 一种跨平台组件生成方法、装置、电子设备及存储介质 | |
CN115016769A (zh) | 基于领域驱动设计的脚手架的搭建方法以及应用开发方法 | |
CN109840074A (zh) | 一种业务生成方法、装置及网络设备 | |
CN114138877A (zh) | 基于微服务架构的主题数据服务实现方法、装置及设备 | |
CN114647548A (zh) | 一种日志生成方法及装置 | |
CN113885886A (zh) | 活动业务的处理方法、设备、系统及存储介质 | |
CN111488144A (zh) | 一种数据处理方法以及设备 | |
CN116629015A (zh) | 数字孪生任务的处理方法、装置、设备及存储介质 | |
CN112800030B (zh) | 一种流程的组件数据管理方法、装置及计算机可读存储介质 | |
CN116069310A (zh) | 一种可视化的业务逻辑无编码开发方法、设备及介质 | |
CN112486461B (zh) | 一种基于springboot框架的信息处理系统 | |
CN114416305A (zh) | 一种机器人引擎实现方法、系统及电子设备 | |
CN114896637A (zh) | 一种数据处理方法、装置、电子设备和存储介质 | |
CN113011984A (zh) | 金融产品的业务数据处理方法及装置 | |
CN114594944A (zh) | 一种应用构建系统以及设备 | |
CN114398226A (zh) | 一种网络资产报告生成方法及装置 | |
CN113741868A (zh) | 业务计算任务处理方法、装置、计算机设备和存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |