基于业务中台的应用开发方法、系统、装置及存储介质

技术领域

本发明涉及软件开发领域，尤其是一种基于业务中台的应用开发方法、系统、装置及存储介质。

背景技术

在以往的互联网企业生产流程中，我们可以将研发过程宏观的划分为前端与后端两个部分。所谓前台就是用户直接接触到的产品部分，如可在应用商店下载的APP，如微信、抖音、淘宝，或者可以使用的网站等。用户对产品的认知也往往是基于前端，而后端提供的服务是面对于开发者而不被普通用户所感知的。在互联网进入日益复杂的市场环境的今天，企业需要不断去更新产品去抢夺市场。而作为实际用户真正接触的前端业务，如：APP、小程序、网站等，必须要快速迭代新的功能才能让产品保持竞争力。

然而以往为了支撑前台越来越多的业务，后台反而在这个时候显得笨重起来。这样的后台变得较难去快速响应前端变化所带来的改变。原来的前后端模式的这种直接关联导致了两者的冲突。由于业务数据的复杂性，每个用户在同一条数据中的担任的角色往往不同，可能是其中某一种角色，也可能是多种角色。这就导致每个用户在不同业务状态下能看到的组件不大相同。列举最简单的例子，在业务系统中几乎每个基础模块中都包含基础CURD(创建(Create)、更新(Update)、读取(Retrieve)和删除(Delete)的数据库基本操作)的功能，开发人员需要花费大量精力去开发这些重复性代码，由此造成了系统重复建设、迁移较困难、能力复用性较低的问题。

发明内容

为解决上述现有技术的问题，本发明提供了一种基于业务中台的应用开发方法，包括以下步骤：

S1:获取不同业务场景的共性需求，将所述共性需求进行归纳抽象，并根据所述归纳抽象后的共性需求设计并提供引擎服务，通过可视化页面对所述引擎服务的配置进行展示；

S2:通过业务中台对所述不同业务场景进行分析并对所有所述引擎服务进行分类，将所述引擎服务封装并定义成业务组件；

S3:根据业务需求将所述业务组件分配到业务场景中，并对各个业务组件之间的业务逻辑进行配置以完成应用开发。

在上述方案的基础上本发明还可以做如下改进。

进一步，所述S2中业务中台中对所有所述引擎服务进行分类，根据所述业务需求中的共性需求将所述引擎服务封装并定义为业务组件包括：对所述引擎服务进行标准化管理，对于引擎服务中的请求地址以及参数格式进行数据标准的统一。

进一步，将多个业务组件封装成业务构件，以实现页面的特定业务需求。

进一步，所述S2中还包括：对业务场景的业务需求、主要功能以及应用场景进行应用管理，自定义应用的数据角色，并预设数据角色的查询条件以及参数，以供查询当前应用中的数据角色，并根据业务需求对所述数据角色分配业务组件。

进一步，所述S3中根据业务需求将所述业务组件分配到业务场景中，并对各个业务组件之间的业务逻辑进行配置，包括以下步骤，

S301,根据业务需求选取相应数据角色的业务组件和/或业务构件，并对所述业务组件的通用性参数进行配置，通过流程引擎将业务组件的逻辑流程串联以及状态翻转后生成程序代码；

S302,将所述程序代码通过解析器解析成页面JSON信息表单；

S303,获取页面JSON信息后，通过执行页面生成器反向生成的代码，动态挂载页面布局。

本发明另一个目的在于提供一种基于业务中台的应用开发系统，包括数据后端、业务中台以及业务前台：

所述数据后端用于获取不同业务场景的共性需求，将所述共性需求进行归纳抽象，并根据所述归纳抽象后的共性需求设计并提供引擎服务，通过可视化页面对所述引擎服务的配置进行展示；

所述业务中台用于对所述不同的业务场景进行分析并对所有所述引擎服务进行分类，将所述引擎服务封装并定义成业务组件；

所述业务前台用于根据业务需求将所述业务组件分配到业务场景中，并对各个组件之间的业务逻辑进行配置以完成应用开发。

进一步，所述业务中台还用于：对业务场景的业务需求、主要功能以及应用场景进行应用管理，自定义应用的数据角色，并预设数据角色的查询条件以及参数，以供查询当前应用中的数据角色，并根据业务需求对所述数据角色分配业务组件。

进一步，所述业务前台中根据业务需求将所述业务组件分配到业务场景中，并对各个业务组件之间的业务逻辑进行配置，包括以下步骤，

