CN117289903A - 一种领域驱动的软件设计方法和装置 - Google Patents

Abstract

本发明提供一种领域驱动的软件设计方法和装置，涉及互联网技术领域，所述方法用于设计开发工具，包括：获取目标软件的业务需求数据；将业务需求数据发送至业务建模平台进行建模处理，得到业务流程模型和业务数据模型；基于业务建模平台与后端开发平台的预设映射关系，将业务流程模型和业务数据模型映射至后端开发平台，进行领域驱动设计的转换，得到应用层微服务和领域层微服务；接收后端开发平台形成的表现层、应用层、领域层和基础设施层依的赖关系，完成目标软件的开发，从而不需要在需求、设计乃至开发阶段再完成相应的文档，可直接通过本方法实现从业务需求数据到软件开发的过程，保证需求到开发软件的一致性。

Description

一种领域驱动的软件设计方法和装置

技术领域

本发明涉及互联网技术领域，尤其涉及一种领域驱动的软件设计方法和装置。

背景技术

现有软件开发生命周期过程，需要先由业务分析师采集业务需求形成文档，知识转移到系统分析师进行概要设计和详细设计，最终研发人员根据系统分析师的知识转移，完成代码的开发工作。整个软件开发生命周期内，是通过文档的形式实现从需求、设计到开发的知识转移。

在此过程中，只能通过文档的标准化，及使用文档的下游角色来约束最终交付的产品质量，这里面会存在文档质量不高、人员理解不充分等各种各样的问题。可能会导致需求和最终呈现的产品有较大偏差，质量较差。

发明内容

本发明提供一种领域驱动的软件设计方法和装置，用以解决现有技术中通过文档实现软件开发导致需求与产品偏差较大、质量较差的缺陷。

本发明提供一种领域驱动的软件设计方法，用于设计开发工具，所述方法包括：

获取目标软件的业务需求数据；其中，所述业务需求数据为软件开发的所需数据；

将所述业务需求数据发送至业务建模平台进行建模处理，得到业务流程模型和业务数据模型；

基于业务建模平台与后端开发平台的预设映射关系，将所述业务流程模型和业务数据模型映射至后端开发平台，进行领域驱动设计的转换，得到应用层微服务和领域层微服务；其中，所述领域驱动设计包括具有依赖关系的表现层、应用层、领域层和基础设施层；所述应用层微服务位于应用层，用于协调对领域对象的操作；所述领域层包括领域对象和所述领域层微服务，所述领域层微服务用于处理业务逻辑；

接收后端开发平台形成的所述表现层、应用层、领域层和基础设施层的依赖关系，完成目标软件的开发。

根据本发明提供的一种领域驱动的软件设计方法，所述业务流程模型包括：业务领域、业务阶段、活动、任务和步骤；所述业务数据模型包括：主题域、业务属性、业务实体、业务对象和业务组件；

将所述业务需求数据发送至业务建模平台进行建模处理，得到业务流程模型和业务数据模型，包括：

确定所述业务需求数据的所属业务流程，得到属于业务流程模型的业务领域、业务阶段、活动、任务和步骤；

将所述业务需求数据进行拆分，得到属于业务数据模型的主题域、业务属性、业务实体、业务对象和业务组件。

根据本发明提供的一种领域驱动的软件设计方法，所述业务流程模型的业务领域和活动与所述后端开发平台的应用层具有预设的映射关系，所述业务流程模型的任务和步骤与所述后端开发平台的领域层具有预设的映射关系；

所述业务数据模型的业务属性、业务实体、业务对象和业务组件与所述领域层具有预设的映射关系；

基于业务建模平台与后端开发平台的预设映射关系，将所述业务流程模型和业务数据模型映射至后端开发平台，进行领域驱动设计的转换，得到应用层微服务和领域层微服务，包括：

基于所述业务流程模型的业务领域和活动与应用层的映射关系，将所述业务流程模型的业务领域和活动映射至应用层，得到所述应用层微服务；

基于所述业务流程模型的任务和步骤与所述领域层的映射关系，以及所述业务数据模型的业务属性、业务实体、业务对象和业务组件与所述领域层的映射关系，将所述业务流程模型的任务和步骤以及所述业务数据模型的业务属性、业务实体、业务对象和业务组件映射至领域层，得到所述领域层微服务。

根据本发明提供的一种领域驱动的软件设计方法，基于所述业务流程模型的业务领域和活动与应用层的映射关系，将所述业务流程模型的业务领域和活动映射至应用层，得到所述应用层微服务，包括：

基于所述业务流程模型的业务领域和活动与应用层的映射关系，将所述业务领域映射至应用层，得到所述应用层微服务框架；

将所述活动中抽取联机的执行流程，作为场景服务，映射至应用层，转换为所述应用层微服务的应用服务；

基于所述应用层微服务框架和所述应用层微服务的应用服务，得到所述应用层微服务。

根据本发明提供的一种领域驱动的软件设计方法，所述领域层微服务包括：领域服务和聚合，所述聚合包括实体对象以及值对象；所述实体对象以及值对象均包括属性和行为；

