CN110533406B - 一种支付调用方法、装置及系统 - Google Patents

Abstract

本说明书实施例公开了一种支付调用方法、装置及系统。所述方法包括接收调用方发送的支付请求；根据所述支付请求和配置字典生成支付调用构件，所述支付调用构件包括业务规则，所述业务规则用来实现与所述支付调用构件对应的业务逻辑；基于所述支付调用构件对预先构建的支付实体充血模型中包括的支付构件进行调用，获得调用结果，所述支付实体充血模型包括实体数据结构和业务逻辑层，所述业务逻辑层包括支付构件；将所述调用结果发送给调用方。利用本说明书实施例可以在降低系统复杂性的同时，提高系统的可维护性。

Description

一种支付调用方法、装置及系统

技术领域

本说明书实施例方案属于应用开发领域，尤其涉及一种支付调用方法、装置及系统。

背景技术

随着金融科技、互联网金融的不断发展、创新、衍变，新型支付模式如扫码支付、NFC支付(Near Field Communication，近距离无线通讯)、手机收款、无卡取现、刷脸支付层出不穷，这导致金融支付体系越来越复杂。

目前，金融支付体系的使用者(如商户、政府机构)，在使用金融服务时，往往不会只使用其中一种服务。例如，商户扫码支付场景下，系统的开发人员需要对接多种支付能力提供方(如银行、第三方支付机构等)，而且实际支付时支付介质也各有不同(如账户、卡、手机号码等)。由于不同支付服务接口差异很大，开发人员要为每一个服务接口单独写一套程序对接，这样不仅同时涉及处理大量复杂数据，而且必须适配很多各不相同的业务规则，导致系统代码冗余度高，不易维护。

因此，业内亟需一种可以降低系统复杂性的解决方案。

发明内容

本说明书实施例在于提供一种支付调用方法、装置及系统，通过领域建模，将原来分散在业务处理流程各出的核心逻辑内聚到充血模型，从而可以在降低系统复杂性的同时，提高系统的可维护性。

本说明书提供的支付调用方法、装置、设备及系统是包括以下方式实现的：

一种支付调用方法，包括：

接收调用方发送的支付请求；

根据所述支付请求和配置字典生成支付调用构件，所述支付调用构件包括业务规则，所述业务规则用来实现与所述支付调用构件对应的业务逻辑；

基于所述支付调用构件对预先构建的支付实体充血模型中包括的支付构件进行调用，获得调用结果，所述支付实体充血模型包括实体数据结构和业务逻辑层，所述业务逻辑层包括支付构件；

将所述调用结果发送给调用方。

本说明书提供的所述方法的另一个实施例中，所述预先构建的支付实体充血模型包括采用下述方式得到：

获取功能相同的支付服务；

提取所述支付服务中的业务逻辑；

将功能相同的业务逻辑等效为支付构件，所述支付构件包括标准化构件、支付元素注入构件、支付校验构件、持久化构件、支付幂等构件、支付路由生成构件、支付接口调用构件；

基于领域驱动设计构建支付实体充血模型，所述支付实体充血模型包括实体数据结构和业务逻辑层，所述业务逻辑层包括支付构件。

本说明书提供的所述方法的另一个实施例中，所述支付实体充血模型中，每个支付构件包括预设个业务规则，所述业务规则对应不同提供方、不同支付介质、不同支付接口。

本说明书提供的所述方法的另一个实施例中，所述基于所述支付调用构件对预先构建的支付实体充血模型中包括的支付构件进行调用，获得调用结果，包括：

对所述支付实体充血模型进行初始化处理，获得初始化充血模型；

将所述支付调用构件注入到所述初始化充血模型中；

调用所述初始化充血模型包括的支付构件。

本说明书提供的所述方法的另一个实施例中，还包括：

当所述支付实体充血模型中不存在满足所述支付请求的第一支付构件时，将所述第一支付构件添加到所述支付实体充血模型中。

本说明书提供的所述方法的另一个实施例中，还包括：

当所述支付实体充血模型中存在满足所述支付请求的第一支付构件，且所述第一支付构件包括的预设个业务规则中不存在满足所述支付请求的第一业务规则时，将所述第一业务规则添加到所述第一支付构件包括的业务规则中。

一种支付调用装置，所述装置包括：

接收模块，用于接收调用方发送的支付请求；

生成模块，用于根据所述支付请求和配置字典生成支付调用构件，所述支付调用构件包括业务规则，所述业务规则用来实现与所述支付调用构件对应的业务逻辑；

调用模块，用于基于所述支付调用构件对预先构建的支付实体充血模型中包括的支付构件进行调用，获得调用结果，所述支付实体充血模型包括实体数据结构和业务逻辑层，所述业务逻辑层包括支付构件；

发送模块，用于将所述调用结果发送给调用方。

本说明书提供的所述装置的另一个实施例中，所述预先构建的支付实体充血模型包括：

获取模块，用于获取功能相同的支付服务；

提取模块，用于提取所述支付服务中的业务逻辑；

等效模块，用于将功能相同的业务逻辑等效为支付构件，所述支付构件包括标准化构件、支付元素注入构件、支付校验构件、持久化构件、支付幂等构件、支付路由生成构件、支付接口调用构件；

构建模块，用于基于领域驱动设计构建支付实体充血模型，所述支付实体充血模型包括实体数据结构和业务逻辑层，所述业务逻辑层包括支付构件。

本说明书提供的所述装置的另一个实施例中，所述支付构件中，

所述标准化构件用于实现请求报文到充血模型的转换，还用于实现支付信息的初始化；

所述支付元素注入构件用于预先将生成规则保存到数据库中，所述生成规则用于生成标识当前交易的随机序列号码；

所述支付校验构件用于实现支付过程中的数据检查；

所述持久化构件用于提供标准的数据库操作模板，所述操作模板用于完成数据操作；

所述支付幂等构件用于根据配置字典记录的幂等规则，在幂等处理过程中，将幂等逻辑和字段分离；

所述支付路由生成构件用于自动判断支付请求需要调用的接口；

所述支付接口调用构件用于读取所述支付路由生成构件提供的待调用接口信息，根据所述待调用接口信息调用对应的接口，还用于解析调用接口返回的报文，生成预设格式的结果发送给调用方。

本说明书提供的所述装置的另一个实施例中，所述调用模块，包括：

初始化单元，用于对所述支付实体充血模型进行初始化处理，获得初始化充血模型；