根据业务需求选取相应数据角色的业务组件和/或业务构件，并对所述业务组件的通用性参数进行配置，通过流程引擎将业务组件的逻辑流程串联以及状态翻转后生成程序代码；

将所述程序代码通过解析器解析成页面JSON信息表单；

获取页面JSON信息后，通过执行页面生成器反向生成的代码，动态挂载页面布局。

本发明再一个目的在于提供一种基于业务中台的应用开发装置，其特征在于：包括存储器和处理器，所述存储器存储有至少一段程序，所述至少一段程序由所述处理器执行上述的基于业务中台的应用开发方法。

本发明还提供一种计算机可读存储介质，所述存储介质中存储有至少一段程序，所述至少一段程序由所述处理器执行以实现如上述的基于业务中台的应用开发方法。

本发明的有益效果是：通过对组件的构建以及对业务场景共性需求的抽象，可以在业务中台中业务画布的对业务组件进行拼装，对指挥调度中的任务、情报模块应用进行了统一的改造，运维人员根据业务需求配置相应功能的组件即可满足用户的实时性修改的目标，使得研发人员的力量得到了很大的释放，实现了业务研发、快速迭代、运维快速反应方案。此方法是一种可分解、可管理的、共享的设计理念。支持可靠的、可定制、可升级、安全快速的应用构建思路，通过使用业务中台搭建的业务应用程序比起其他传统程序能有更短的研发周期，更健壮的运行机制，更快速的运维响应，更平滑的升级体验，更长的服务寿命。在业务诉求快速迭代和技术手段不断更新的时代，业务中台化的设计思想和组件、构件、页面、流程的可视化研发手段，对于不同领域应用系统的快速构建具有重大意义。

附图说明

图1为本发明一种基于业务中台的应用开发方法的流程框图；

图2为本发明基于业务中台的应用程序设计架构示意图；

图3为本发明对于业务组件进行配置的方法流程图；

图4为本发明中业务前台中应用配置界面示意图；

图5为本发明中业务前台中角色配置界面示意图；

图6为本发明中业务前台中新增组件配置界面示意图；

图7为本发明中业务前台中业务流程配置界面示意图；

图8为本发明组件编辑以及其组件预览示意图。

具体实施方式

以下结合附图对本发明的原理和特征进行描述，所举实例只用于解释本发明，并非用于限定本发明的范围。

如图1所示，一种基于业务中台的应用开发方法，其特征在于：

S1:获取不同业务场景的共性需求，将所述共性需求进行归纳抽象，并根据所述归纳抽象后的共性需求设计并提供引擎服务，通过可视化页面对所述引擎服务的配置进行展示；

S2:通过业务中台对所述不同业务场景进行分析并对所有所述引擎服务进行分类，将所述引擎服务封装并定义成业务组件；

S3:根据业务需求将所述业务组件分配到业务场景中，并对各个业务组件之间的业务逻辑进行配置以完成应用开发。

本发明通过对组件的构建以及对业务场景共性需求的抽象，可以在业务中台中业务画布的对业务组件进行拼装，对指挥调度中的任务、情报模块应用进行了统一的改造，运维人员根据业务需求配置相应功能的组件即可满足用户的实时性修改的目标，使得研发人员的力量得到了很大的释放，实现了敏捷研发、快速迭代、运维快速反应方案。此方法是一种可分解、可管理的、共享的设计理念。支持可靠的、可定制、可升级、安全快速的应用构建思路，通过使用业务中台搭建的业务应用程序比起其他传统程序能有更短的研发周期，更健壮的运行机制，更快速的运维响应，更平滑的升级体验，更长的服务寿命。在业务诉求快速迭代和技术手段不断更新的时代，业务中台化的设计思想和组件、构件、页面、流程的可视化研发手段，对于不同领域应用系统的快速构建具有重大意义。

在本实施例中具体地，获取用户需求并设计构建用以实现用户需求的业务场景，根据各种业务场景的特点，对业务场景中的功能进行分析并拆分，将用以实现业务场景的单一应用程序划分成小的服务即引擎服务(面向服务的体系结构(SOA)架构样式的一种变体)，引擎服务之间互相协调、互相配合，为用户提供最终价值。每个引擎服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通，每个服务都围绕着具体业务场景功能进行构建，并且能够独立地部署。对各个业务场景中引擎服务进行分类，并对将用以实现主要功能和/或实例化用户需求的可变因素以及在各个业务场景中需要重复使用的引擎服务(复用因素)进行分类，将多个业务场景的共性需求进行归纳抽象，并以组件化的形式将复用因素封装并定义为业务组件，为各个业务应用场景的实现提供可数据共享的业务组件。实现研发可复用的服务对接底层逻辑和UI端构件渲染数据的前端逻辑层，业务中台来实例化业务需求，提高支持产品、运营的效率，减少编码数量。

