CN111694555B - 业务系统构建方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请提供一种业务系统构建方法、装置、电子设备及存储介质，涉及业务管理技术领域。所述方法包括：将业务功能之间的逻辑结构抽象为业务架构模型，业务架构模型包括用于实现各业务功能的功能域；基于功能域的结构关系构建应用架构模型，应用架构模型包括用于处理功能域对应业务功能的应用域，业务功能、功能域和应用域一一对应；基于数据字典建立数据架构模型，数据架构模型包括用于存储实体对象与功能域之间的业务关系和数据的数据域，数据域与应用域通过功能域基于数据映射技术连接。本方法基于数据映射技术，通过功能域将应用域和数据域连接架构生成业务系统，通过业务功能关系将相关对象连接起来，从而提高了业务处理效率。

Description

业务系统构建方法、装置、电子设备及存储介质

技术领域

本申请涉及业务管理技术领域，具体而言，涉及一种业务系统构建方法、装置、电子设备及存储介质。

背景技术

业务是企业或部门核心价值的载体，是由必不可少的价值增值环节通过各种逻辑关系组合而成的企业核心价值链。不同的业务形态不同，但是本质相同，都是创造价值。但是现有的业务管理模式通常无法将具体业务、业务数据以及业务对象进行统一整合，三者之间的业务流程联系并不充分，且对于业务范围较大的企业或组织来说，全业务数据的接入与汇聚较为散乱，存在业务管理和处理效率较低的问题。

发明内容

有鉴于此，本申请实施例的目的在于提供一种业务系统构建方法、装置、电子设备及存储介质，以改善现有技术中存在的存在业务管理和处理效率较低的问题。

本申请实施例提供了一种业务系统构建方法，所述方法包括：将指定业务对应的至少一个业务功能之间的逻辑结构抽象为业务架构模型，所述业务架构模型包括用于实现所述指定业务中各业务功能的至少一个功能域，功能域与业务功能一一对应；基于所述业务架构模型中的所述至少一个功能域的结构关系构建应用架构模型，所述应用架构模型包括用于用户设备处理所述至少一个功能域对应业务功能的至少一个应用域，功能域与应用域一一对应；获取所述至少一个功能域中每个功能域的数据字典，基于所述数据字典建立数据架构模型，所述数据架构模型包括用于存储实体对象与功能域之间的业务关系和业务数据的至少一个数据域，功能域与数据域一一对应，每个数据域与对应的应用域通过对应的功能域基于数据映射技术进行连接。

在上述实现方式中，关联建立业务架构模型、应用架构模型和数据架构模型，提高了业务、数据和应用之间的关联性，以提高业务的可管理性，以业务架构模型中的功能域为对应基础，采用数据映射技术连接数据域和应用域，并结合统一的数据架构模型进行数据的统一存储和管理，解决了数据冗杂问题，满足了业务处理应用和分析类应用的使用需求，从而提高了业务处理效率。

可选地，所述将指定业务对应的至少一个业务功能之间的逻辑结构抽象为业务架构模型，包括：确定所述指定业务对应的所述至少一个业务功能中每个业务功能的业务领域；基于所述业务领域确定所述每个业务功能的业务职能，所述业务职能为所述每个业务功能的至少一个相关业务能力；基于所述业务职能的至少一个业务活动以及所述至少一个业务活动之间的关联关系确定业务流程；基于所述业务领域、所述业务职能和所述业务流程确定所述至少一个业务功能之间的逻辑结构；将所述逻辑结构抽象为所述业务架构模型。

在上述实现方式中，基于业务功能的具体相关业务领域的划分，继而依次其业务职能、业务活动和业务流程，从而完成了对业务的职能划分、流程梳理和最小业务单元拆解，能够根据业务功能对应的岗位业务职能和业务场景进行对象和场景设计，形成一体化业务架构，为与业务相关的应用、服务和数据模型的设计提供业务依据。

可选地，所述基于所述业务架构模型中的所述至少一个功能域的结构关系构建应用架构模型，包括：确定所述至少一个业务活动中每个业务活动对应的微应用，所述微应用用于调用至少一个微服务实现对应的业务活动；将业务活动与业务功能的逻辑关系作为所述至少一个功能域的结构关系；基于所述结构关系将所述微应用分别聚合形成与所述至少一个功能域一一对应的应用域。

在上述实现方式中，以微应用和应用域实现“服务化、组件化”的设计，使应用架构更加符合业务域的业务流程，从而提高了应用的响应速度，并且通过应用域能够为业务提供完整的解决方案。

可选地，所述获取所述至少一个功能域中每个功能域的数据字典，包括：确定所述至少一个功能域中每个功能域的实体对象、对象属性和业务活动；基于所述实体对象、所述对象属性和所述业务活动确定所述每个功能域的数据项、数据结构、数据流、数据存储和/或处理逻辑；基于所述数据项、所述数据结构、所述数据流、所述数据存储和/或所述处理逻辑生成所述每个功能域的所述数据字典。

在上述实现方式中，基于数据字典确定业务对数据存储规划的需求，从而使数据架构模型能够以业务为驱动进行构建，且数据字典能够清楚地描述功能域的实体属性及实体对象间的活动关系，从而能完善数据架构设计，使数据架构模型更加贴合功能域对应的实体对象。

可选地，所述方法还包括：确定每个所述应用域和每个所述微应用的业务活动类型、访问流量和访问地域；基于所述访问流量和所述访问地域，采用分布式存储技术生成服务器架构模型，所述服务器架构模型用于表示物理服务器的地域分布和类型。

