关于产品包装的ESB服务定义探讨

需求背景:

某银行为支持小微企业发展,解决小微企业流动资金不足的困难,设计新贷款产品:优质客户在贷款到期时,可以通过审批获得一笔新贷款,客户偿还上笔贷款利息后,银行为客户发放新贷款,并自动将新贷款用于偿还上笔贷款本金(实际就是延长了上笔贷款的还款时间,避免小微企业为偿还贷款而借用民间短期借贷)。

系统背景:

该银行建设有信贷系统和核心系统,信贷系统主要负责贷款的贷前审批及贷后管理,核心系统主要负责贷款发放、偿还等账务核算。

实现分析:

该产品是通过对现有的“贷款还息”、“贷款发放”、“贷款还本”三个服务的组合包装,而问题在于该产品是应该由信贷系统连续调用三个服务来实现该产品功能,还是应该由核心系统对三个服务进行组装提供一个新的“贷款还息延期”服务(服务名称可能不合适,暂定)。

服务定义:

最初的思路,是由信贷系统在一个事务中,组合三个服务,包装为一个新的贷款产品,ESB不再新增服务,但若按此思路开发,则信贷系统需对核心系统提供的三个服务分别按次序调用,并保证全部成功,跨系统的事务一致性保障并不容易实现。若改由核心系统提供服务,由于核心系统并无组装现有交易模块的功能,需开发新程序将原有三个交易模块写于同一事务中(实际就是把三个交易代码复制到一起,然后简单修改)。

定义结果:

最终决定,由核心系统提供“贷款还息延期”服务。定义由核心系统提供服务,并非前述的实现难度的差异,而是基于贷款产品的实际提供方的考虑,表面上贷款产品是由信贷系统提供,但如系统背景中所述,该行的信贷系统是作为流程审批系统来使用,贷款的业务处理及账务核算均由核心系统提供,在该背景下,“还息”、“放款”、“还本”都是属于核心系统的服务范围,信贷系统只是作为一个业务发起方,本身无相关业务处理,核心系统才是真正提供该贷款产品的服务方,所以在该背景下,应由核心系统对已有服务进行组装,提供新服务。

扩展思考:

  1. 若信贷系统作为贷款的业务处理系统,承担贷款相关的所有业务处理,而核心系统提供的是会计分录记账,根据信贷系统提供的会计分录进行记账,那么就无需新增服务,因为所有的业务处理在信贷系统内部就可以完成,核心系统不需要进行改造。在这种场景下,信贷系统和核心系统是松耦合的,但对信贷系统的功能要求较高。
  2. 若信贷系统和核心系统间的界限较模糊,均承担了一些业务处理,如核心系统提供通用记账,根据信贷系统提供贷款种类信息及各项记账金额,核心决定记账方式和规则,则该业务产品的实现,可由核心系统对记账规则进行配置,而信贷系统完成相关计算来实现。在这种场景下,信贷系统和核心系统是紧耦合的,新增业务品种,核心需进行相关配置或修改,但核心系统的提供的服务相对唯一。
  3. 在该案例中,信贷实际只是业务发起方,核心系统实现了所有业务及账务处理,信贷系统和核心系统也是紧耦合的,新增业务品种,核心需新增服务(是否核心系统能通过整理产品模型,统一提供较为标准的某类产品服务,这样就貌似和第2点的情况一致了?)。

茶余饭后:

建设ESB的目标,就是将各系统进行解耦,降低系统间耦合度,提高业务响应效率,但在实际工作中,理想的系统模型是难以直接落地的,总会受到历史遗留、能力水平、资源情况等各方面约束,应该认识到建设ESB的过程也是一个循序渐进的过程,在服务的不断演变中循环上升,相信最终能获得成功。

文章只是对突然灵感的记录,不一定就正确,希望有志同道合之人一同探讨。