在本实施例中具体地，通过抽取引擎服务中的可变因素并将引擎服务中的因素共性定义，以将多个业务组件封装成业务构件以实现页面的特定业务需求。其中业务组件是构成应用功能页面的基本元素，即是一种可以被结构化的信息。在各业务场景实现过程中，用来组成描述应用功能页面的某一单元，在实际业务场景中每个页面可包含任意多种，任意多个组件。本发明通过抽象和整理不同业务场景下每种组件的变化部分和通用部分，尽可能将不同场景中相同组件的变化封装到一种组件当中。而构件则是由2个及以上的组件封装而成的带有特定业务需求的元素，可以支持组件间的灵活拼装及组成其他构建。在业务中台中的业务画布上组装业务组件和/或构件开发组件库中没有的组件并注册。将在业务画布中用以实现业务场景的业务组件统一配置参数，并对各个组件之间的业务逻辑进行配置，构建业务场景完成应用开发。

上述方案实现了低代码的方式构建应用系统的技术方案，对运维，敏捷研发，部署等以及多种领域的应用系统的快速构建具有重大意义。这种方法进一步简化了由于业务复杂度的提高而带来的基本组件抽象难度，减少了开发难度。

图2为本发明一实施例的基于业务中台的应用程序设计架构示意图。在本实施例中具体地，如图2所示，对业务场景中合理需求、主要功能以及应用场景进行应用管理，通过自定义应用的数据角色并预设查询条件以及参数，以供查询在当前应用中的数据角色，根据业务需求通过业务组件对所述数据角色进行分配。为了保证应用系统构建在各个业务场景，我们对各类业务组件进行了模型结构化定义，以支持多场景定义自由化、数据多形态可视化、服务对接灵活化。

以业务系统中的业务场景为例，新建应用任务办理，通过业务分析得出新建关联角色发起人、审批人、派发人、承办人、协办人、访客等，并为其预设好对应的角色代码，根据原型图分解业务组件和构建，根设计好的业务表建立相应的业务字典，根据业务流程配置，设置对应组件显示的组合条件，如工作办理组件中，发起人角色设置条件为任务类型、任务状态的某些字典预设值。再根据流程编辑预设可选审批人，编辑保存后即可发布。

在搭建各类目组件属性和业务场景构建过程中，本发明业务开发系统各种服务对接的技术实践。所述数据后端的开发员根据提供的业务需求以及原型设计图等开发需求设计并实现的引擎服务。其中根据产品、应用部门提供的用户需求、原型设计图，按照如下步骤进行组件分类和模型的设计，以业务场景中需要的录入项、角色权限、录入验证规则为基础抽象出几类组件。结构以下表1为例：

表1

其中业务组件、业务构件：以及相关的业务组件和业务构件的注册以及封装定义的描述，用于业务前台的解析驱动。结构如下表2所示：

表2

结果集的渲染形态可选范围(默认对接的缺省为：T1,B1)，如下表3所示：

表3

业务组件以及业务构件的开发实现由数据后端的研发部门或人员上传源代码，预览图片及示例链接，集成到业务中台的构件库中，丰富构件内容。研发部门或人员定义用户在引擎服务中充当的角色并对数据角色进行管理，将数据角色绑定到对应应用上，通过设置查询条件和参数，可以快速查询出用户在当前应用中数据的担任角色，查询方式支持本地调用、远程调用、批量查询(列表按钮服务)。在实现业务场景的过程中由于业务数据的复杂性，不同用户在同一条服务中担任的数据角色往往不同，可能是其中某一种数据角色，也可能是多种数据角色。

例如在一条任务中，张三是任务的创建人，创建任务后可以看到任务基本信息、任务内容、任务要求3个组件；李四是任务的审批人，任务状态为待审批的状态下可以看到任务基本信息、任务内容、任务要求、任务审批4个组件；王五为任务的办理人员，任务审批通过后可以看到任务基本信息、任务内容、任务要求、任务办理这4个组件；若张三既是创建人又是办理人员则判断逻辑更为复杂，此时就产生了不同的用户在同一条任务担任的角色不一样，这就导致每个用户在不同业务场景中可能看到的业务组件不同。