在上述实现方式中，基于应用域和微应用的具体访问情况，采用分布式存储技术进行分地域和流量的服务器架构模型构建，能够有效提高服务器对业务的处理效率，避免资源剩余或过于集中，基于分布式网络存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息的特点，不但提高了业务系统的可靠性、可用性和存取效率，还易于扩展。

可选地，所述方法还包括：基于数据域和业务域的连接关系，以及所述物理服务器的地域分布确定所述至少一个应用域中每个应用域和所述至少一个数据域中每个数据域的边界性质；基于所述边界性质生成安全架构模型，所述安全架构模型用于表示是否对所述每个应用域或所述每个数据域设置防火墙、入侵检测设备、单向安全隔离装置。

在上述实现方式中，基于每个数据域的边界性质，更加适应业务需求地进行安全防控，采取防火墙、入侵检测设备、单向安全隔离装置等保障措施，实现不同安全区域及接入对象之间风险管控及安全监测，提高了业务系统的安全性。

可选地，所述数据映射技术包括Java数据库连接和/或对象关系映射。

在上述实现方式中，Java数据库连接在通信设备满足一定通信数据格式时即可通过软件进行通信，而该通信数据格式可以基于业务系统具体架构进行设定，从而使通信连接更适用于业务系统；此外，对象关系映射在业务系统中数据需要面向对象较多且不定时，更加方便使用多态的方式去处理不同实例的操作，能够提高业务系统的数据处理效率。

本申请实施例还提供了一种业务系统构建装置，所述装置包括：业务架构模型建立模块，用于指定业务对应的至少一个业务功能之间的逻辑结构抽象为业务架构模型，所述业务架构模型包括用于实现所述指定业务中各业务功能的至少一个功能域，功能域与业务功能一一对应；应用架构模型建立模块，用于基于所述业务架构模型中的所述至少一个功能域的结构关系构建应用架构模型，所述应用架构模型包括用于用户设备处理所述至少一个功能域对应业务功能的至少一个应用域，功能域与应用域一一对应；数据架构模型建立模块，用于获取所述至少一个功能域中每个功能域的数据字典，基于所述数据字典建立数据架构模型，所述数据架构模型包括用于存储实体对象与功能域之间的业务关系和业务数据的至少一个数据域，功能域与数据域一一对应，每个数据域与对应的应用域通过对应的功能域基于数据映射技术进行连接。

在上述实现方式中，关联建立业务架构模型、应用架构模型和数据架构模型，提高了业务、数据和应用之间的关联性，以提高业务的可管理性，以业务架构模型中的功能域为对应基础，采用数据映射技术连接数据域和应用域，并结合统一的数据架构模型进行数据的统一存储和管理，解决了数据冗杂问题，满足了业务处理应用和分析类应用的使用需求，从而提高了业务处理效率。

可选地，所述业务架构模型建立模块具体用于：确定所述指定业务对应的所述至少一个业务功能中每个业务功能的业务领域基于所述业务领域确定所述每个业务功能的业务职能，所述业务职能为所述每个业务功能的至少一个相关业务能力；基于所述业务职能的至少一个业务活动以及所述至少一个业务活动之间的关联关系确定业务流程；基于所述业务领域、所述业务职能和所述业务流程确定所述至少一个业务功能之间的逻辑结构；将所述逻辑结构抽象为所述业务架构模型。

在上述实现方式中，基于业务功能的具体相关业务领域的划分，继而依次其业务职能、业务活动和业务流程，从而完成了对业务的职能划分、流程梳理和最小业务单元拆解，能够根据业务功能对应的岗位业务职能和业务场景进行对象和场景设计，形成一体化业务架构，为与业务相关的应用、服务和数据模型的设计提供业务依据。

可选地，所述应用架构模型建立模块具体用于：确定所述至少一个业务活动中每个业务活动对应的微应用，所述微应用用于调用至少一个微服务实现对应的业务活动；将业务活动与业务功能的逻辑关系作为所述至少一个功能域的结构关系；基于所述结构关系将所述微应用分别聚合形成与所述至少一个功能域一一对应的应用域。

在上述实现方式中，以微应用和应用域实现“服务化、组件化”的设计，使应用架构更加符合业务域的业务流程，从而提高了应用的响应速度，并且通过应用域能够为业务提供完整的解决方案。

可选地，所述数据架构模型建立模块具体用于：确定所述至少一个功能域中每个功能域的实体对象、对象属性和业务活动；基于所述实体对象、所述对象属性和所述业务活动确定所述每个功能域的数据项、数据结构、数据流、数据存储和/或处理逻辑；基于所述数据项、所述数据结构、所述数据流、所述数据存储和/或所述处理逻辑生成所述每个功能域的所述数据字典。

在上述实现方式中，基于数据字典确定业务对数据存储规划的需求，从而使数据架构模型能够以业务为驱动进行构建，且数据字典能够清楚地描述功能域的实体属性及实体对象间的活动关系，从而能完善数据架构设计，使数据架构模型更加贴合功能域对应的实体对象。

可选地，所述业务系统构建装置还包括：服务器架构模型建立模块，用于确定每个所述应用域和每个所述微应用的业务活动类型、访问流量和访问地域；基于所述访问流量和所述访问地域，采用分布式存储技术生成服务器架构模型，所述服务器架构模型用于表示物理服务器的地域分布和类型。

在上述实现方式中，基于应用域和微应用的具体访问情况，采用分布式存储技术进行分地域和流量的服务器架构模型构建，能够有效提高服务器对业务的处理效率，避免资源剩余或过于集中，基于分布式网络存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息的特点，不但提高了业务系统的可靠性、可用性和存取效率，还易于扩展。