基于所述业务流程模型的任务和步骤与所述领域层的映射关系，以及所述业务数据模型的业务属性、业务实体、业务对象和业务组件与所述领域层的映射关系，将所述业务流程模型的任务和步骤以及所述业务数据模型的业务属性、业务实体、业务对象和业务组件映射至领域层，得到所述领域层微服务，包括：

将所述业务流程模型的任务映射至领域层，转换为所述领域服务；

基于所述业务流程模型的任务和步骤与所述领域层的映射关系，将所述步骤映射至领域层，转换为所述实体对象以及值对象的行为；

基于所述业务数据模型的业务属性、业务实体、业务对象和业务组件与所述领域层的映射关系，将所述业务属性映射至领域层，转换为所述实体对象以及值对象的属性；

将所述业务对象映射至领域层，转换为所述聚合；

将所述业务实体映射至领域层，转换为所述实体对象以及值对象；

将所述业务组件映射至领域层，转换为所述领域层微服务的框架；

基于所述领域层微服务的框架、领域服务、聚合、实体对象、值对象、所述实体对象的属性和行为以及值对象的属性和行为，得到所述领域层微服务。

根据本发明提供的一种领域驱动的软件设计方法，所述表现层依赖于应用层、领域层和基础设施层；

所述应用层依赖于领域层和基础设施层；

所述领域层依赖于基础设施层；

所述依赖关系通过所述表现层、应用层、领域层和基础设施层之间的调用关系约束来保证。

本发明提供了一种领域驱动的软件设计装置，用于设计开发工具，所述装置包括：

业务数据获取模块，用于获取目标软件的业务需求数据；其中，所述业务需求数据为软件开发的所需数据；

业务建模模块，用于将所述业务需求数据发送至业务建模平台进行建模处理，得到业务流程模型和业务数据模型；

领域驱动设计模块，用于基于业务建模平台与后端开发平台的预设映射关系，将所述业务流程模型和业务数据模型映射至后端开发平台，进行领域驱动设计的转换，得到应用层微服务和领域层微服务；其中，所述领域驱动设计包括具有依赖关系的表现层、应用层、领域层和基础设施层；所述应用层微服务位于应用层，用于协调对领域对象的操作；所述领域层包括领域对象和所述领域层微服务，所述领域层微服务用于处理业务逻辑；

开发模块，用于接收后端开发平台形成的所述表现层、应用层、领域层和基础设施层的依赖关系，完成目标软件的开发。

根据本发明提供的一种领域驱动的软件设计装置，所述业务流程模型包括：业务领域、业务阶段、活动、任务和步骤；所述业务数据模型包括：主题域、业务属性、业务实体、业务对象和业务组件；

所述业务建模模块，具体用于：

确定所述业务需求数据的所属业务流程，得到属于业务流程模型的业务领域、业务阶段、活动、任务和步骤；

将所述业务需求数据进行拆分，得到属于业务数据模型的主题域、业务属性、业务实体、业务对象和业务组件。

本发明还提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上述任一种所述领域驱动的软件设计方法的步骤。

本发明还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上述任一种所述领域驱动的软件设计方法的步骤。

本发明还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现如上述任一种所述领域驱动的软件设计方法的步骤。

本发明提供的领域驱动的软件设计方法和装置，通过将业务需求数据发送至业务建模平台进行建模处理，得到业务流程模型和业务数据模型；然后基于业务建模平台与后端开发平台的预设映射关系，将业务流程模型和业务数据模型映射至后端开发平台，进行领域驱动设计的转换，得到应用层微服务和领域层微服务；然后接收后端开发平台形成的表现层、应用层、领域层和基础设施层的依赖关系，完成目标软件的开发，从而实现将业务建模与领域驱动设计的不同方法论的理论打通，不需要在需求、设计乃至开发阶段再完成相应的文档，可直接通过本方法业务建模平台与后端开发平台的预设映射关系，实现自动从业务需求数据到软件开发的过程，保证需求到开发软件的一致性，避免通过文档实现软件开发导致需求与产品偏差较大、质量较差的缺陷，从而提高产品的可靠性。

其次，通过基于业务需求数据的所属业务流程，得到属于业务流程模型的业务领域、业务阶段、活动、任务和步骤，将业务需求数据进行拆分，得到属于业务数据模型的主题域、业务属性、业务实体、业务对象和业务组件，从而可以基于业务需求数据得到拆分后的业务领域、业务阶段、活动、任务和步骤，以及主题域、业务属性、业务实体、业务对象和业务组件，从而为后续步骤中从业务数据模型以及业务流程模型到领域驱动设计之间的映射提供基础。

再次，基于预设的映射关系，将业务流程模型的业务领域和活动映射至应用层，得到应用层微服务，将业务流程模型的任务和步骤以及业务数据模型的业务属性、业务实体、业务对象和业务组件映射至领域层，得到领域层微服务，从而实现从业务模型到领域驱动设计之间的转换。