一般情况，研发会直接将判断条件硬编码在代码中进行逻辑判断，不利于后续的需求变更，如甲方在某一天提出需求，办理人不能看到任务要求这个组件，研发还需要重新修改源码，打包部署，而本专利通过解耦硬编码，实现客户需求变，配置一下即可改变生产系统的页面展示。

研发部门人员通过定义组件名称、组件描述、组件类别、组件排序等去定义组件，对用于配置业务场景的组件、构件进行注册，通过执行页面生成器拆解注册约定的组件、构件反向生成的代码，实现页面布局的动态挂载。研发部门或人员可以通过下文所述示例性算法中的一个或多个来对驱动组件显示或隐藏。所述示例性算法通常可以采用对于数据角色的分配支持多条件按照多个数据字典分配；自定义sql分配；支持且、或判断分配；支持分组条件配置；按照组件类型分为组件、底部工具栏、按钮进行分配；支持无限嵌套；支持自定义排序，即前端自定义展示顺序，保存后即可驱动页面。研发部门或人员通过可视化研发手段去定义组件，可以实现对于不同领域应用系统的快速构建，使用业务中台搭建的业务应用程序比起其他传统程序能有更短的研发周期，更健壮的运行机制，更快速的运维响应，更平滑的升级体验，更长的服务寿命。

在本实施例中具体地，对所述引擎服务进行标准化管理，对于引擎服务中的请求地址以及参数格式进行数据标准的统一。将定义好的组件、构件可视化处理后分配到具体的业务页面中，可配置各个组件、构件之间的逻辑关系，配置当前页面的后端请求url(统一资源定位符)。采用前后分离的引擎驱动模式，基于业务中台的配置中心或者分布式配置中心来支持后端引擎服务程序。例如列表和区块的组件，各请求响应解析改为统一标准，降低前端对接服务的工作量。而随着业务场景不断的变化，比如部门、任务、用户标签、状态、场景等使用业务中台来配置，进行额外的动态参数扩展，从而使我们的应用系统在业务表现层和业务逻辑层实现解耦，达到运行时动态紧耦合管理的标准。这样实现了前端研发能够专心的拼装页面或拼装构件，不用关心业务逻辑。后端开发人员专心关注业务逻辑的实现，所有的业务场景都可以由业务中台配置产生。将原本业务上、系统上、研发过程中等很多易变的数据进行管理，使应用系统在业务表现层和业务逻辑层实现解耦，达到运行时动态紧耦合管理的标准。

图3为本发明对于业务组件进行配置的方法流程图。在本实施例中具体地，如图3所示，对于业务组件进行配置的方法包括:S301,根据业务需求选取相应数据角色的业务组件和/或业务构件，并对所述业务组件的通用性参数进行配置，通过流程引擎将业务组件的逻辑流程串联以及状态翻转后生成程序代码；S302,将所述程序代码通过解析器解析成页面JSON信息表单；S303,获取页面JSON信息后，通过执行页面生成器反向生成的代码，动态挂载页面布局。示例性地，设计及代码生成器，可通过组件库例如基于Element的Vue项目中，将生成的代码直接运行；也可导出JSON表单，使用配套的解析器将JSON解析成真实的表单。使用UI端、服务端解析、执行引擎，进行对接调试，将生成的JSON代码通过解析器解析成页面JSON信息表单；获取页面JSON信息后，通过执行页面生成器反向生成的代码，拆解注册约定的组件、构件，生成页面布局，实现页面布局的动态挂载。组件、构件内的UI渲染，并根据配置的属性进行解析，例如布局占比、菜单、导航、固定位置、icon、class样式等。通过数据监控引擎的支撑，其UI端就可以使用引擎服务提供的统一请求地址和参数格式，通过服务ID、参数、配置信息的变换，然后统一的在服务端做参数验证、权限校验、日志记录、响应数据的统一格式处理。同时为了提高搜索效率，以及搜索的精准度，会大量使用Redis、MongoDB等NoSQL数据库，也会使用大量的Solr、Elasticsearch等全文检索服务。通过使用CDC(changedatacapture，数据变更抓取)技术进行同步，将代码完全解耦，API完全解耦，将变化的数据同步到这些数据库。通过引擎服务端统一的服务入口接入参数，进行技术元数据、业务元数据的执行引擎解析，提供应用查询、排序、聚合分组统计、分页等架构的能力，同时返回标准统一的数据格式，且携带了资源服务对应的数据字段属性的元数据。约定前端依据服务解析元数据，在后期我们仅需要修改元数据的描述即可配置出不同形态的特色应用。通过流程引擎将几个不同的页面串联起来，在此过程中，研发人员只需关注流程的走向并在页面中配置流程节点的属性和关注流程变化后业务数据的状态反转等因素即可。