可选地，所述业务系统构建装置还包括：安全架构模型建立模块，用于基于数据域和业务域的连接关系，以及所述物理服务器的地域分布确定所述至少一个应用域中每个应用域和所述至少一个数据域中每个数据域的边界性质；基于所述边界性质生成安全架构模型，所述安全架构模型用于表示是否对所述每个应用域或所述每个数据域设置防火墙、入侵检测设备、单向安全隔离装置。

在上述实现方式中，基于每个数据域的边界性质，更加适应业务需求地进行安全防控，采取防火墙、入侵检测设备、单向安全隔离装置等保障措施，实现不同安全区域及接入对象之间风险管控及安全监测，提高了业务系统的安全性。

可选地，所述数据映射技术包括Java数据库连接和/或对象关系映射。

在上述实现方式中，Java数据库连接在通信设备满足一定通信数据格式时即可通过软件进行通信，而该通信数据格式可以基于业务系统具体架构进行设定，从而使通信连接更适用于业务系统；此外，对象关系映射在业务系统中数据需要面向对象较多且不定时，更加方便使用多态的方式去处理不同实例的操作，能够提高业务系统的数据处理效率。

本申请实施例还提供了一种电子设备，所述电子设备包括存储器和处理器，所述存储器中存储有程序指令，所述处理器读取并运行所述程序指令时，执行上述任一实现方式中的步骤。

本申请实施例还提供了一种可读取存储介质，所述可读取存储介质中存储有计算机程序指令，所述计算机程序指令被一处理器读取并运行时，执行上述任一实现方式中的步骤。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种业务系统构建方法的流程示意图。

图2为本申请实施例提供的一种业务架构模型构建步骤的流程示意图。

图3为本申请提供的一种业务架构模型的模块示意图。

图4为本申请实施例提供的一种应用架构模型建立步骤的流程示意图。

图5为本申请实施例提供的一种数据字典获取步骤的流程示意图。

图6为本申请实施例提供的一种数据架构模型的部分模块示意图。

图7为本申请实施例提供的一种技术架构模型的模块示意图。

图8为本申请实施例提供的一种业务系统构建装置的模块示意图。

图标：20-业务系统构建装置；21－业务架构模型建立模块；22－应用架构模型建立模块；23－数据架构模型建立模块。

具体实施方式

下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行描述。

本申请实施例了一种业务系统构建方法，请参考图1，图1为本申请实施例提供的一种业务系统构建方法的流程示意图。该业务系统构建方法的具体步骤如下：

步骤S12：将指定业务对应的至少一个业务功能之间的逻辑结构抽象为业务架构模型，业务架构模型包括用于实现指定业务中各业务功能的至少一个功能域，功能域与业务功能一一对应。

具体地，请参考图2，图2为本申请实施例提供的一种业务架构模型构建步骤的流程示意图，步骤S12可以包括如下步骤：

步骤S121：确定指定业务对应的至少一个业务功能中每个业务功能的业务领域。

业务领域是企业中不同业务功能的核心价值链，通常和组织中部门的划分相似。以电力营销业务为例，客户服务与客户关系、电费管理作为业务领域分别对应客户服务中心和电费核算部门不同的组织部门。

步骤S122：基于业务领域确定每个业务功能的业务职能，业务职能为每个业务功能的至少一个相关业务能力。

业务职能是企业经营某个业务领域所具备的相关业务能力，通常和组织单元中处室的划分相似。例如电费管理功能域下的抄表管理、核算管理分别对应的处室为抄表部门、核算部门。

步骤S123：基于业务职能的至少一个业务活动以及至少一个业务活动之间的关联关系确定业务流程。

业务流程是业务职能下由不同的岗位协同完成的、由多个业务活动及其关联关系组成的价值链，例如电费管理功能域下抄表管理功能模块把抄表的结果数据传递给核算管理功能模块进行核算业务。

业务活动是业务流程中的流程节点，是业务流程得以实现的必备环节。业务流程中的业务活动(流程节点)之间不仅有严格的先后顺序限定，而且活动的内容、方式、责任等也都必须有明确的安排和界定，以使不同活动在不同角色之间进行交互。例如电费管理域中从抄表活动结束作为流程节点到核算活动开始，且两个活动有先后顺序。

步骤S124：基于业务领域、业务职能和业务流程确定至少一个业务功能之间的逻辑结构。

业务功能之间的逻辑关系则对应着功能域之间的逻辑关系。

步骤S125：将逻辑结构抽象为业务架构模型。

业务功能对应业务架构模型中的功能域，功能域则是基于不同业务领域的业务功能抽象获得，把功能域作为桥梁和其他架构设计相关联。具体地，针对上述业务架构模型建立步骤，本实施例中以电力营销业务为例，请参考图3，图3为本申请提供的一种业务架构模型的模块示意图，根据客服中心、电费核算部门、售电部门、计量部门等各业务部门的业务领域不同划分为客户服务与客户关系功能域、电费管理功能域、市场与需求侧功能域、电能计量及信息采集功能域、市场化售电功能域分别对应不同的业务功能。其中，综合管理功能域是各职能部门的业务数据形成的综合管理数据指标和监管指标数据，为各部门领导提供监管需求的功能域。

接下来再根据各部门具体工作角色的职责，进一步细分出功能模块，比如客户服务与客户关系功能域中的各个功能模块中，客服人员进行电话的话务处理对应功能模块为客服业务处理，进行业扩报装登记对应功能模块为新装、增容及变更用电功能等等。