注入单元，用于将所述支付调用构件注入到所述初始化充血模型中；

调用单元，用于调用所述初始化充血模型包括的支付构件。

本说明书提供的所述装置的另一个实施例中，还包括：

第一添加模块，用于当所述支付实体充血模型中不存在满足所述支付请求的第一支付构件时，将所述第一支付构件添加到所述支付实体充血模型中。

本说明书提供的所述装置的另一个实施例中，还包括：

第二添加模块，用于当所述支付实体充血模型中存在满足所述支付请求的第一支付构件，且所述第一支付构件包括的预设个业务规则中不存在满足所述支付请求的第一业务规则时，将所述第一业务规则添加到所述第一支付构件包括的业务规则中。

一种支付调用设备，包括处理器及用于存储处理器可执行指令的存储器，所述指令被所述处理器执行时实现包括以下步骤：

接收调用方发送的支付请求；

根据所述支付请求和配置字典生成支付调用构件，所述支付调用构件包括业务规则，所述业务规则用来实现与所述支付调用构件对应的业务逻辑；

基于所述支付调用构件对预先构建的支付实体充血模型中包括的支付构件进行调用，获得调用结果，所述支付实体充血模型包括实体数据结构和业务逻辑层，所述业务逻辑层包括支付构件；

将所述调用结果发送给调用方。

一种支付调用系统，包括至少一个处理器以及存储计算机可执行指令的存储器，所述处理器执行所述指令时实现本说明书实施例中任意一个方法实施例方法的步骤。

本说明书实施例提供的一种支付调用方法、装置及系统。一些实施例中可以通过将复杂支付流程中的业务逻辑抽象成若干个支付构件，从而将具有各异性的支付流程转换为对支付构件的模式化编排，可以有效指导软件开发人员在开发流程中将重点放在系统的核心业务领域，即支付构件的实现上。通过采用领域驱动设计构建支付实体充血模型，将原来分散在业务处理流程各处的核心逻辑内聚到充血模型本身，可以极大降低软件系统的复杂性，提高软件系统的可维护性、可扩展性。利用本说明书的一些实施例，可以在降低系统复杂性的同时，提高系统的可维护性、可扩展性。

附图说明

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

图1是本说明书提供的一种支付调用方法的一个实施例的流程示意图；

图2是本说明书提供的账单充血模型及其实体数据结构和逻辑业务层的一个实施例的示意图；

图3是本说明书提供的支付实体充血模型构建方法一个实施例的流程示意图；

图4是本说明书提供的一种支付调用方法的一个具体实施例的示意图；

图5是本说明书提供的一种支付调用装置的一个实施例的模块结构示意图；

图6是本说明书提供的一种支付调用服务器的一个实施例的硬件结构框图。

具体实施方式

为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述。下述所描述的实施例仅仅是本说明书中的一部分实施例，而不是全部的实施例。基于本说明书中的一个或多个实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本说明书实施例保护的范围。

随着金融科技、互联网金融的不断发展、创新、衍变，新型支付模式如扫码支付、NFC支付、手机收款、无卡取现、刷脸支付层出不穷，这导致金融支付体系越来越复杂。目前，金融支付体系的使用者在使用金融服务时，往往不会只使用其中一种服务。由于不同支付服务接口差异很大，开发人员要为每一个服务接口单独写一套程序对接，这样不仅同时涉及处理大量复杂数据，而且必须适配很多各不相同的业务规则，导致系统代码冗余度高，不易维护。

本说明书实施例提供了一种支付调用方法，通过将复杂支付流程中的业务逻辑抽象成若干个支付构件，从而将具有各异性的支付流程转换为对支付构件的模式化编排，可以有效指导软件开发人员在开发流程中将重点放在系统的核心业务领域，即支付构件的实现上。通过采用领域驱动设计构建支付实体充血模型，将原来分散在业务处理流程各处的核心逻辑内聚到充血模型本身，可以极大降低软件系统的复杂性，提高软件系统的可维护性、可扩展性。因此，利用本说明书各个实施例，可以在降低系统复杂性的同时，提高系统的可维护性、可扩展性。

领域驱动设计(Domain Driven Design，DDD)是一套完整而系统的设计方法，尤其善于处理与领域相关的具有高复杂度业务特性的产品研发。领域驱动设计分为两个阶段：第一阶段是以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具，在交流的过程中发现领域概念，然后将这些概念设计成一个领域模型；第二阶段是由领域模型驱动软件设计，用代码实现领域模型。例如，软件开发前，通常需要进行大量的业务知识梳理，而后到达软件设计的层面，最后才是开发，而在业务知识梳理的过程中，必然会形成某个领域知识，根据领域知识来一步步驱动软件设计，就是领域驱动设计的基本概念。可见，领域驱动设计的核心在于建立正确的领域模型。