具体地，将业务领域映射至应用层，得到应用层微服务框架；将活动中抽取联机的执行流程，作为场景服务映射至应用层，转换为应用层微服务的应用服务；基于应用层微服务框架和应用层微服务的应用服务，得到应用层微服务，从而实现基于业务流程模型以及预设的映射关系生成应用层微服务。

另外，将业务流程模型的任务和步骤以及业务数据模型的业务属性、业务实体、业务对象和业务组件分别映射至领域层，得到领域层微服务的框架、领域服务、聚合、实体对象、值对象、所述实体对象的属性和行为以及值对象的属性和行为，以确定领域层微服务，从而实现基于业务流程模型以及业务数据模型以及预设的映射关系得到领域层微服务。

附图说明

为了更清楚地说明本发明或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明提供的用于领域驱动的软件设计的系统架构图；

图2是本发明提供的领域驱动的软件设计方法的流程示意图之一；

图3是本发明提供的领域驱动设计的框架示意图；

图4是本发明提供的领域驱动的软件设计方法的流程示意图之二；

图5是本发明提供的从业务模型到领域驱动设计之间的转换的示意图；

图6是本发明提供的领域驱动的软件设计方法的流程示意图之三；

图7是本发明提供的领域驱动的软件设计方法的流程示意图之四；

图8是本发明提供的领域驱动的软件设计装置的结构示意图；

图9是本发明提供的电子设备的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合本发明中的附图，对本发明中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

下面结合图1-图9描述本发明的领域驱动的软件设计方法及装置、电子设备、存储介质和计算机程序产品。

本发明实施例公开了一种领域驱动的软件设计方法，用于设计开发工具，参见图1。图1示出了本实施例中设计开发工具与业务建模平台和后端开发平台的关系示意图。设计开发工具分别与存储设备、业务建模平台和后端开发平台连接，用于接收存储设备的业务需求数据，并发送至业务建模平台；然后基于业务建模平台与后端开发平台的预设映射关系，将业务流程模型和业务数据模型映射至后端开发平台。

参见图2，所述方法包括：

201、获取目标软件的业务需求数据。

本实施例中，业务需求数据为软件开发的所需数据，可以为数据资产，用于作为生成目标软件的基础。

数据资产是指由个人或企业拥有或者控制的，能够为企业带来未来经济利益的，以物理或电子的方式记录的数据资源。

其中，获取的方式可以为多种，例如接收设计人员的输入、在云端下载、或者在存储设备中获取等等。

进一步地，数据资产可以为企业订单数据、用户画像数据、财务数据等。数据资产可以根据所属业务流程的不同，划分不同的类别。

在获取数据资产后，设计开发工具可以依照类别的不同，将数据资产分批次发送至业务建模平台，从而可以使业务建模平台根据不同类别的数据资产进行建模处理，得到不同业务的业务流程模型和业务数据模型。对于当前业务无需使用的数据资产，可无需发送至业务建模平台，以避免将所有数据同时发送至业务建模平台，由于并行任务过多而导致业务建模平台在数据压力下造成宕机的后果。

例如，以业务1和业务2为例，业务1对应包括类别1、类别2和类别3的数据资产，业务2对应包括类别4、类别5和类别6的数据资产。设计开发工具在接收到类别1～类别6的数据资产后，可以先将类别1、类别2和类别3的数据资产发送至业务建模平台，以使业务建模平台进行建模处理，得到业务1的业务流程模型和业务数据模型；然后再将类别4、类别5和类别6的数据资产发送至业务建模平台，以使业务建模平台进行建模处理，得到业务2的业务流程模型和业务数据模型。

202、将所述业务需求数据发送至业务建模平台进行建模处理，得到业务流程模型和业务数据模型。

本实施例中，业务建模平台可以为业务流程建模(Business Process Modeling，BPM)是业务流程管理的核心方法和工具。业务流程建模包括了流程节点建模、流程内容建模、流程权限建模等三个方面的内容。

本实施例的建模，以五级建模为例，可以包括：业务流程模型和业务数据模型。

业务流程模型是从最初的业务链开始，逐步的分解到很细致的、局部的流程模型，因此需要分级，包括业务领域、业务阶段、活动、任务和步骤五个级别。

业务领域：顾名思义，为业务需求数据所属的具体领域，如投资领域、保险领域等等。

业务阶段：以理财业务领域为例，按生命周期来看，还需要分为投前、投中、投后三个阶段。再往下就是各阶段中能够确定的、能够工作的流程即活动。

活动：一个组织或部门为了处理一个事件，而执行的一个协同工作的过程，一般是需要多角色协同完成不同的任务。

任务：级别比活动更低，为某个角色(包括系统)处理某个任务时内部的处理流程，如柜员存款就是一个任务。

步骤：执行任务的流程即是步骤。例如柜员存款任务，需要执行检查是否开户、账户是否列入黑名单、查询账户信息、输入存款金额、提交数据等流程，每个流程为一个步骤。