本实施例通过对业务进行职能划分、流程梳理和最小业务单元拆解，并根据岗位职责和业务场景设计角色场景，形成一体化业务蓝图，建立业务场景基线，为指导微应用、微服务和数据架构模型设计提供业务依据，业务架构模型从业务角度对核心业务进行细化、抽象、归纳、总结，形成整体业务能力视图，为应用架构模型和数据架构模型提供关键输入。对于业务具有体量大、形态多、涉及广、很复杂等特点的公司，业务架构模型对于可研编制、评审、概设编制、评审、架构管控等工作具有很强的指导性，并且与实际工作形成“相互促进，共同提升”的关系。在实际工作中，如发现有与业务架构不符的情况，例如：超出范围、不遵从等，应通过业务部门及时上报，合理的差异会在后续的架构修编等工作中予以体现。

步骤S14：基于业务架构模型中的至少一个功能域的结构关系构建应用架构模型，应用架构模型包括用于用户设备处理至少一个功能域对应业务功能的至少一个应用域，功能域与应用域一一对应。

应用架构模型的设计目标是描述了公司信息系统功能和技术实现的内容，通过应用架构模型将承接企业战略发展方向和业务模式，指导企业各个IT系统的定位和功能，确保业务架构落地与避免技术设计复杂性。

应用架构模型设计思路是结合业务的同质化程度，流程化程度及耦合度进行划分，当分不合、当合不分。业务梳理需考虑流程类业务、非流程类业务，同时需要考虑新增业务需求。以业务流程拆解后的业务活动为颗粒度，作为最小业务活动，梳理出输入输出的数据对象。

具体地，请参考图4，图4为本申请实施例提供的一种应用架构模型建立步骤的流程示意图，其具体步骤可如下：

步骤S141：确定至少一个业务活动中每个业务活动对应的微应用，微应用用于调用至少一个微服务实现对应的业务活动。

微应用是通过调用一个或者多个微服务，实现一组同类型的或紧密耦合的单一业务目标或业务场景的功能逻辑组合软件包。本系统中例如电费管理功能域对应的抄表段管理微应用、抄表机管理微应用等。

其中，微服务是一个软件架构，就是把一个大型的单个应用程序和服务拆分为多个支持微服务。一个微服务的策略可以让工作变得更为简便，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。微服务的特点是单一职责的，一个微服务解决一个业务活动的业务问题，并且为面向服务的，继承面向服务的架构(Service－OrientedArchitecture，SOA)，即将自己的业务能力封装并对外提供服务。

步骤S142：将业务活动与业务功能的逻辑关系作为至少一个功能域的结构关系。

可选地，业务活动与业务功能的逻辑关系可以通过业务活动需要连接的功能域来确定，例如电费管理功能域下抄表管理功能模块把抄表的结果数据传递给核算管理功能模块进行核算业务，且电费管理功能域需要与综合管理功能域和市场化售电功能域等连接，则基于上述功能域及功能模块之间的连接关系可以确定对应的业务活动与业务功能的逻辑关系。

步骤S143：基于结构关系将微应用分别聚合形成与至少一个功能域一一对应的应用域。

其中，应用域是根据业务耦合程度聚合而成的高阶应用群(微应用群)，一般与业务领域有着紧密的对应关系，一个业务功能的业务领域下的业务活动对应的微应用往往具有较高的耦合度。可选地，业务耦合程度可以根据功能域及功能模块之间的连接关系确定。

本实施例以“服务化、组件化”为设计理念，全面梳理业务架构模型中各功能域、业务流程建立应用架构，使需求响应更敏捷、业务衔接更紧密、数据共享更充分、用户体验更友好。立足现有业务的设计成果，对原有业务的业务职能、场景等进行梳理、归并。同时对业务的未来发展进行展望规划，根据微应用、微服务的特点，设计形成一整套业务的应用解决方案。

步骤S16：获取至少一个功能域中每个功能域的数据字典，基于数据字典建立数据架构模型，数据架构模型包括用于存储实体对象与功能域之间的业务关系和业务数据的至少一个数据域，功能域与数据域一一对应，每个数据域与对应的应用域通过对应的功能域基于数据映射技术进行连接。

本实施例中为了持久化数据，应用架构模型通过数据层和数据库建立连接，本实施例从业务架构模型的功能模块中梳理各功能模块对应的实体对象关系进行数据架构模型的规划。本系统的数据架构模型是遵循企业级统一信息模型的设计思路，按照全业务统一数据中心统一规划，标准先行的建设思路，围绕业务架构中的各业务域，开展统一信息模型设计，实现数据统一管理，构建企业级的统一的信息模型。具体而言，根据业务架构模型中各功能域之间的关系和处理流程形成逻辑视图，结合逻辑视图和实体关系图(对业务架构模型中的实体进行关系描述的图，例如库存管理业务的业务架构模型中实体指的是库房，资产、资料等实体，实体关系图指的是这些实体类之间的关系描述)表现系统数据域的数据对象及相互逻辑关系。

具体地，请参考图5，图5为本申请实施例提供的一种数据字典获取步骤的流程示意图，其具体步骤可以如下：

步骤S161：确定至少一个功能域中每个功能域的实体对象、对象属性和业务活动。

数据字典是指对数据的数据项、数据结构、数据流、数据存储、处理逻辑等进行定义和描述，其目的是对数据流程图中的各个元素做出详细的说明，使用数据字典为简单的建模项目。简而言之，数据字典是描述数据的信息集合，是对系统中使用的所有数据元素的定义的集合。具体地，分析一个用户交换的对象系统的第一步就是去辨别每一个对象，以及它与其他对象之间的关系。这个过程称为数据建模，结果产生一个对象关系图。当每个数据对象和项目都给出了一个描述性的名字之后，它的关系再进行描述(或者是成为潜在描述关系的结构中的一部分)，然后再描述数据的类型(例如文本还是图像，或者是二进制数值)，列出所有可能预先定义的数值，以及提供简单的文字性描述。这个集合被组织成书的形式用来参考，就叫做数据字典。