通过执行以上的步骤，从开始设计到执行，最终的结果是：我们得到一个自研的、灵活的应用实例。根据各业务场景的特点，进行拆分，确保组件、构件复用的必要性。总体来说，就是研发可复用的服务对接底层逻辑和UI端构件渲染数据的前端逻辑层，业务中台来实例化业务需求，提高支持产品、运营的效率，减少编码数量。中台的设计更多地注重对核心业务的流程和逻辑进行抽象，使其扁平化、可视化，通过可视化配置来实现各个业务的需求。

在另一个实施例中具体地，本发明还提供一种基于业务中台的应用开发系统，包括数据后端、业务中台以及业务前台：所述数据后端用于获取不同业务场景的共性需求，将所述共性需求进行归纳抽象，并根据所述归纳抽象后的共性需求设计并提供引擎服务，通过可视化页面对所述引擎服务的配置进行展示；所述业务中台用于对所述不同的业务场景进行分析并对所有所述引擎服务进行分类，将所述引擎服务封装并定义成业务组件，根据业务场景的业务需求、主要功能以及应用场景进行应用管理，自定义应用的数据角色，并预设数据角色的查询条件以及参数，以供查询当前应用中的数据角色，并根据业务需求对所述数据角色分配业务组件；所述业务前台用于根据业务需求将所述业务组件分配到业务场景中，并对各个组件之间的业务逻辑进行配置以完成应用开发。

在本实施例的一具体实现中，示例性地，关于所述业务前台中应用配置界面、角色配置界面、新增组件界面、业务流程配置界面可以分别如图4、图5、图6以及图7所示；对于组件编辑以及其组件预览如图8所示。图4-图8中所示出的仅为示例性地，根据具体业务的不同，所使用的配置界面、角色配置界面、新增组件界面、业务流程配置界面、组件编辑以及其组件预览界面均可根据需要进行设计，如使用的具体组件等可不同。

在另一个实施例中具体地，所述业务前台中根据业务需求将所述业务组件分配到业务场景中，并对各个业务组件之间的业务逻辑进行配置，包括以下步骤，根据业务需求选取相应数据角色的业务组件和/或业务构件，并对所述业务组件的通用性参数进行配置，通过流程引擎将业务组件的逻辑流程串联以及状态翻转后生成程序代码；将所述程序代码通过解析器解析成页面JSON信息表单；获取页面JSON信息后，通过执行页面生成器反向生成的代码，动态挂载页面布局。

本发明还提供一种基于业务中台的应用开发装置，包括存储器和处理器，所述存储器存储有至少一段程序，所述至少一段程序由所述处理器执行以实现上述的图像伪造检测方法。作为一个可执行方案，图像伪造检测装置可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。系统/电子设备可包括，但不仅限于，处理器、存储器。本领域技术人员可以理解，上述系统/电子设备的组成结构仅仅是系统/电子设备的示例，并不构成对系统/电子设备的限定，可以包括比上述更多或更少的部件，或者组合某些部件，或者不同的部件。例如系统/电子设备还可以包括输入输出设备、网络接入设备、总线等，本发明实施例对此不做限定。

进一步地，作为一个可执行方案，所称处理器可以是中央处理单元(CentralProcessing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital SignalProcessor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，处理器是系统/电子设备的控制中心，利用各种接口和线路连接整个系统/电子设备的各个部分。

存储器可用于存储计算机程序和/或模块，处理器通过运行或执行存储在存储器内的计算机程序和/或模块，以及调用存储在存储器内的数据，实现系统/电子设备的各种功能。存储器可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据手机的使用所创建的数据等。此外，存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

本发明还提供一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器执行时实现本发明实施例上述方法的步骤。系统/电子设备集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，计算机程序包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。计算机可读介质可以包括：能够携带计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)以及软件分发介质等。需要说明的是，计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减。

读者应理解，在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的方法实施例仅仅是示意性的，例如，步骤的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个步骤可以结合或者可以集成到另一个步骤，或一些特征可以忽略，或不执行。

以上，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。