贫血模型和充血模型是领域模型中两个较为重要的概念。贫血模型是一种传统的领域模型设计方案，它是指使用的领域对象是简单的Java对象，其中只有一些属性和简单的setter和getter方法，也称作POJO((Plain Ordinary Java Object，简单的Java对象)或VO(Value Object，值对象)。由于所有的业务逻辑都不包含在领域对象中，在实现业务功能时，只能由过程驱动，即由过程方法“操作”POJO对象完成业务逻辑。随着业务逻辑复杂性增加，系统的复杂性将迅速增加，程序结构也变得极度混乱。充血模型是贫血模型的反面，充血模型将大多数业务逻辑放在领域对象中，可以同时完成对业务逻辑的封装处理，从而体现出面向对象设计的本质：“一个对象同时拥有状态和行为”。这样，通过该领域对象可以为系统建立一个核心的领域模型，该领域模型聚焦于为用户提供解决业务场景下核心问题的能力。

下面以一个具体的应用场景为例对本说明书实施方案进行说明。具体的，图1是本说明书提供的一种支付调用方法的一个实施例的流程示意图。虽然本说明书提供了如下述实施例或附图所示的方法操作步骤或装置结构，但基于常规或者无需创造性的劳动在所述方法或装置中可以包括更多或者部分合并后更少的操作步骤或模块单元。在逻辑性上不存在必要因果关系的步骤或结构中，这些步骤的执行顺序或装置的模块结构不限于本说明书实施例或附图所示的执行顺序或模块结构。所述的方法或模块结构的在实际中的装置、服务器或终端产品应用时，可以按照实施例或者附图所示的方法或模块结构进行顺序执行或者并行执行(例如并行处理器或者多线程处理的环境、甚至包括分布式处理、服务器集群的实施环境)。

需要说明的是，下述实施例描述并不对基于本说明书的其他可扩展到的应用场景中的技术方案构成限制。具体的一种实施例如图1所示，本说明书提供的一种支付调用方法的一种实施例中，所述方法可以包括：

S10：接收调用方发送的支付请求。

所述支付请求中可以包括请求报文、服务类型等。所述请求报文可以包括请求行、请求头部、空行和请求数据。调用方可以包括向支付系统发送支付请求的一方。

本说明书提供的一个实施例中，调用方需要完成支付服务时，可以向支付系统发起支付请求，支付系统在接收到支付请求后可以进行相应处理。

S12：根据所述支付请求和配置字典生成支付调用构件，所述支付调用构件包括业务规则，所述业务规则用来实现与所述支付调用构件对应的业务逻辑。

所述支付调用构件可以包括满足调用方支付请求的业务规则。所述业务规则可以用来实现与所述支付调用构件对应的业务逻辑。所述支付调用构件可以包括一个或多个，一个支付调用构件对应一个业务规则。

所述配置字典可以用来存放配置文件。根据配置文件可以自动确定所需的业务规则。配置文件可以理解为是对不同对象进行不同配置的文件。配置文件里存放程序启动时需要对程序进行配置的信息，比如启动刚安装的一款软件时，会出现一些填写注册信息的控件，并询问是否要勾选记住密码、下次自动登录等复选框，这些注册信息就被写进相应程序的配置文件里，当程序下次在启动时就会自动读取配置文件，对程序进行配置，这样就不用每次都填写这些注册信息，从而可以减少操作时间，提高开发效率。例如一些实施场景中，可以预先将实现不同业务规则的配置文件存放到配置字典，在支付场景中，可以通过读取配置字典确定实现业务逻辑所需的业务规则。

本说明书提供的一个实施例中，可以根据支付请求和配置字典为调用方生成完成支付流程所需的一个或多个支付调用构件。其中，每个支付调用构件包括完成对应支付流程的一个业务规则。也就是说，通过利用多个支付调用构件包括的业务规则可以实现对应支付流程的逻辑处理。例如一个实施场景中，完成支付流程需要完成对应的3个逻辑业务，则支付构件工厂需要根据支付请求和配置字典生成与逻辑业务对应的3个支付调用构件，且每个支付调用构件中包括已经确定的一个业务规则，即每个支付调用构件中包括完成该支付流程对应的一个业务规则。

本说明书提供的一个实施例中，支付构件工厂收到支付请求后，可以根据配置字典，为该提供方生成满足调用方要求的支付调用构件。例如一些实施场景中，支付构件工厂根据支付请求中的服务类型，读取配置字典，获取实现类名，通过Spring框架动态注入的方法，在初始化时确定调用哪个实现类，即确定调用哪个支付构件。

本说明书提供的一个实施例中，通过根据调用方发送的支付请求和配置字典生成满足调用方需求的支付调用构件，从而为调用方接下来调用预先构建的支付实体充血模型中包括的支付构件提供基础。

需要说明的是，本说明书实施例中，支付调用构件可以是根据调用方需求生成的，每个支付调用构件可以包括一个实现对应业务逻辑的业务规则。不同支付场景中，生成满足调用方需求的支付调用构件可以不同，也可以相同。此外，不同支付场景中，生成满足调用方需求的支付调用构件的数量可以不同，也可以相同。本说明书对此不作限定。

S14：基于所述支付调用构件对预先构建的支付实体充血模型中包括的支付构件进行调用，获得调用结果，所述支付实体充血模型包括实体数据结构和业务逻辑层，所述业务逻辑层包括支付构件。

充血模型可以理解为实体对象。充血模型的模型中既可以包括状态(属性)，又可以包括行为(方法)。充血模型可以将大多数业务逻辑放在领域对象中，同时完成对业务逻辑的封装处理，从而体现出面向对象设计的本质。这样，通过该领域对象可以为系统建立一个核心的领域模型，而该领域模型聚焦于为用户提供解决业务场景下核心问题的能力。一些支付场景中，所述支付实体充血模型可以包括账单、借方、贷方等一系列充血模型。

本说明书提供的一个实施例中，所述预先构建的支付实体充血模型可以采用领域驱动设计思想抽象获得，其可以用于描述业务逻辑。支付实体充血模型可以包括实体数据结构和业务逻辑层两部分。其中，领域驱动设计包括以下优点：(1)可以使业务逻辑被合理的分散到不同的领域对象中，代码结构更加清晰，可读性、可维护性更高；(2)领域驱动设计中对象职责更加单一，内聚度更高；(3)复杂的业务模型可以通过领域建模清晰的表达，开发人员可以在不读源码的情况下了解业务和系统结构，有利于对现存的系统进行维护和迭代开发；(4)系统高度模块化，代码重用度高，不会出现太多的重复逻辑。业务可以是一个实体单元向另一个实体单元提供的服务。逻辑可以是根据已有的信息推出合理的结论的规律。业务逻辑可以是一个实体单元为了向另一个实体单元提供服务，应该具备的规则与流程。业务逻辑可以理解为处理数据的逻辑。数据结构可以是带有结构特性的数据元素的集合，其研究的可以包括数据的逻辑结构和数据的物理结构以及它们之间的相互关系、对结构定义相适应的运算、设计相应的算法，并确保经过这些运算以后所得到的新结构仍保持原来的结构类型。数据结构可以是相互之间存在一种或多种特定关系的数据元素的集合，即带“结构”的数据元素的集合。一般的，所述的“结构”可以包括数据元素之间存在的关系，分为逻辑结构和存储结构。业务逻辑层可以是系统架构中体现核心价值的部分，主要可以集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计，它与系统所应对的领域逻辑有关，通常情况，也将业务逻辑层称为领域层。业务逻辑层可以实现对系统领域业务的处理以及逻辑性数据的生成、处理及转换。

本说明书提供的一个实施例中，所述业务逻辑层包括支付构件。所述支付构件可以通过将业务逻辑进行等效处理后获得。例如，可以通过分析支付流程中一系列基础支付服务，如同行转账、跨行转账等，提取出共性业务逻辑，将每个共性业务逻辑抽取为支付构件。

所述支付构件可以包括预设个业务规则，即一个支付构件可以对应一个或多个业务规则。每个支付构件中可以包括实现相同业务逻辑的不同业务规则。所述业务规则可以对应不同提供方、不同支付介质、不同支付接口。例如，一些实施场景中，账户、卡、手机号码都是用来支付的支付介质，也就是说，其都是实现相同业务逻辑的。由于不同支付介质对应的业务规则不同，而且在选择不同支付介质进行支付时需要通过对应的业务规则完成，所以可以将不同业务规则封装在一个支付构件中，即支付构件可以包括预设个业务规则。

所述业务规则可以用来实现与所述支付构件对应的业务逻辑。例如，第一支付构件可以包括3个业务规则，3个业务规则分别对应实现同行转账、跨行转账、信用卡消费服务时的业务逻辑。当支付请求中包括的服务类型为同行转账时，可以根据支付请求和配置字典自动确定支付所需要的业务规则，这样在具体实现同行转账时，可以通过调用第一支付构件自动实现同行转账的业务逻辑。

本说明书提供的一个实施例中，通过将实现相同业务逻辑对应的业务规则封装到一个支付构件中，使得，在实际支付过程中，可以直接通过配置字典确定需要支付构件中包括的哪个业务规则，从而可以实现异化场景、异化介质、异化规则下一体化支付。此外，由于将复杂支付流程抽象建模成若干个支付构件，将具有各异性的支付流程转换为对支付构件的模式化编排，当调用方需要同时满足不同支付场景，如“同行转账”、“跨行转账”、“信用卡消费”时，可以实现一次调用自动适配不同支付场景的需求，而且只需要一套调用逻辑处理代码，从而可以大大降低程序冗余度，提高代码可维护性。

例如一些支付场景下，账单是最重要的一个充血模型，可以首先对其进行领域模型建模。如图2所示，图2是本说明书提供的账单充血模型及其实体数据结构和逻辑业务层的一个实施例的示意图。图2中，标五角星的条目为账单模型的实体数据部分。特别的，这些实体数据也都是充血模型(如“借方”实体数据，也有自己的实体数据结构和逻辑业务)。只有实体数据结构为元数据，不涉及逻辑业务操作时，才使用贫血模型表示。标旗子的条目为账单模型的逻辑业务层，它由一系列方法组成。这些方法分成两类：一类为操作实体数据结构的方法，如“账单当前状态是否可支付”通过判断“账单状态”得到正确的返回；一类为支付构件方法，这类方法在初始化账单模型时由支付构件工厂为当前调用方自适应生成，实现对应的逻辑业务操作。特别的，第二类方法实现内部也可以调用第一类方法。

本说明书提供的一个实施例中，所述基于所述支付调用构件对预先构建的支付实体充血模型中包括的支付构件进行调用，获得调用结果，可以包括：对所述支付实体充血模型进行初始化处理，获得初始化充血模型；将所述支付调用构件注入到所述初始化充血模型中；调用所述初始化充血模型包括的支付构件。例如一些实施场景中，可以通过标准化构件初始化账单充血模型，将支付构件工厂生成的支付调用构件注入到账单充血模型中，然后通过逐一调用账单充血模型包括的支付构件，完成对应的逻辑业务操作。需要说明的是，在调用支付构件时，实际上是调用账单充血模型中的逻辑业务方法，并在具体问题处理上还有选择的调用其他充血模型的逻辑业务方法，这些业务方法通过操作充血模型中的实体数据结构完成业务闭环。

图3是本说明书提供的支付实体充血模型构建方法一个实施例的流程示意图。具体的，一种实施例中，所述预先构建的支付实体充血模型可以包括采用下述方式得到：

S140：获取功能相同的支付服务。

所述支付服务可以包括同行转账、跨行转账、信用卡消费等。

本说明书提供的一个实施例中，获取功能相同的支付服务可以包括：通过结构化、标准化的方法收集服务，确定服务信息，所述服务信息可以包括服务名称、服务功能、生命周期、服务触发条件及相关人员以及服务分类信息(如单一支付、聚合支付等)，然后从服务信息中提取能够标识对应服务的关键信息(如服务功能)，基于提取出的关键信息对收集到的服务进行聚类分析，获得具有共性的服务。例如，从服务信息中提取能够标识对应服务的关键信息为服务功能，基于服务功能对收集到的服务进行聚类分析，获得功能相同的服务，如功能相同的基础支付服务。

需要说明的是，在系统开发阶段开始前，可以对获得的功能相同的服务完成实例化，构造接入报文、接入方法、接入条件等。此外，收集服务所采用的结构化、标准化的方法可以是本领域人员知晓的人员一种方法，本说明书对此不做限定。

S142：提取所述支付服务中的业务逻辑。

一般情况下，支付流程中包括实现不同功能的业务逻辑。

本说明书提供的一个实施例中，在获取功能相同的支付服务后，可以通过分析一系列功能相同的服务，提取出具有共性的业务逻辑，如提取出功能相同的业务逻辑。具体的，可以通过分析一系列基础支付服务，如同行转账、跨行转账等，提取出功能相同的业务逻辑。

S144：将功能相同的业务逻辑等效为支付构件，所述支付构件包括标准化构件、支付元素注入构件、支付校验构件、持久化构件、支付幂等构件、支付路由生成构件、支付接口调用构件。

本说明书提供的一个实施例中，在提取出功能相同的业务逻辑后，可以将相同功能的业务逻辑抽取为一个支付构件。每个支付构件可以包括一个或多个实现相同业务逻辑的业务规则。所述业务规则可以用来实现与所述支付构件对应的业务逻辑。例如，获取同行转账、跨行转账两个基础支付服务的业务逻辑，其中，同行转账包括1、2、3三个业务逻辑，跨行转账包括1’、2’、3’三个业务逻辑，业务逻辑1和1’、2和2’、3和3’实现的功能相似，业务逻辑1和1’对应的业务规则不同、2和2’对应的业务规则不同、3和3’对应的业务规则相同，则可以把业务逻辑1和1’用构件1表示，业务逻辑2和2’用构件2表示，业务逻辑3和3’用构件3表示，其中，构件1和构件2均包括两个业务规则，构件3包括一个业务规则。再如，获取同行转账、跨行转账两个基础支付服务的业务逻辑，其中，同行转账包括1、2、3三个业务逻辑，跨行转账包括1’、2’、3’三个业务逻辑，业务逻辑1和1’、2和2’、3和3’实现的功能相似，业务逻辑1和1’对应的业务规则相同、2和2’对应的业务规则不同、3和3’对应的业务规则相同，则可以把业务逻辑1和1’用构件1表示，业务逻辑2和2’用构件2表示，业务逻辑3和3’用构件3表示，其中，构件1和构件3均包括一个业务规则，构件2包括两个个业务规则。

一般情况下，一些实施场景中，支付构件可以包括标准化构件、支付元素注入构件、支付校验构件、持久化构件、支付幂等构件、支付路由生成构件、支付接口调用构件。

其中，所述标准化构件可以用于实现请求报文到充血模型的转换以及支付信息的初始化。具体的，由于支付服务都以json(JavaScript Object Notation，脚本语言中的对象和数组)格式报文作为交互媒介，即调用方调用支付服务时上送请求json报文，支付服务处理完毕后，又将处理结果以json报文的形式返回给调用方。所以标准化构件可以完成请求报文到充血模型的转换，即将请求报文中每个字段值映射到充血模型实体数据结构中对应的数据项上，然后通过配置字典识别出不同支付服务的请求报文的映射规则，实现充血模型的自动适配和初始化。同时，标准化构件还可以完成支付时间、支付日期的初始化，并通过调用支付介质服务识别出借贷方支付介质类型并为对应的充血模型赋值。可见，标准化构件可以为后续的支付过程打下良好的基础。

所述支付元素注入构件可以用于预先将生成规则保存到数据库中，所述生成规则可以用于生成标识当前交易的随机序列号码。具体的，通过分析不同的支付服务接口，可以知晓每个支付接口都要求调用方上送一种长时间内全局唯一的随机序列号码，这类号码在不同的支付接口中名称不同，如交易流水号、支付事件编号、支付渠道编码等等，且生成规则也不同，有以特殊随机数作为种子生成的，有取当前时间戳和唯一键拼接生成的。但是，这类随机序列号码的作用相同，都是为了标示当前交易，方便支付后续操作，如账务核对等。如果让调用方自己维护一套不同支付服务的序列号码生成规则，不仅维护麻烦，且完全和实际业务交易无关。支付元素注入控件可以预先将生成规则保存在数据库中，当交易发生时，自动按需生成随机序列号码，并且支持特殊场景的灵活配置。

所述支付校验构件可以用于实现支付过程中的数据检查。具体的，支付校验构件可以完成支付过程中的数据检查，如密码是否一致、账户户名是否一致等。同时，也支持自动适配特殊场景下的特殊校验规则，如某类转账中，需要校验调用方上送的客户三要素(姓名、证件类型、证件号码)和银行客户系统中留存的是否一致。

所述持久化构件可以用于提供标准的数据库操作模板，所述操作模板可以用于完成数据操作。持久化就是将内存中的数据模型转换为存储模型。本说明书一个实施例中，持久化可以是向数据库提交支付明细(即账单)数据。一般情况下，不同的持久化程序可以是由不同的开发人员实现的，由于开发人员能力有所差异，且有可能对不同的程序分支尤其是异常分支的处理流程设计不同，往往会造成相同支付服务的不同支付场景响应不同。如插入数据时发生主键冲突异常，是直接报错还是返回已存在的记录。持久化构件可以提供一种标准的数据库增、删、改、查操作模板，只需传入数据对象，再调用对应的增、删、改、查方法，就能够完成对应数据操作，这样就可以统一异常处理、状态判断等数据库操作中常见的处理流程，解决支付响应不一致的问题。

所述支付幂等构件可以用于根据配置字典记录的幂等规则，在幂等处理过程中，将幂等逻辑和字段分离。幂等可以是使用相同参数重复执行，并能获得相同结果的方法。这些方法不会影响系统状态，从而不用担心重复执行对系统造成改变。一些支付场景下的幂等比较复杂。例如一些实施场景中，不同调用方对幂等的定义不完全相同。例如，有些调用方需要执行严格的幂等规则，再次上送请求报文时，报文字段中支付日期、支付时间、账单状态等都需要与首次上送保持一致，才能返回一致的处理结果。有些调用方需要的幂等规则却较为宽泛，只要核心交易数据，如借贷方账户、交易金额一致时，就希望可以返回幂等的结果。在这种场景下，传统的做法是当重复上送请求报文时，根据调用方的不同对每个字段做分支判断，这种实现方法在初期调用方较少时还可维护，当调用方增多时，代码的可维护性将会大大降低。支付幂等构件可以提供一种通用的幂等处理方法。可以通过配置字典记录不同调用方对不同字段的幂等规则，在幂等处理过程中，可以自动剔除当前调用方不关心的数据字段，从而可以将幂等逻辑和字段分离，提高系统的可维护性和可扩展性。

所述支付路由生成构件可以用于自动判断支付请求需要调用的接口。针对不同的支付场景，前期调用方的做法是调用不同的支付服务。如同行转账调用A接口，跨行转账调用B接口，信用卡消费调用C接口。这给调用方在多支付场景下的开发带来不少麻烦。支付路由生成构件可以根据借贷方、支付介质类型等模型，自动判断出当前支付请求需要调用的接口，这样，调用方只需要生成一种请求报文、调用一种支付服务就可以实现多场景的支付需求。

所述支付接口调用构件可以用于读取所述支付路由生成构件提供的待调用接口信息，根据所述待调用接口信息调用对应的接口，还可以用于解析调用接口返回的报文，生成预设格式的结果发送给调用方。具体的，支付接口调用构件可以读取支付路由生成构件提供的待调用接口信息，调用对应的支付接口，并解析所调接口返回的报文，生成统一的支付结果返回给调用方。

需要说明的是，另一些实施场景中，还可以包括其他支付构件，本说明书对此不作限定。

S146：基于领域驱动设计构建支付实体充血模型，所述支付实体充血模型包括实体数据结构和业务逻辑层，所述业务逻辑层包括支付构件。

本说明书提供的一个实施例中，可以采用领域驱动设计思想抽象出支付实体充血模型，用于描述业务逻辑，充血模型可以包括实体数据结构和业务逻辑层两部分。

S16：将所述调用结果发送给调用方。

本说明书提供的一个实施例中，通过对支付构件的模式化编排，完成对应的逻辑业务操作，获得调用结果，从而将调用结果发送给调用方。其中，模式化编排可以理解为对支付构件的有序调用。调用结果可以是支付接口调用构件通过解析调用接口返回的报文，然后将其封装为统一格式的支付结果应答报文。

本说明书提供的一个实施例中，还可以包括：当所述支付实体充血模型中不存在满足所述支付请求的第一支付构件时，将所述第一支付构件添加到所述支付实体充血模型中。例如，支付实体充血模型中包括7种支付构件，支付构件工厂收到调用方发送的支付请求事件后，根据配置字典，为该提供方生成满足调用方要求的支付调用构件包括6种(假设支付实体充血模型中可以满足支付调用构件对应业务逻辑的有5种，剩余1种支付调用构件对应的业务逻辑在支付实体充血模型中不存在)，此时，可以将剩余1种支付调用构件添加到支付实体充血模型中。这样通过将重要业务逻辑不断添加到充血模型中，可以使充血模型日趋完善。

本说明书提供的一个实施例中，还可以包括：当所述支付实体充血模型中存在满足所述支付请求的第一支付构件，且所述第一支付构件包括的预设个业务规则中不存在满足所述支付请求的第一业务规则时，将所述第一业务规则添加到所述第一支付构件包括的业务规则中。

本说明书提供的一个实施例中，还可以将不再使用或不重要的构件或业务规则从模型中移除。从而实现系统架构的平稳优化，并对当前运行的系统影响最小。

本说明书实施例中，在支付实体充血模型中添加支付构件或业务规则的过程相当于为充血模型添加新功能的过程，可以使充血模型日趋完善。此外，将不再使用或不重要的构件或业务从充血模型中移除，可以实现系统架构的平稳优化，降低对当前运行系统的影响。

图4是本说明书提供的一种支付调用方法的一个具体实施例的示意图。如图4所示，其中，实施例的具体过程和步骤如下：

(1)调用方发起支付请求报文，将支付请求报文发送给支付系统；

(2)支付系统中支付构件工厂收到支付请求报文，读取配置字典，生成满足调用方要求的支付调用构件；

(3)支付构件的模式化编排；

首先通过标准化构件初始化账单充血模型，将支付构件工厂生成的支付调用构件注入到账单充血模型中，然后通过逐一调用账单充血模型包括的支付构件，完成对应的逻辑业务操作。其中，在调用支付构件时，实际上是调用账单充血模型中的逻辑业务方法，并在具体问题处理上还有选择的调用其他充血模型的逻辑业务方法，这些业务方法通过操作充血模型中的实体数据结构完成业务闭环。

(4)根据接口调用结果返回报文。

支付接口调用构件通过解析调用接口返回的报文，生成统一的支付结果返回给调用方。

本说明书提供的一个或多个支付调用方法实施例，可以通过将复杂支付流程中的业务逻辑抽象成若干个支付构件，从而将具有各异性的支付流程转换为对支付构件的模式化编排，可以有效指导软件开发人员在开发流程中将重点放在系统的核心业务领域，即支付构件的实现上。通过采用领域驱动设计构建支付实体充血模型，将原来分散在业务处理流程各处的核心逻辑内聚到充血模型本身，可以极大降低软件系统的复杂性，提高软件系统的可维护性、可扩展性。利用本说明书的一些实施例，可以在降低系统复杂性的同时，提高系统的可维护性、可扩展性。

本说明书中上述方法的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参加即可，每个实施例重点说明的都是与其他实施例的不同之处。相关之处参加方法实施例的部分说明即可。

基于上述所述的一种支付调用方法，本说明书还提供一个或多个支付调用装置的实施例。所述装置可以包括使用了本说明书实施例所述方法的系统(包括分布式系统)、软件(应用)、模块、组件、服务器、客户端等并结合必要的实施硬件的装置。基于同一创新构思，本说明书实施例提供的一个或多个实施例中的装置如下面的实施例所述。由于装置解决问题的实现方案与方法相似，因此本说明书实施例具体的装置的实施可以参见前述方法的实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

具体地，图5是本说明书提供的一种支付调用装置的一个实施例的模块结构示意图，如图5所示，本说明书提供的一种支付调用装置可以包括：接收模块120，生成模块122，调用模块124，发送模块126。

接收模块120，可以用于接收调用方发送的支付请求；

生成模块122，可以用于根据所述支付请求和配置字典生成支付调用构件，所述支付调用构件包括业务规则，所述业务规则用来实现与所述支付调用构件对应的业务逻辑；

调用模块124，可以用于基于所述支付调用构件对预先构建的支付实体充血模型中包括的支付构件进行调用，获得调用结果，所述支付实体充血模型包括实体数据结构和业务逻辑层，所述业务逻辑层包括支付构件；

发送模块126，可以用于将所述调用结果发送给调用方。

需要说明的，上述所述的装置根据方法实施例的描述还可以包括其他的实施方式，具体的实现方式可以参照相关方法实施例的描述，在此不作一一赘述。

所述装置的另一个实施例中，所述预先构建的支付实体充血模型可以包括：

获取模块，可以用于获取功能相同的支付服务；

提取模块，可以用于提取所述支付服务中的业务逻辑；

等效模块，可以用于将功能相同的业务逻辑等效为支付构件，所述支付构件包括标准化构件、支付元素注入构件、支付校验构件、持久化构件、支付幂等构件、支付路由生成构件、支付接口调用构件；

构建模块，可以用于基于领域驱动设计构建支付实体充血模型，所述支付实体充血模型包括实体数据结构和业务逻辑层，所述业务逻辑层包括支付构件。

所述装置的另一个实施例中，所述支付构件中，

所述标准化构件可以用于实现请求报文到充血模型的转换，还用于实现支付信息的初始化；

所述支付元素注入构件可以用于预先将生成规则保存到数据库中，所述生成规则用于生成标识当前交易的随机序列号码；

所述支付校验构件可以用于实现支付过程中的数据检查；

所述持久化构件可以用于提供标准的数据库操作模板，所述操作模板用于完成数据操作；

所述支付幂等构件可以用于根据配置字典记录的幂等规则，在幂等处理过程中，将幂等逻辑和字段分离；

所述支付路由生成构件可以用于自动判断支付请求需要调用的接口；

所述支付接口调用构件可以用于读取所述支付路由生成构件提供的待调用接口信息，根据所述待调用接口信息调用对应的接口，还可以用于解析调用接口返回的报文，生成预设格式的结果发送给调用方。

所述装置的另一个实施例中，所述调用模块124，可以包括：

初始化单元1240，可以用于对所述支付实体充血模型进行初始化处理，获得初始化充血模型；

注入单元1242，可以用于将所述支付调用构件注入到所述初始化充血模型中；

调用单元1244，可以用于调用所述初始化充血模型包括的支付构件。

所述装置的另一个实施例中，还可以包括：

第一添加模块，可以用于当所述支付实体充血模型中不存在满足所述支付请求的第一支付构件时，将所述第一支付构件添加到所述支付实体充血模型中。

所述装置的另一个实施例中，还可以包括：

第二添加模块，可以用于当所述支付实体充血模型中存在满足所述支付请求的第一支付构件，且所述第一支付构件包括的预设个业务规则中不存在满足所述支付请求的第一业务规则时，将所述第一业务规则添加到所述第一支付构件包括的业务规则中。

本说明书提供的一个或多个支付调用装置实施例，可以通过将复杂支付流程中的业务逻辑抽象成若干个支付构件，从而将具有各异性的支付流程转换为对支付构件的模式化编排，可以有效指导软件开发人员在开发流程中将重点放在系统的核心业务领域，即支付构件的实现上。通过采用领域驱动设计构建支付实体充血模型，将原来分散在业务处理流程各处的核心逻辑内聚到充血模型本身，可以极大降低软件系统的复杂性，提高软件系统的可维护性、可扩展性。利用本说明书的一些实施例，可以在降低系统复杂性的同时，提高系统的可维护性、可扩展性。

需要说明的，上述所述的装置根据方法实施例的描述还可以包括其他的实施方式，具体的实现方式可以参照相关方法实施例的描述，在此不作一一赘述。

本说明书实施例还提供一种支付调用设备，包括处理器及用于存储处理器可执行指令的存储器，所述指令被所述处理器执行时实现包括以下步骤：

接收调用方发送的支付请求；

根据所述支付请求和配置字典生成支付调用构件，所述支付调用构件包括业务规则，所述业务规则用来实现与所述支付调用构件对应的业务逻辑；

基于所述支付调用构件对预先构建的支付实体充血模型中包括的支付构件进行调用，获得调用结果，所述支付实体充血模型包括实体数据结构和业务逻辑层，所述业务逻辑层包括支付构件；

将所述调用结果发送给调用方。

需要说明的，上述所述的设备根据方法实施例的描述还可以包括其他的实施方式。具体的实现方式可以参照相关方法实施例的描述，在此不作一一赘述。

本说明书还提供一个或多个支付调用系统的实施例，包括至少一个处理器以及存储计算机可执行指令的存储器，所述处理器执行所述指令时实现上述任意一个或者多个实施例中所述方法的步骤，例如包括：接收调用方发送的支付请求；根据所述支付请求和配置字典生成支付调用构件，所述支付调用构件包括业务规则，所述业务规则用来实现与所述支付调用构件对应的业务逻辑；基于所述支付调用构件对预先构建的支付实体充血模型中包括的支付构件进行调用，获得调用结果，所述支付实体充血模型包括实体数据结构和业务逻辑层，所述业务逻辑层包括支付构件；将所述调用结果发送给调用方。所述的系统可以为单独的服务器，也可以包括使用了本说明书的一个或多个所述方法或一个或多个实施例装置的服务器集群、系统(包括分布式系统)、软件(应用)、实际操作装置、逻辑门电路装置、量子计算机等并结合必要的实施硬件的终端装置。

本说明书实施例所提供的方法实施例可以在移动终端、计算机终端、服务器或者类似的运算装置中执行。以运行在服务器上为例，图6是本说明书提供的一种支付调用服务器的一个实施例的硬件结构框图，该服务器可以是上述实施例中的支付调用装置或支付调用系统。如图6所示，服务器10可以包括一个或多个(图中仅示出一个)处理器100(处理器100可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器200、以及用于通信功能的传输模块300。本领域普通技术人员可以理解，图6所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，服务器10还可包括比图6中所示更多或者更少的组件，例如还可以包括其他的处理硬件，如数据库或多级缓存、GPU，或者具有与图6所示不同的配置。

存储器200可用于存储应用软件的软件程序以及模块，如本说明书实施例中的支付调用方法对应的程序指令/模块，处理器100通过运行存储在存储器200内的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器200可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器200可进一步包括相对于处理器100远程设置的存储器，这些远程存储器可以通过网络连接至计算机终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输模块300用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端的通信供应商提供的无线网络。在一个实例中，传输模块300包括一个网络适配器(Network Interface Controller，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输模块300可以为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本说明书提供的上述实施例所述的方法或装置可以通过计算机程序实现业务逻辑并记录在存储介质上，所述的存储介质可以计算机读取并执行，实现本说明书实施例所描述方案的效果。

所述存储介质可以包括用于存储信息的物理装置，通常是将信息数字化后再以利用电、磁或者光学等方式的媒体加以存储。所述存储介质有可以包括：利用电能方式存储信息的装置如，各式存储器，如RAM、ROM等；利用磁能方式存储信息的装置如，硬盘、软盘、磁带、磁芯存储器、磁泡存储器、U盘；利用光学方式存储信息的装置如，CD或DVD。当然，还有其他方式的可读存储介质，例如量子存储器、石墨烯存储器等等。

本说明书实施例提供的上述支付调用方法或装置可以在计算机中由处理器执行相应的程序指令来实现，如使用windows操作系统的c++语言在PC端实现、linux系统实现，或其他例如使用android、iOS系统程序设计语言在智能终端实现，以及基于量子计算机的处理逻辑实现等。

需要说明的是说明书上述所述的装置、计算机存储介质、系统根据相关方法实施例的描述还可以包括其他的实施方式，具体的实现方式可以参照对应方法实施例的描述，在此不作一一赘述。

本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于硬件+程序类实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书实施例并不局限于必须是符合行业通信标准、标准计算机数据处理和数据存储规则或本说明书一个或多个实施例所描述的情况。某些行业标准或者使用自定义方式或实施例描述的实施基础上略加修改后的实施方案也可以实现上述实施例相同、等同或相近、或变形后可预料的实施效果。应用这些修改或变形后的数据获取、存储、判断、处理方式等获取的实施例，仍然可以属于本说明书实施例的可选实施方案范围之内。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device，PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、车载人机交互设备、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

虽然本说明书一个或多个实施例提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或终端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境，甚至为分布式数据处理环境)。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下，并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书一个或多个时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

本发明是参照根据本发明实施例的方法、装置(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储、石墨烯存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

本领域技术人员应明白，本说明书一个或多个实施例可提供为方法、系统或计算机程序产品。因此，本说明书一个或多个实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书一个或多个实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

以上所述仅为本说明书一个或多个实施例的实施例而已，并不用于限制本本说明书一个或多个实施例。对于本领域技术人员来说，本说明书一个或多个实施例可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在权利要求范围之内。

Claims (14)

1.一种支付调用方法，其特征在于，包括：

接收调用方发送的支付请求；

根据所述支付请求和配置字典生成支付调用构件，所述支付调用构件包括实现相同功能业务逻辑的业务规则，所述业务规则用来实现与所述支付调用构件对应的业务逻辑，所述配置字典中包括用于实现不同业务规则的配置文件；

基于所述支付调用构件对预先构建的支付实体充血模型中包括的支付构件进行调用，以实现所述支付调用构件对应的业务规则的业务逻辑，获得调用结果，所述支付实体充血模型包括实体数据结构和业务逻辑层，所述业务逻辑层包括支付构件；所述支付构件中封装有预设个业务规则；

将所述调用结果发送给调用方。

2.如权利要求1所述的方法，其特征在于，所述预先构建的支付实体充血模型包括采用下述方式得到：

获取功能相同的支付服务；

提取所述支付服务中的业务逻辑；

将功能相同的业务逻辑等效为支付构件，所述支付构件包括标准化构件、支付元素注入构件、支付校验构件、持久化构件、支付幂等构件、支付路由生成构件、支付接口调用构件；

基于领域驱动设计构建支付实体充血模型，所述支付实体充血模型包括实体数据结构和业务逻辑层，所述业务逻辑层包括支付构件。

3.如权利要求1所述的方法，其特征在于，所述支付实体充血模型中，每个支付构件中的预设个业务规则对应不同提供方、不同支付介质、不同支付接口。

4.如权利要求1所述的方法，其特征在于，所述基于所述支付调用构件对预先构建的支付实体充血模型中包括的支付构件进行调用，获得调用结果，包括：

对所述支付实体充血模型进行初始化处理，获得初始化充血模型；

将所述支付调用构件注入到所述初始化充血模型中；

调用所述初始化充血模型包括的支付构件。

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

当所述支付实体充血模型中不存在满足所述支付请求的第一支付构件时，将所述第一支付构件添加到所述支付实体充血模型中。

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

当所述支付实体充血模型中存在满足所述支付请求的第一支付构件，且所述第一支付构件包括的预设个业务规则中不存在满足所述支付请求的第一业务规则时，将所述第一业务规则添加到所述第一支付构件包括的业务规则中。

7.一种支付调用装置，其特征在于，包括：

接收模块，用于接收调用方发送的支付请求；

生成模块，用于根据所述支付请求和配置字典生成支付调用构件，所述支付调用构件包括实现相同功能业务逻辑的业务规则，所述业务规则用来实现与所述支付调用构件对应的业务逻辑，所述配置字典中包括用于实现不同业务规则的配置文件；

调用模块，用于基于所述支付调用构件对预先构建的支付实体充血模型中包括的支付构件进行调用，以实现所述支付调用构件对应的业务规则的业务逻辑，获得调用结果，所述支付实体充血模型包括实体数据结构和业务逻辑层，所述业务逻辑层包括支付构件；所述支付构件中封装有预设个业务规则；

发送模块，用于将所述调用结果发送给调用方。

8.如权利要求7所述的装置，其特征在于，所述预先构建的支付实体充血模型包括：

获取模块，用于获取功能相同的支付服务；

提取模块，用于提取所述支付服务中的业务逻辑；

等效模块，用于将功能相同的业务逻辑等效为支付构件，所述支付构件包括标准化构件、支付元素注入构件、支付校验构件、持久化构件、支付幂等构件、支付路由生成构件、支付接口调用构件；

构建模块，用于基于领域驱动设计构建支付实体充血模型，所述支付实体充血模型包括实体数据结构和业务逻辑层，所述业务逻辑层包括支付构件。

9.如权利要求8所述的装置，其特征在于，所述支付构件中，

所述标准化构件用于实现请求报文到充血模型的转换，还用于实现支付信息的初始化；

所述支付元素注入构件用于预先将生成规则保存到数据库中，所述生成规则用于生成标识当前交易的随机序列号码；

所述支付校验构件用于实现支付过程中的数据检查；

所述持久化构件用于提供标准的数据库操作模板，所述操作模板用于完成数据操作；

所述支付幂等构件用于根据配置字典记录的幂等规则，在幂等处理过程中，将幂等逻辑和字段分离；

所述支付路由生成构件用于自动判断支付请求需要调用的接口；

所述支付接口调用构件用于读取所述支付路由生成构件提供的待调用接口信息，根据所述待调用接口信息调用对应的接口，还用于解析调用接口返回的报文，生成预设格式的结果发送给调用方。

10.如权利要求7所述的装置，其特征在于，所述调用模块，包括：

初始化单元，用于对所述支付实体充血模型进行初始化处理，获得初始化充血模型；

注入单元，用于将所述支付调用构件注入到所述初始化充血模型中；

调用单元，用于调用所述初始化充血模型包括的支付构件。

11.如权利要求7所述的装置，其特征在于，还包括：

第一添加模块，用于当所述支付实体充血模型中不存在满足所述支付请求的第一支付构件时，将所述第一支付构件添加到所述支付实体充血模型中。

12.如权利要求7所述的装置，其特征在于，还包括：

第二添加模块，用于当所述支付实体充血模型中存在满足所述支付请求的第一支付构件，且所述第一支付构件包括的预设个业务规则中不存在满足所述支付请求的第一业务规则时，将所述第一业务规则添加到所述第一支付构件包括的业务规则中。

13.一种支付调用设备，其特征在于，包括处理器及用于存储处理器可执行指令的存储器，所述指令被所述处理器执行时实现包括以下步骤：

接收调用方发送的支付请求；

根据所述支付请求和配置字典生成支付调用构件，所述支付调用构件包括实现相同功能业务逻辑的业务规则，所述业务规则用来实现与所述支付调用构件对应的业务逻辑，所述配置字典中包括用于实现不同业务规则的配置文件；

基于所述支付调用构件对预先构建的支付实体充血模型中包括的支付构件进行调用，获得调用结果，以实现所述支付调用构件对应的业务规则的业务逻辑，所述支付实体充血模型包括实体数据结构和业务逻辑层，所述业务逻辑层包括支付构件；所述支付构件中封装有预设个业务规则；

将所述调用结果发送给调用方。

14.一种支付调用系统，其特征在于，包括至少一个处理器以及存储计算机可执行指令的存储器，所述处理器执行所述指令时实现权利要求1-6中任意一项所述方法的步骤。

Images