步骤S162：基于实体对象、对象属性和业务活动确定每个功能域的数据项、数据结构、数据流、数据存储和/或处理逻辑。

其中，数据项是数据流图中数据块的数据结构中的数据项说明；数据结构是数据流图中数据块的数据结构说明，反映了数据之间的组合关系；数据流是数据流图中流线的说明，是数据结构在系统内传输的路径；数据存储是数据流图中数据块的存储特性说明，数据存储是数据结构停留或保存的地方，也是数据流的来源和去向之一；处理过程是数据流图中功能块的说明，数据字典中只需要描述处理过程的说明性信息。

步骤S163：基于数据项、数据结构、数据流、数据存储和/或处理逻辑生成每个功能域的数据字典。

作为一种可选的实施方式，本实施例基于大数据、云计算等新技术，采用PB(存储空间单位，等于100万GB)级数据统一存储与管理、跨地域分布式计算、基础软硬件资源弹性扩展为建设全业务统一数据架构模型提供技术保障。

可选地，本实施例中的数据架构模型根据各个数据域对应的应用域所处理的流量地域分布，还可以采用分布式存储技术，将不同省公司、市公司的数据库分别设置。分布式存储是一种数据存储技术，通过网络使用企业中的每台机器上的磁盘空间，并将这些分散的存储资源构成一个虚拟的存储设备，数据分散的存储在企业的各个角落。传统的网络存储系统采用集中的存储服务器存放所有数据，存储服务器成为系统性能的瓶颈，也是可靠性和安全性的焦点，不能满足大规模存储应用的需要。分布式网络存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。

具体地，数据架构模型可以包含数据处理域、数据分析域和数据管理域三部分。

数据管理域是实现数据规范、统一、安全的关键和保障。其主要包括统一数据模型和主数据管理体系，通过在处理域和分析域应用数据模型和主数据，确保数据一致，打破专业间信息壁垒，实现企业数据模型统一，通过数据管理和主数据管理两个支撑组件实现设计成果在处理域和分析域的应用落地。

数据分析域是挖掘数据资源价值，提升数据应用水平的核心。是全业务、全类型、全时间维度数据的汇聚中心，为各类分析应用提供统一的大数据分析计算能力和数据服务。通过在分析域统一构建分析应用，改变过去“反复抽取、冗余存储”的现象，促进跨专业大数据价值挖掘。

处理域是保障数据质量的关键，提升数据应用水平的基础。其是公司生产经营管理数据产生的源头，为各类业务应用提供统一的平台处理能力和集成服务。通过在处理域以服务方式统一支撑业务集成，改变过去“反复抽取、多头输入”的现象，推进源端数据逻辑一致、分布合理、实时有效。

其中，数据架构模型中的数据层和应用架构模型中的业务逻辑层可以基于Java数据库连接和/或对象关系映射进行连接。

Java数据库连接(Java Database Connectivity，JDBC)是连接Java应用程序和数据库之间的桥梁，其为接口形式即Java数据库编程接口，是一组标准的Java语言中的接口和类，使用这些接口和类，Java客户端程序可以访问各种不同类型的数据库。比如建立数据库连接、执行SQL语句进行数据的存取操作。JDBC在通信设备满足一定通信数据格式时即可通过软件进行通信，而该通信数据格式可以基于业务系统具体架构进行设定，从而使通信连接更适用于业务系统。

对象关系映射(Object Relational Mapping，ORM)是一种为了解决面向对象与关系数据库存在的互不匹配的现象的技术。简单的说，ORM是通过使用描述对象和数据库之间映射的元数据，将程序中的对象自动持久化到关系数据库中。本质上就是将数据从一种形式转换到另外一种形式。其能够方便地使用面向对象，语句清晰，并且在业务架构模型对象不确定的时候，使用多态的方式去处理不同实例的相同操作。

业务层通过JDBC或O/R Mapping把对数据的操作持久化到数据层中，从数据层查询数据返回给业务逻辑层或是业务逻辑层根据业务逻辑修改、新增数据到数据层存储数据或删除数据；根据业务层处理的数据形式及业务模式的不同，数据源对应有存储数据、实时数据、统计数据。达到业务逻辑层的业务需求变化不影响数据层的数据运行。基础架构层为数据层提供硬件支撑，通过数据库服务器对数据进行存储和备份。

具体地，请参考图6，图6为本申请实施例提供的一种数据架构模型的部分模块示意图。其中，还是以电力营销业务为例，包括公司总部营销业务应用数据、省公司的营销业务应用数据和营销分析与辅助决策应用数据、地市公司的营销数据以及相关数据。营销业务应用数据、营销分析与辅助决策应用数据和营销数据以及相关数据中的数据划分根据上述数据字典中表示的实体与业务的关系进行完成，具体如图6所示，在此不再进行赘述。

本实施例以业务为驱动，采用“自上而下”和“自下而上”相结合的设计方式，完成全业务统一数据架构模型设计，通过构建全业务结构化数据的企业数据仓库，解决全业务数据的接入与汇聚问题；构建统一存储服务，实现数据的统一存储和管理，满足业务处理应用与分析类应用的使用需求，解决数据多份复制，冗余存储问题；构建统一分析服务，提供跨域分布式计算能力，支撑分析类应用的统一构建，解决分散重复建设的问题。

本实施例还可以根据业务架构模型选择适合业务特点的技术架构模型，比如根据业务架构模型中的功能域在技术架构客户层用哪种客户端进行展示，根据业务架构模型中的业务场景在技术架构业务逻辑层划分业务服务功能域等。