只有业务流程是不够的，业务需求最终处理的是业务数据，因此必须要有业务数据模型的存在，业务需求的描述才是完整的。业务数据模型按照主题划分成不同的域，如产品、客户、渠道等等，就形成了主题域。比主题域更低一级的是业务对象(很容易和单一的业务数据发生混淆)，它实际上是一组业务数据构成的包，如贷款产品业务对象，内部是和贷款产品相关的所有业务数据模型。比业务对象更低一级的是业务属性和业务实体。最后是具体的数据定义。其中一类数据定义是域的定义，如日期、账户号等，它包含了域值的规则，如长度、赋值约束等等；还有一类数据定义是实例组，实例组可以包含N个实例，是一种数据字典，如地域(包含北京、上海实例)、年龄段(包含青年、中年、老年等实例)等等。域、实例组常作为其他对象、实体的属性。

若仅仅通过业务建模的方式，那么只能是得到文档，而文档并非是直接用于开发软件的数据文件。所以，本实施例实现的是业务建模与领域驱动设计的两套方法的数据层的打通，以实现从业务需求数据可以直接实现软件的设计开发。

203、基于业务建模平台与后端开发平台的预设映射关系，将所述业务流程模型和业务数据模型映射至后端开发平台，进行领域驱动设计的转换，得到应用层微服务和领域层微服务。

具体地，参见图3，所述领域驱动设计包括具有依赖关系的表现层、应用层、领域层和基础设施层。

所述表现层依赖于应用层、领域层和基础设施层。表现层可以用于处理用户显示和用户请求，但是不包含领域或业务逻辑。表现层采用OHS(开放主机服务)的方式向外提供API。

所述应用层依赖于领域层和基础设施层；应用层微服务位于应用层，应用服务是很轻量的，它本身不处理业务逻辑，而是用于协调对领域对象的操作，比如聚合。

应用层响应表现层中的用户操作，并调用领域层接口，将需要展现的业务数据以指定格式保存，提供给表现层。

所述领域层依赖于基础设施层；领域层包括领域对象和所述领域层微服务，所述领域层微服务用于处理业务逻辑。领域层可以引入状态容器库，例如Redux库。作为领域驱动设计的核心部分，领域层可以保存业务数据、业务操作、业务规则等等。

基础设施层主要实现对资源库的访问，例如以infrastructure JS功能组件实现基础设施层功能。

所述依赖关系通过所述表现层、应用层、领域层和基础设施层之间的调用关系约束来保证。

本实施例中，分层架构一个重要的原则是：每层只能与位于其下方的层发生耦合。分层架构的好处是显而易见的。首先，由于层间松散的耦合关系，每层的设计只专注当层即可，而无需关心其他层，也不必担心本层的设计会影响其它层，有利于提高软件质量。其次，分层架构使得程序结构清晰，升级和维护都变得十分容易，更改某层的代码，只要本层的接口保持稳定，其他层可以不必修改。即使本层的接口发生变化，也只影响其上层，修改工作量小且错误可以控制，不会带来意外的风险。

204、接收后端开发平台形成的所述表现层、应用层、领域层和基础设施层的依赖关系，完成目标软件的开发。

通过前述内容可见，基于领域驱动设计理论，通过4个层的协同，以实现目标软件的开发，具体的实现过程在本实施例中便不再赘述。

本发明提供的领域驱动的软件设计方法，通过将业务需求数据发送至业务建模平台进行建模处理，得到业务流程模型和业务数据模型；然后将业务流程模型和业务数据模型映射至后端开发平台，进行领域驱动设计的转换，得到应用层微服务和领域层微服务；然后接收后端开发平台形成的表现层、应用层、领域层和基础设施层的依赖关系，完成目标软件的开发，从而实现将业务建模与领域驱动设计的不同方法论的理论打通，不需要在需求、设计乃至开发阶段再完成相应的文档，可直接通过本方法业务建模平台与后端开发平台的预设映射关系，实现自动从业务需求数据到软件开发的过程，保证需求到开发软件的一致性，避免通过文档实现软件开发导致需求与产品偏差较大、质量较差的缺陷，从而提高产品的可靠性。

进一步地，所述业务流程模型包括：业务领域、业务阶段、活动、任务和步骤；所述业务数据模型包括：主题域、业务属性、业务实体、业务对象和业务组件；

具体地，步骤202包括：

S121、确定所述业务需求数据的所属业务流程，得到属于业务流程模型的业务领域、业务阶段、活动、任务和步骤。

业务流程模型是从最初的价值链开始，逐步的分解到很细致的、局部的流程模型，因此需要分级，分别对应业务领域、业务阶段、活动、任务和步骤。

关于业务流程模型的具体实现，在前述步骤202中有介绍，在此便不再赘述。

S122、将所述业务需求数据进行拆分，得到属于业务数据模型的主题域、业务属性、业务实体、业务对象和业务组件。

关于业务数据模型的具体实现，在前述步骤202中有介绍，在此便不再赘述。

需要注意的是，如业务领域、业务阶段、主题域，这些类型的架构元素可以看作目录型元素，它本身不具备具体的数据信息，仅为了划分业务数据模型的定义而存在。对于另一些架构元素如业务组件、业务对象，则是真正包含了具体的数据信息的。