本实施例中的技术架构模型的设计目标是制定公司信息系统建设技术路线，通过技术架构模型设计将应用架构模型和数据架构模型中所需要的技术能力映射为相应的技术组件，为公司信息系统建设提供技术指导。具体地，技术架构模型可以从技术框架视图和集成方式视图两个层面理解。

技术框架视图主要描述公共技术域，明确每一个技术域具备的技术能力，由云基础设施、云平台服务、全业务数据服务、公共应用支撑、访问渠道、安全防护和运行维护等技术域构成。其中云基础设施是为公司信息系统提供基础支撑能力；云平台服务是为公司实现应用上云提供能力支撑；全业务数据服务是为公司提供全量数据存储、计算、交换、管理等能力；公共应用支撑是对公司所需的公共支撑服务进行梳理，实现基础应用的高效共享应用；访问渠道是为公司员工访问公司信息系统或者业务应用提供基本通道；安全防护是为公司信息系统的安全运行提供基础保障；运行维护是对信息系统健康运行所需的管理手段以及技术手段进行梳理，设计调度管理、运行监控、运维服务等组件。

集成方式视图主要描述各个业务的应用域之间通过中间件或者接口服务，实现系统之间或者模块之间数据与能力的调用与交互，达到系统之间信息互联共享的一种技术实现框架，包含服务集成、数据集成和界面集成模式。服务集成是支撑应用集成的技术组件包括企业级服务总线、分布式服务总线、即时消息总线、统一流程管理组件；数据交换的重点应用于处理域产生的数据传输至分析域，包括数据复制、服务总线、文件传输；界面集成主要用于实现系统的访问渠道，将不同应用的界面集成在同一个访问渠道，主要技术分为基于iFrame(一种HTML标签)界面集成和基于URL(Uniform Resource Locator，统一资源定位符)链接集成。

请参考图7，图7为本申请实施例提供的一种技术架构模型的模块示意图，其大致可以划分为客户层、界面控制层、业务逻辑层、数据层和基础架构，各部分具体细节如图所示，在此不再赘述。

本实施例还可以基于应用架构模型中每个应用域和每个微应用的业务活动类型、访问流量和访问地域来确定物理服务器的服务器架构模型，其具体步骤可以包括：确定每个应用域和每个微应用的业务活动类型、访问流量和访问地域；基于访问流量和访问地域，采用分布式存储技术生成服务器架构模型，服务器架构模型用于表示物理服务器的地域分布和类型。

进一步地，根据应用架构模型中的功能域的业务性质、业务处理复杂度及业务使用频率，服务器架构模型规划时需要相应规划应用服务器及数据库服务器的数量。例如在应用架构模型中的电费模块处理计费算法时业务复杂且使用频率高，则在服务器架构模型中规划出高性能的计费服务器，单独为电费计费计算使用，分担服务器运行压力；根据功能域的连续性，服务器架构模型相应考虑是否需要负载均衡服务器部署多个节点，当一个服务器出现异常时功能请求可以分流到其他的服务器继续运行，例如支付业务需要保持业务的连续性，相应的服务器架构模型需要对应部署负载均衡服务器。

同时，物理架构模型还可以根据技术架构模型的客户端展现方式的不同，服务器架构模型规划时需要相应的考虑规划出不同的网络区域。例如当技术架构模型的客户端展现同时存在内网PC机、互联网的手机、互联网终端等多种形式时，服务器架构模型就要相应的规划出内网区和互联网专区。内网核心业务在内网环境下运行，与互联网专区通过网闸和防火墙隔离，有效阻断网络攻击。

针对数据架构模型，根据省公司和地市公司的区域划分成不同的数据库，在服务器架构模型中就要相应规划对应的数据库服务器。根据数据架构模型中实时数据和统计数据的划分，可以建立实时运算的运行库和只读取的数据中心库，服务器架构模型相应的就要规划运行数据库服务器和只读数据库服务器。

此外，本实施例还可以采用安全架构模型提高整体的系统安全性，其具体步骤可以如下：基于数据域和业务域的连接关系，以及物理服务器的地域分布确定至少一个应用域中每个应用域和至少一个数据域中每个数据域的边界性质；基于边界性质生成安全架构模型，安全架构模型用于表示是否对每个应用域或每个数据域设置防火墙、入侵检测设备、单向安全隔离装置。

进一步地，安全架构模型的网络安全技术标准包括：(1)制定物理与环境安全具体指机房位置、温湿度、防火防水等基础物理及环境安全标准规范；(2)通信安全关注网络运行的架构、冗余、路由、隔离等规范；(3)网络设备安全关注设备的性能、缺陷等规范；(4)主机与终端安全是网络接入、操作系统、防病毒等规定；(5)应用与数据安全是安全漏洞、代码规范、数据存储等规定。

因此，安全架构模型从“物理与环境、边界、网络与通信、主机、终端、应用、数据”等七个方面，利用安全隔离、入侵检测、主机加固、访问控制、安全审计等安全措施，实现管理信息系统各环节的技术安全防护。根据不同的边界性质，采取防火墙、入侵检测设备、单向安全隔离装置等保障措施，实现不同安全区域及接入对象之间风险管控及安全监测；采用无线APN公网或者电力无线专网接入网络。无线接入方式下设立安全接入区，并重点采用安全隔离、访问控制、认证及加密等措施。

可选地，本实施中还可以采用应用集成手段进行应用架构模型、数据架构模型、业务架构模型、技术架构模型和安全架构模型的集成，应用集成就是建立一个统一的综合应用，是将截然不同的、基于各种不同平台、用不同方案建立的应用软件和系统有机地集成到一个无缝的、并列的、易于访问的单一系统中，并使它们就像一个整体一样，进行业务处理和信息共享。