通过步骤S121～122，通过基于业务需求数据的所属业务流程，得到属于业务流程模型的业务领域、业务阶段、活动、任务和步骤，将业务需求数据进行拆分，得到属于业务数据模型的主题域、业务属性、业务实体、业务对象和业务组件，从而可以基于业务需求数据得到拆分后的业务领域、业务阶段、活动、任务和步骤，以及主题域、业务属性、业务实体、业务对象和业务组件，从而为后续步骤中从业务数据模型以及业务流程模型到领域驱动设计之间的映射提供基础。

具体地，为了实现基于业务数据模型和业务流程模型的领域驱动设计，需要建立业务数据模型以及业务流程模型和领域驱动设计之间的映射关系，并为此映射关系提供强有效的约束规则，以实现从业务模型到领域驱动设计之间的转换。

具体地，参见图4，步骤203包括：

401、基于所述业务流程模型的业务领域和活动与应用层的映射关系，将所述业务流程模型的业务领域和活动映射至应用层，得到所述应用层微服务。

402、基于所述业务流程模型的任务和步骤与所述领域层的映射关系，以及所述业务数据模型的业务属性、业务实体、业务对象和业务组件与所述领域层的映射关系，将所述业务流程模型的任务和步骤以及所述业务数据模型的业务属性、业务实体、业务对象和业务组件映射至领域层，得到所述领域层微服务。

通过步骤401和402，基于预设的映射关系，将业务流程模型的业务领域和活动映射至应用层，得到应用层微服务，将业务流程模型的任务和步骤以及业务数据模型的业务属性、业务实体、业务对象和业务组件映射至领域层，得到领域层微服务，实现了从业务模型到领域驱动设计之间的转换。

图5示出了本实施例中的从业务模型到领域驱动设计之间的转换的示意图。其中，图中的虚线表达的是映射关系，实线表达的是业务建模平台侧，业务流程模型和业务数据模型之间的联系。

领域驱动设计包括以下元素：

领域：指特定业务领域，如银行、电商、医疗等。领域是开发的核心焦点，领域驱动设计通过深入理解和建模领域，将业务逻辑准确地映射到软件系统中。

领域模型：将业务领域中的概念和规则抽象出来，形成一个具有行为和状态的模型。

实体：领域模型中的实体是领域中的具体对象，具有唯一的标识和属性。实体可以包含业务逻辑和行为，与其他实体之间可以有关联和交互。

值对象：具有不可变性的对象，用于表示领域中的一些属性或组合属性，如日期、地址等。

聚合：聚合是一组相关实体和值对象的集合，它们在领域中具有内聚性，可以作为一个整体进行管理和操作。聚合根是聚合中的一个实体，负责协调聚合内的对象之间的交互。

领域服务：领域服务是一些无状态的操作或行为，用于处理领域中的复杂业务逻辑或跨多个实体的操作。领域服务可以与实体和值对象进行交互，但不属于它们的一部分。

以一个满减活动为例：

满减活动——满减活动是满减品的载体，一个满减活动可以包含多个满减品，并且多个满减活动可以同时存在。

领域模型：

活动名称——比如“双11限时满减”；

活动开始时间和结束时间：在活动期间内，用户才可以进行下单，用户下单时将进行活动时间校验；

活动状态——分为发布、上线和下线等。

活动描述——可为活动添加丰富的图文描述。

领域服务：

发布满减活动——当运营侧需要新的满减活动时，可以发布新的满减活动。满减活动发布后，将不对用户透出；

上线活动——当运营侧已确认活动可以上线时，可以对活动执行上线操作。

下线活动——当活动不需要继续进行时，可以对活动执行下线操作。活动下线后，用户将不可见。

满减活动下单条件检查——当用户执行满减下单时，满减活动可以根据此前配置的规则执行下单前置校验，确认当前活动是否允许下单。

领域事件：

满减活动上线——当满减活动被执行上线操作时，将发出对应的上线事件，以通知相关订阅者处理；

满减活动下线——当满减活动被执行下线操作时，将发出对应的下线事件，以通知相关订阅者处理。

更为具体地，参见图6，步骤401包括：

601、基于所述业务流程模型的业务领域和活动与应用层的映射关系，将业务领域映射至应用层，得到所述应用层微服务框架。

602、将所述活动中抽取联机的执行流程，作为场景服务，映射至应用层，转换为所述应用层微服务的应用服务。

603、基于所述应用层微服务框架和所述应用层微服务的应用服务，得到所述应用层微服务。

通过步骤601-603，将业务领域映射至应用层，得到应用层微服务框架；将活动中抽取联机的执行流程，作为场景服务映射至应用层，转换为应用层微服务的应用服务；基于应用层微服务框架和应用层微服务的应用服务，得到应用层微服务，从而实现基于业务流程模型以及预设的映射关系生成应用层微服务，可以得到应用层微服务。

更为具体地，参见图7，步骤402包括：

701、将所述业务流程模型的任务映射至领域层，转换为所述领域服务。

702、基于所述业务流程模型的任务和步骤与所述领域层的映射关系，将所述步骤映射至领域层，转换为所述实体对象以及值对象的行为。

703、基于所述业务数据模型的业务属性、业务实体、业务对象和业务组件与所述领域层的映射关系，将所述业务属性映射至领域层，转换为所述实体对象以及值对象的属性。

704、将所述业务对象映射至领域层，转换为所述聚合。

705、将所述业务实体映射至领域层，转换为所述实体对象以及值对象。

706、将所述业务组件映射至领域层，转换为所述领域层微服务的框架。

707、基于所述领域层微服务的框架、领域服务、聚合、实体对象、值对象、所述实体对象的属性和行为以及值对象的属性和行为，得到所述领域层微服务。

通过步骤701-707，将业务流程模型的任务和步骤以及业务数据模型的业务属性、业务实体、业务对象和业务组件分别映射至领域层，得到领域层微服务的框架、领域服务、聚合、实体对象、值对象、所述实体对象的属性和行为以及值对象的属性和行为，以确定领域层微服务，从而实现基于业务流程模型以及业务数据模型以及预设的映射关系得到领域层微服务。

通过以上的数据转换，可将业务模型视角的数据，转换为软件开发视角的数据，实现从业务需求到设计开发的数据级的贯通。

下面对本发明提供的领域驱动的软件设计装置进行描述，下文描述的领域驱动的软件设计装置与上文描述的领域驱动的软件设计方法可相互对应参照。

本发明实施例公开了一种领域驱动的软件设计装置，参见图8，用于设计开发工具，所述装置包括：

业务数据获取模块801，用于获取目标软件的业务需求数据；其中，所述业务需求数据为软件开发的所需数据；

业务建模模块802，用于将所述业务需求数据发送至业务建模平台进行建模处理，得到业务流程模型和业务数据模型；

领域驱动设计模块803，用于基于业务建模平台与后端开发平台的预设映射关系，将所述业务流程模型和业务数据模型映射至后端开发平台，进行领域驱动设计的转换，得到应用层微服务和领域层微服务；其中，所述领域驱动设计包括具有依赖关系的表现层、应用层、领域层和基础设施层；所述应用层微服务位于应用层，用于协调对领域对象的操作；所述领域层包括领域对象和所述领域层微服务，所述领域层微服务用于处理业务逻辑；

开发模块804，用于接收后端开发平台形成的表现层、应用层、领域层和基础设施层的依赖关系，完成目标软件的开发。

可选地，所述业务流程模型包括：业务领域、业务阶段、活动、任务和步骤；所述业务数据模型包括：主题域、业务属性、业务实体、业务对象和业务组件；

所述业务建模模块802，具体用于：

确定所述业务需求数据的所属业务流程，得到属于业务流程模型的业务领域、业务阶段、活动、任务和步骤；

将所述业务需求数据进行拆分，得到属于业务数据模型的主题域、业务属性、业务实体、业务对象和业务组件。

可选地，领域驱动设计模块803，具体用于：

基于所述业务流程模型的业务领域和活动与应用层的映射关系，将所述业务流程模型的业务领域和活动映射至应用层，得到所述应用层微服务；

基于所述业务流程模型的任务和步骤与所述领域层的映射关系，以及所述业务数据模型的业务属性、业务实体、业务对象和业务组件与所述领域层的映射关系，将所述业务流程模型的任务和步骤以及所述业务数据模型的业务属性、业务实体、业务对象和业务组件映射至领域层，得到所述领域层微服务。

可选地，领域驱动设计模块803，具体用于：基于所述业务流程模型的业务领域和活动与应用层的映射关系，将所述业务领域映射至应用层，得到所述应用层微服务框架；

将所述活动中抽取联机的执行流程，作为场景服务，映射至应用层，转换为所述应用层微服务的应用服务；

基于所述应用层微服务框架和所述应用层微服务的应用服务，得到所述应用层微服务。

可选地，所述领域层微服务包括：领域服务和聚合，所述聚合包括实体对象以及值对象；所述实体对象以及值对象均包括属性和行为；

领域驱动设计模块803，具体用于：将所述业务流程模型的任务映射至领域层，转换为所述领域服务；

基于所述业务流程模型的任务和步骤与所述领域层的映射关系，将所述步骤映射至领域层，转换为所述实体对象以及值对象的行为；

基于所述业务数据模型的业务属性、业务实体、业务对象和业务组件与所述领域层的映射关系，将所述业务属性映射至领域层，转换为所述实体对象以及值对象的属性；

将所述业务对象映射至领域层，转换为所述聚合；

将所述业务实体映射至领域层，转换为所述实体对象以及值对象；

将所述业务组件映射至领域层，转换为所述领域层微服务的框架；

基于所述领域层微服务的框架、领域服务、聚合、实体对象、值对象、所述实体对象的属性和行为以及值对象的属性和行为，得到所述领域层微服务。

可选地，所述表现层依赖于应用层、领域层和基础设施层；

所述应用层依赖于领域层和基础设施层；

所述领域层依赖于基础设施层；

所述依赖关系通过所述表现层、应用层、领域层和基础设施层之间的调用关系约束来保证。