为了配合上述业务系统构建方法，本申请实施例还提供了一种业务系统构建装置20。

请参考图8，图8为本申请实施例提供的一种业务系统构建装置的模块示意图。

业务系统构建装置20包括：

业务架构模型建立模块21，用于指定业务对应的至少一个业务功能之间的逻辑结构抽象为业务架构模型，业务架构模型包括用于实现指定业务中各业务功能的至少一个功能域，功能域与业务功能一一对应；

应用架构模型建立模块22，用于基于业务架构模型中的至少一个功能域的结构关系构建应用架构模型，应用架构模型包括用于用户设备处理至少一个功能域对应业务功能的至少一个应用域，功能域与应用域一一对应；

数据架构模型建立模块23，用于获取至少一个功能域中每个功能域的数据字典，基于数据字典建立数据架构模型，数据架构模型包括用于存储实体对象与功能域之间的业务关系和业务数据的至少一个数据域，功能域与数据域一一对应，每个数据域与对应的应用域通过对应的功能域基于数据映射技术进行连接。

可选地，业务架构模型建立模块21具体用于：确定指定业务对应的至少一个业务功能中每个业务功能的业务领域基于业务领域确定每个业务功能的业务职能，业务职能为每个业务功能的至少一个相关业务能力；基于业务职能的至少一个业务活动以及至少一个业务活动之间的关联关系确定业务流程；基于业务领域、业务职能和业务流程确定至少一个业务功能之间的逻辑结构；将逻辑结构抽象为业务架构模型。

可选地，应用架构模型建立模块22具体用于：确定所述至少一个业务活动中每个业务活动对应的微应用，微应用用于调用至少一个微服务实现对应的业务活动；将业务活动与业务功能的逻辑关系作为至少一个功能域的结构关系；基于结构关系将微应用分别聚合形成与至少一个功能域一一对应的应用域。

可选地，数据架构模型建立模块23具体用于：确定至少一个功能域中每个功能域的实体对象、对象属性和业务活动；基于实体对象、对象属性和业务活动确定每个功能域的数据项、数据结构、数据流、数据存储和/或处理逻辑；基于数据项、数据结构、数据流、数据存储和/或处理逻辑生成每个功能域的数据字典。

可选地，业务系统构建装置20还包括：服务器架构模型建立模块，用于确定每个应用域和每个微应用的业务活动类型、访问流量和访问地域；基于访问流量和访问地域，采用分布式存储技术生成服务器架构模型，服务器架构模型用于表示物理服务器的地域分布和类型。

可选地，业务系统构建装置20还包括：安全架构模型建立模块，用于基于数据域和业务域的连接关系，以及物理服务器的地域分布确定至少一个应用域中每个应用域和至少一个数据域中每个数据域的边界性质；基于边界性质生成安全架构模型，安全架构模型用于表示是否对每个应用域或每个数据域设置防火墙、入侵检测设备、单向安全隔离装置。

可选地，数据映射技术包括Java数据库连接和/或对象关系映射。

本申请实施例还提供了一种电子设备，该电子设备包括存储器和处理器，所述存储器中存储有程序指令，所述处理器读取并运行所述程序指令时，执行本实施例提供的业务系统构建方法中任一项所述方法中的步骤。

应当理解是，该电子设备可以是个人电脑(Personal Computer，PC)、平板电脑、智能手机、个人数字助理(Personal Digital Assistant，PDA)等具有逻辑计算功能的电子设备。

本申请实施例还提供了一种可读取存储介质，所述可读取存储介质中存储有计算机程序指令，所述计算机程序指令被一处理器读取并运行时，执行业务系统构建方法中的步骤。

综上所述，本申请实施例提供了一种业务系统构建方法、装置、电子设备及存储介质，所述方法包括：将指定业务对应的至少一个业务功能之间的逻辑结构抽象为业务架构模型，所述业务架构模型包括用于实现所述指定业务中各业务功能的至少一个功能域，功能域与业务功能一一对应；基于所述业务架构模型中的所述至少一个功能域的结构关系构建应用架构模型，所述应用架构模型包括用于用户设备处理所述至少一个功能域对应业务功能的至少一个应用域，功能域与应用域一一对应；获取所述至少一个功能域中每个功能域的数据字典，基于所述数据字典建立数据架构模型，所述数据架构模型包括用于存储实体对象与功能域之间的业务关系和业务数据的至少一个数据域，功能域与数据域一一对应，每个数据域与对应的应用域通过对应的功能域基于数据映射技术进行连接。

在上述实现方式中，关联建立业务架构模型、应用架构模型和数据架构模型，提高了业务、数据和应用之间的关联性，以提高业务的可管理性，以业务架构模型中的功能域为对应基础，采用数据映射技术连接数据域和应用域，并结合统一的数据架构模型进行数据的统一存储和管理，解决了数据冗杂问题，满足了业务处理应用和分析类应用的使用需求，从而提高了业务处理效率。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的框图显示了根据本申请的多个实施例的设备的可能实现的体系架构、功能和操作。在这点上，框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图中的每个方框、以及框图的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。因此本实施例还提供了一种可读取存储介质中存储有计算机程序指令，所述计算机程序指令被一处理器读取并运行时，执行区块数据存储方法中任一项所述方法中的步骤。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，RanDom Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (7)

1.一种业务系统构建方法，其特征在于，所述方法包括：

将指定业务对应的至少一个业务功能之间的逻辑结构抽象为业务架构模型，所述业务架构模型包括用于实现所述指定业务中各业务功能的至少一个功能域，功能域与业务功能一一对应；