本发明提供的领域驱动的软件设计装置，通过将业务需求数据发送至业务建模平台进行建模处理，得到业务流程模型和业务数据模型；然后将业务流程模型和业务数据模型映射至后端开发平台，进行领域驱动设计的转换，得到应用层微服务和领域层微服务；然后接收后端开发平台形成的表现层、应用层、领域层和基础设施层的依赖关系，完成目标软件的开发，从而实现将业务建模与领域驱动设计的不同方法论的理论打通，不需要在需求、设计乃至开发阶段再完成相应的文档，可直接通过本方法业务建模平台与后端开发平台的预设映射关系，实现自动从业务需求数据到软件开发的过程，保证需求到开发软件的一致性，避免通过文档实现软件开发导致需求与产品偏差较大、质量较差的缺陷，从而提高产品的可靠性。

图9示例了一种电子设备的实体结构示意图，如图9所示，该电子设备可以包括：处理器(processor)910、通信接口(Communications Interface)920、存储器(memory)930和通信总线940，其中，处理器910，通信接口920，存储器930通过通信总线940完成相互间的通信。处理器910可以调用存储器930中的逻辑指令，以执行所述领域驱动的软件设计方法，包括：获取目标软件的业务需求数据；将所述业务需求数据发送至业务建模平台进行建模处理，得到业务流程模型和业务数据模型；基于业务建模平台与后端开发平台的预设映射关系，将所述业务流程模型和业务数据模型映射至后端开发平台，进行领域驱动设计的转换，得到应用层微服务和领域层微服务；其中，所述领域驱动设计包括具有依赖关系的表现层、应用层、领域层和基础设施层；所述应用层微服务位于应用层，用于协调对领域对象的操作；所述领域层包括领域对象和所述领域层微服务，所述领域层微服务用于处理业务逻辑；接收后端开发平台形成的表现层、应用层、领域层和基础设施层的依赖关系，完成目标软件的开发。

此外，上述的存储器930中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

另一方面，本发明还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，计算机程序可存储在非暂态计算机可读存储介质上，所述计算机程序被处理器执行时，计算机能够执行上述各方法所提供的所述领域驱动的软件设计方法，包括：获取目标软件的业务需求数据；将所述业务需求数据发送至业务建模平台进行建模处理，得到业务流程模型和业务数据模型；基于业务建模平台与后端开发平台的预设映射关系，将所述业务流程模型和业务数据模型映射至后端开发平台，进行领域驱动设计的转换，得到应用层微服务和领域层微服务；其中，所述领域驱动设计包括具有依赖关系的表现层、应用层、领域层和基础设施层；所述应用层微服务位于应用层，用于协调对领域对象的操作；所述领域层包括领域对象和所述领域层微服务，所述领域层微服务用于处理业务逻辑；接收后端开发平台形成的表现层、应用层、领域层和基础设施层的依赖关系，完成目标软件的开发。

又一方面，本发明还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现以执行上述各方法提供的所述领域驱动的软件设计方法，包括：获取目标软件的业务需求数据；将所述业务需求数据发送至业务建模平台进行建模处理，得到业务流程模型和业务数据模型；基于业务建模平台与后端开发平台的预设映射关系，将所述业务流程模型和业务数据模型映射至后端开发平台，进行领域驱动设计的转换，得到应用层微服务和领域层微服务；其中，所述领域驱动设计包括具有依赖关系的表现层、应用层、领域层和基础设施层；所述应用层微服务位于应用层，用于协调对领域对象的操作；所述领域层包括领域对象和所述领域层微服务，所述领域层微服务用于处理业务逻辑；接收后端开发平台形成的表现层、应用层、领域层和基础设施层的依赖关系，完成目标软件的开发。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

1.一种领域驱动的软件设计方法，其特征在于，用于设计开发工具，所述方法包括：

获取目标软件的业务需求数据；其中，所述业务需求数据为软件开发的所需数据；

将所述业务需求数据发送至业务建模平台进行建模处理，得到业务流程模型和业务数据模型；

基于业务建模平台与后端开发平台的预设映射关系，将所述业务流程模型和业务数据模型映射至后端开发平台，进行领域驱动设计的转换，得到应用层微服务和领域层微服务；其中，所述领域驱动设计包括具有依赖关系的表现层、应用层、领域层和基础设施层；所述应用层微服务位于应用层，用于协调对领域对象的操作；所述领域层包括领域对象和所述领域层微服务，所述领域层微服务用于处理业务逻辑；

接收后端开发平台形成的所述表现层、应用层、领域层和基础设施层的依赖关系，完成目标软件的开发。

2.根据权利要求1所述的领域驱动的软件设计方法，其特征在于，所述业务流程模型包括：业务领域、业务阶段、活动、任务和步骤；所述业务数据模型包括：主题域、业务属性、业务实体、业务对象和业务组件；

将所述业务需求数据发送至业务建模平台进行建模处理，得到业务流程模型和业务数据模型，包括：

确定所述业务需求数据的所属业务流程，得到属于业务流程模型的业务领域、业务阶段、活动、任务和步骤；

将所述业务需求数据进行拆分，得到属于业务数据模型的主题域、业务属性、业务实体、业务对象和业务组件。

3.根据权利要求2所述的领域驱动的软件设计方法，其特征在于，所述业务流程模型的业务领域和活动与所述后端开发平台的应用层具有预设的映射关系，所述业务流程模型的任务和步骤与所述后端开发平台的领域层具有预设的映射关系；

所述业务数据模型的业务属性、业务实体、业务对象和业务组件与所述领域层具有预设的映射关系；

基于业务建模平台与后端开发平台的预设映射关系，将所述业务流程模型和业务数据模型映射至后端开发平台，进行领域驱动设计的转换，得到应用层微服务和领域层微服务，包括：

基于所述业务流程模型的业务领域和活动与应用层的映射关系，将所述业务流程模型的业务领域和活动映射至应用层，得到所述应用层微服务；

基于所述业务流程模型的任务和步骤与所述领域层的映射关系，以及所述业务数据模型的业务属性、业务实体、业务对象和业务组件与所述领域层的映射关系，将所述业务流程模型的任务和步骤以及所述业务数据模型的业务属性、业务实体、业务对象和业务组件映射至领域层，得到所述领域层微服务。

4.根据权利要求3所述的领域驱动的软件设计方法，其特征在于，基于所述业务流程模型的业务领域和活动与应用层的映射关系，将所述业务流程模型的业务领域和活动映射至应用层，得到所述应用层微服务，包括：

基于所述业务流程模型的业务领域和活动与应用层的映射关系，将所述业务领域映射至应用层，得到所述应用层微服务框架；

将所述活动中抽取联机的执行流程，作为场景服务，映射至应用层，转换为所述应用层微服务的应用服务；

基于所述应用层微服务框架和所述应用层微服务的应用服务，得到所述应用层微服务。

5.根据权利要求3所述的领域驱动的软件设计方法，其特征在于，所述领域层微服务包括：领域服务和聚合，所述聚合包括实体对象以及值对象；所述实体对象以及值对象均包括属性和行为；

基于所述业务流程模型的任务和步骤与所述领域层的映射关系，以及所述业务数据模型的业务属性、业务实体、业务对象和业务组件与所述领域层的映射关系，将所述业务流程模型的任务和步骤以及所述业务数据模型的业务属性、业务实体、业务对象和业务组件映射至领域层，得到所述领域层微服务，包括：

将所述业务流程模型的任务映射至领域层，转换为所述领域服务；

基于所述业务流程模型的任务和步骤与所述领域层的映射关系，将所述步骤映射至领域层，转换为所述实体对象以及值对象的行为；

基于所述业务数据模型的业务属性、业务实体、业务对象和业务组件与所述领域层的映射关系，将所述业务属性映射至领域层，转换为所述实体对象以及值对象的属性；

将所述业务对象映射至领域层，转换为所述聚合；

将所述业务实体映射至领域层，转换为所述实体对象以及值对象；

将所述业务组件映射至领域层，转换为所述领域层微服务的框架；

基于所述领域层微服务的框架、领域服务、聚合、实体对象、值对象、所述实体对象的属性和行为以及值对象的属性和行为，得到所述领域层微服务。

6.根据权利要求1所述的领域驱动的软件设计方法，其特征在于，所述表现层依赖于应用层、领域层和基础设施层；

所述应用层依赖于领域层和基础设施层；

所述领域层依赖于基础设施层；

所述依赖关系通过所述表现层、应用层、领域层和基础设施层之间的调用关系约束来保证。

7.一种领域驱动的软件设计装置，其特征在于，用于设计开发工具，所述装置包括：

业务数据获取模块，用于获取目标软件的业务需求数据；其中，所述业务需求数据为软件开发的所需数据；

业务建模模块，用于将所述业务需求数据发送至业务建模平台进行建模处理，得到业务流程模型和业务数据模型；

领域驱动设计模块，用于基于业务建模平台与后端开发平台的预设映射关系，将所述业务流程模型和业务数据模型映射至后端开发平台，进行领域驱动设计的转换，得到应用层微服务和领域层微服务；其中，所述领域驱动设计包括具有依赖关系的表现层、应用层、领域层和基础设施层；所述应用层微服务位于应用层，用于协调对领域对象的操作；所述领域层包括领域对象和所述领域层微服务，所述领域层微服务用于处理业务逻辑；

开发模块，用于接收后端开发平台形成的所述表现层、应用层、领域层和基础设施层的依赖关系，完成目标软件的开发。

8.根据权利要求7所述的领域驱动的软件设计装置，其特征在于，所述业务流程模型包括：业务领域、业务阶段、活动、任务和步骤；所述业务数据模型包括：主题域、业务属性、业务实体、业务对象和业务组件；

所述业务建模模块，具体用于：

确定所述业务需求数据的所属业务流程，得到属于业务流程模型的业务领域、业务阶段、活动、任务和步骤；

将所述业务需求数据进行拆分，得到属于业务数据模型的主题域、业务属性、业务实体、业务对象和业务组件。

9.一种电子设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1至6任一项所述领域驱动的软件设计方法的步骤。

10.一种非暂态计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至6任一项所述领域驱动的软件设计方法的步骤。