基于所述业务架构模型中的所述至少一个功能域的结构关系构建应用架构模型，所述应用架构模型包括用于用户设备处理所述至少一个功能域对应业务功能的至少一个应用域，功能域与应用域一一对应；

获取所述至少一个功能域中每个功能域的数据字典，基于所述数据字典建立数据架构模型，所述数据架构模型包括用于存储实体对象与功能域之间的业务关系和业务数据的至少一个数据域，功能域与数据域一一对应，每个数据域与对应的应用域通过对应的功能域基于数据映射技术进行连接；

所述获取所述至少一个功能域中每个功能域的数据字典，包括：

确定所述至少一个功能域中每个功能域的实体对象、对象属性和业务活动；

基于所述实体对象、所述对象属性和所述业务活动确定所述每个功能域的数据项、数据结构、数据流、数据存储和/或处理逻辑；

基于所述数据项、所述数据结构、所述数据流、所述数据存储和/或所述处理逻辑生成所述每个功能域的所述数据字典；

所述将指定业务对应的至少一个业务功能之间的逻辑结构抽象为业务架构模型，包括：

确定所述指定业务对应的所述至少一个业务功能中每个业务功能的业务领域；

基于所述业务领域确定所述每个业务功能的业务职能，所述业务职能为所述每个业务功能的至少一个相关业务能力；

基于所述业务职能的至少一个业务活动以及所述至少一个业务活动之间的关联关系确定业务流程；

基于所述业务领域、所述业务职能和所述业务流程确定所述至少一个业务功能之间的逻辑结构；

将所述逻辑结构抽象为所述业务架构模型；

所述基于所述业务架构模型中的所述至少一个功能域的结构关系构建应用架构模型，包括：

确定所述至少一个业务活动中每个业务活动对应的微应用，所述微应用用于调用至少一个微服务实现对应的业务活动；

将业务活动与业务功能的逻辑关系作为所述至少一个功能域的结构关系；

基于所述结构关系将所述微应用分别聚合形成与所述至少一个功能域一一对应的应用域。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

确定每个所述应用域和每个所述微应用的业务活动类型、访问流量和访问地域；

基于所述访问流量和所述访问地域，采用分布式存储技术生成服务器架构模型，所述服务器架构模型用于表示物理服务器的地域分布和类型。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

基于数据域和业务域的连接关系，以及所述物理服务器的地域分布确定所述至少一个应用域中每个应用域和所述至少一个数据域中每个数据域的边界性质；其中，数据域和业务域的连接关系的获取，包括：根据数据域和功能域之间的关系，和功能域与业务域之间的关系得到；

基于所述边界性质生成安全架构模型，所述安全架构模型用于表示是否对所述每个应用域或所述每个数据域设置防火墙、入侵检测设备、单向安全隔离装置。

4.根据权利要求1-3中任一项所述的方法，其特征在于，所述数据映射技术包括Java数据库连接和/或对象关系映射。

5.一种业务系统构建装置，其特征在于，所述装置包括：

业务架构模型建立模块，用于指定业务对应的至少一个业务功能之间的逻辑结构抽象为业务架构模型，所述业务架构模型包括用于实现所述指定业务中各业务功能的至少一个功能域，功能域与业务功能一一对应；所述将指定业务对应的至少一个业务功能之间的逻辑结构抽象为业务架构模型，包括：

确定所述指定业务对应的所述至少一个业务功能中每个业务功能的业务领域；

基于所述业务领域确定所述每个业务功能的业务职能，所述业务职能为所述每个业务功能的至少一个相关业务能力；

基于所述业务职能的至少一个业务活动以及所述至少一个业务活动之间的关联关系确定业务流程；

基于所述业务领域、所述业务职能和所述业务流程确定所述至少一个业务功能之间的逻辑结构；

将所述逻辑结构抽象为所述业务架构模型；

应用架构模型建立模块，用于基于所述业务架构模型中的所述至少一个功能域的结构关系构建应用架构模型，所述应用架构模型包括用于用户设备处理所述至少一个功能域对应业务功能的至少一个应用域，功能域与应用域一一对应；所述基于所述业务架构模型中的所述至少一个功能域的结构关系构建应用架构模型，包括：

确定所述至少一个业务活动中每个业务活动对应的微应用，所述微应用用于调用至少一个微服务实现对应的业务活动；

将业务活动与业务功能的逻辑关系作为所述至少一个功能域的结构关系；

基于所述结构关系将所述微应用分别聚合形成与所述至少一个功能域一一对应的应用域；

数据架构模型建立模块，用于获取所述至少一个功能域中每个功能域的数据字典，基于所述数据字典建立数据架构模型，所述数据架构模型包括用于存储实体对象与功能域之间的业务关系和业务数据的至少一个数据域，功能域与数据域一一对应，每个数据域与对应的应用域通过对应的功能域基于数据映射技术进行连接；所述获取所述至少一个功能域中每个功能域的数据字典，包括：确定所述至少一个功能域中每个功能域的实体对象、对象属性和业务活动；基于所述实体对象、所述对象属性和所述业务活动确定所述每个功能域的数据项、数据结构、数据流、数据存储和/或处理逻辑；基于所述数据项、所述数据结构、所述数据流、所述数据存储和/或所述处理逻辑生成所述每个功能域的所述数据字典。

6.一种电子设备，其特征在于，所述电子设备包括存储器和处理器，所述存储器中存储有程序指令，所述处理器运行所述程序指令时，执行权利要求1-4中任一项所述方法中的步骤。

7.一种存储介质，其特征在于，所述存储介质中存储有计算机程序指令，所述计算机程序指令被一处理器运行时，执行权利要求1-4任一项所述方法中的步骤。