头部行对公信贷业务中台DDD建设实践经验分享

江峰  中电金信助理副总裁

 

一、对公业务数字化转型的背景

关于业务中台的建设大家应该不陌生，今天讲的重点是突出在领域驱动设计的架构思想下如何建设业务中台。说到信贷业务中台，先要回顾整个对公信贷业务的数字化转型的背景及突破点，正是因为有了数字化转型大的战略目标的指引，我们才会有建设业务中台的战术层的执行。

近年来，整个金融机构的数字化转型正处在全面加速的进程中，对公业务的数字化转型虽然起步较零售金融有些晚，但是整个发展的态势是非常迅速的。这也是得利于零售金融转型中积累了很多很好的宝贵经验。

转型的背景有很多，主要总结有以下4点：

一是整个对公客户行为预期的改变。随着我们开始大力扶持小微企业、普惠金融，尤其在疫情之后，客户的线上化需求是不断提升的，客户对金融服务的要求是希望可以得到及时的响应，有快速的、良好的体验，所以这对金融机构服务提出新的要求；

二是在经济新常态下，银行原来的商业模式面临着转型的压力，监管导向的日益趋严、资产质量周期性地承压，以及经营业绩放缓，都需要商业银行做出快速转变，通过数字化转型找到新的利润增长点；

三是行业竞争的加剧，一方面是银行同业之间的竞争，很多的数字化产品就是同质化严重，要打出差异化，找出自己精准服务的客群，在产品上提供有特色的一些服务，另一方面还有一些非持牌的泛金融类的公司，借助自有的生态流量场景，更需要通过转型来提升竞争力；

四是目前云计算与分布式架构的技术日趋成熟，同时国产化的、自主可控的一些基础设施的能力，包括国产化的服务器、中间件、数据库等基础设施已经成熟了，让我们的转型成本大幅地降低。

在转型背景之下，我们也看到了几个主要突破点：

首先是全渠道的建设和整合，银行可以通过自建的多渠道来提供金融服务，比如手机银行、网银、微信小程序、公众号等，也包括一些场景金融平台、共享平台，希望通过渠道资金的整合跟建设做到无缝交互的、立体化的交付。在这个渠道之上，所有的用户是可以享受到无差异的、一体化的、高效便捷的体验。

第二是全面提升场景化的服务能力，尤其在交易银行的场景，交易银行天然有线上化、智能化、移动化的特征，跟数字化转型非常契合，也要切入到很多的企业经营的场景中，所以更需要提升场景化的服务能力，来覆盖支付结算、现金管理、贸易融资、供应链管理等能力；

第三是建设中台体系，刚才提到了市场环境的变化、客户需求在变化，我们要及时地响应整个的快速变化，就需要建设强中台的能力，一方面是能够去承接住客户需求快速的变化，另一方面能有效减缓这种变化对后端基础设施的冲击。中台建设基本包括以下三方面：第一是从架构的转型来说，越来越多的银行开始用分布式的IT架构；第二是我们从原来的稳态架构，逐渐过渡到稳态加敏态的双态模式。敏态结构一般是薄前台、厚中台、稳后台的架构模式来实现整体的快速处理能力。第三是数据中台。刚才说的中台建设除了业务中台、技术中台，还有数据中台。建设数据中台也是为了增强大数据的收集能力、分析能力，深度挖掘数据的价值，通过数据产品的形式助推我们的转型。数据产品可以用于智能营销、智能风控，可以通过多模型、多维的评分以及风险策略，可以对信用主体以及债项主体进行风险识别。

 

二、信贷业务中台建设的目标

今天的话题着重在信贷业务中台的建设实践。在中台建设实践上，中电金信根据多年行业最佳实践提出了4个关键的建设目标：

首先是避免重复建设。在以往的对公信贷业务过程中，随着业务快速的发展，我们会有对公信贷，也有针对普惠、小企业的，或者针对交易银行领域的，像烟囱式地建设了一系列的围绕对公企业信贷的垂直领域的各类系统。随着这些系统的建设，我们逐渐发现很多的功能其实是重复造轮子，所以建设业务中台就是要避免公共功能重复建设的问题。

二是提升系统稳定性。在中台出现之前，系统基本是单体应用，在整个对公信贷业务全流程的管理过程中，但凡有一个功能模块出现了异常，可能对整体系统的运行都会造成影响。一个需求的上线，不论大小，系统整体都要停机部署。中台的建设可以有效规避这些问题。

三是整体需求的快速响应。在整个信贷业务办理过程中，客户体验需要增强，个性化的需求希望得到快速的响应，这些需求的实现需要产品重新设计，或者对既有产品的调优，甚至还需要去调整机构层级、角色权限、流程、授权授信体系等等。以前的架构设计中没有考虑到领域的划分，业务逻辑的耦合性非常高，牵一发而动全身，没有办法快速响应。

四是提升智能化水平。中台的建设可快速实现业务逻辑与AI能力的有效协同、对接，利用底层AI能力中的OCR、人脸识别、NLP、大数据等能力快速切入场景，提升智能化水平。

 

三、信贷业务中台建设解决方案

基于以上四个目标，我们提出了一套完整的解决方案体系。

一是从架构层面上，采用薄前台、厚中台、稳后台的架构思想。

二是减少重复性建设、优化系统稳定性、提升快速响应，可以采用领域驱动设计的思想，对整个信贷业务的全流程、全生命周期将业务的共性能力抽象沉淀到业务中台。中台不是规划出来的，是将前台的成熟能力，总结建模下沉到中台，赋能前台渠道，当下沉的能力越来越多，越来越强，中台就“大”起来了。我们已经形成了包括客户中心、产品工厂、统一权限、统一流程等各种业务中台的能力中心。中台可以允许多个独立的前台接入，提供信贷全流程的应用服务的功能，逐渐与前台形成良性循环。

三是在整个业务中台建设中，贯彻可配置、低代码的开发原则，包括对页面布局的配置、菜单的配置、业务规则的配置、流程的配置等做到低代码开发，降低了整个系统的建设周期和成本。

四是在以往的架构设计中，前后端是没有分离的，我们希望通过前后端分离的架构体系来保证中台建设的稳定。前端更多关注页面的样式与动态数据的解析和渲染，而后端专注于具体业务逻辑。

接下来，我们近一步对其中的六大关键解决方案进行阐述：

一是实施工艺，通过领域驱动设计对信贷全流程进行业务建模，通过业务建模实现业务模型组件化和模型资产化的能力。

二是渠道介入，快速的接入能力是非常考验中台建设的能力。APP、微信小程序、移动营销平台等渠道都需要可以快速地露出服务，让用户得到完全一样的一致性的体验。

三是能力整合。业务中台的各个能力中心与统一押品系统、统一授信系统、档案影像、内容管理平台这些单品系统要能够实现快速的无缝对接。对接的前提是做好能力边界的划分，中台建设中哪些需要做，哪些可以不做。例如额度中心仅提供授信业务限额管控能力，非授信业务的限额管理不在额度中心。

四是产品工厂，按场景从头梳理和设计了行业最新的、灵活的信贷产品工厂模型，通过模板化、组件化、配置化管理，实现产品的快速设计、复核、测试、审批、装配、部署上线，能够显著缩短新产品上线60%以上的时间，及时响应新的需求。

五是统一流程。可以支持多法人的业务流程跟审批流程的差异化配置，在流程配置过程中也可以提供拥有可视化的操作与良好体验的定制化的流程配置。

六是智数驱动。基于行内外部的数据，实现贷前、贷中、贷后阶段的全流程数字化风控，风控的设计思路为策略和模型相结合。一体化、智能化的控制中心和模型管理平台是实现智数驱动的有效支撑。

 

四、信贷中台业务建设实施方法

领域驱动设计的概念已经提出了18年，是由Eric Evans所写的《Domain Drive Design》提出的，但最近这一两年才开始火起来。主要是因为领域驱动设计不是万能的，有自己擅长的领域，适用于业务复杂度非常高的软件项目。项目处于长期建设期，且未来要形成有核心竞争力的产品体系是非常适用的。如果只是复杂度高，但软件项目是短周期的，只需要实现当期目标，不建议使用，因为DDD在前期的业务建模和服务化设计上的投入成本是非常大的。最近火起来也是因为业务需求逐渐复杂，再加上技术架构日趋成熟，分布式架构，微服务的设计思想也在各个领域得到广泛的应用。结合以上两方面，最近两年领域驱动设计模式通过在互联网公司应用的生根发芽，开始在银行的应用场景中进行兴起。DDD设计中出现了很多专有的术语，理解起来也比较难懂，例如统一语言，界限上下文是比较关键的，还有聚合、实体、值对象、领域服务、领域事件、工厂、存储等等。虽然建模过程需要付出的成本比较大，但我们坚持在一些实际场景中通过领域驱动设计做了一些实际落地的工作。

Eric提出了模型的思想，但是他没有指出通过事件风暴究竟是怎么产生领域模型。我们在实践中不断对Eric的思想进行完善，更具体地体现是往设计层面、落地层面去思考。于是我们提出全局设计的思想，包括价值需求和业务需求。价值需求是指做一个软件项目、一个产品，首先要考虑到它的价值需求，识别利益相关方，例如对公信贷的利益相关方有客户、风险经理、审批人员、贷后操作人员、系统管理员等；接着确定系统目标与愿景，目标是实现整个全流程的线上化快速响应、智能化配置，并且推出有市场竞争力的产品服务；进而确定好系统范围，众所周知信贷领域的IT建设基本都是以系统群的方式进行，所以中台与各个信贷单品系统之间范围的确定是非常关键。

在价值需求明确之后，进入到业务需求分析阶段。确定用户、目标系统与外部系统之间的协作关系，形成业务流程。在业务流程设计过程中，通过用户故事，梳理出业务场景，进而识别领域事件。最终确定目标系统的子领域，包括核心子领域、通用子领域和支撑子领域。需求也分为功能性需求跟非功能性需求，领域驱动更擅长解构功能性需求，而非功能性需求是不在DDD所涉及的领域内。

通过全局设计之后，进入到DDD的设计过程中。DDD 整体设计过程主要包括两个设计和四个关键阶段。两个设计分为战略设计和战术设计，四个阶段分为领域分解、领域建模、微服务设计和详细设计及技术实现。虽然两个设计都很重要，但战略层面上要更加重要，因为业务中台里会建设多个能力中心，每个能力中心会以微服务的形式呈现，服务与服务之间的边界划分，是要完全依托于战略设计把各子域的限界上下文给规划清楚。

我们通过设计用户找到业务场景，通过头脑风暴的方式列出这个领域中的所有的领域事件。领域事件的描述为某个角色向目标系统发出业务请求，可以得到完整的业务交互，实现想要得到的业务价值。识别完领域事件，接着识别出实现领域事件所对应的决策命令，决策命令里包含了多种不同类型的决策发起方，包括用户、相关的系统，规则、事件。再通过决策命令识别出领域名词，通过相关性紧密的领域名称找出聚合，再识别限界上下文，划分出问题子域。从步骤上看似容易操作，但在具体运用过程中存在很多挑战。例如事件风暴是否能对业务场景全覆盖，聚合的大小是否合适、如何划分限界上下文。限界上下文是定义领域边界，以确保每个上下文含义在它特定的边界内都具有唯一的含义，领域模型则存在于这个边界之内。限界上下文是架构的自治单元，具有最小完备、独立进化、自我履行、稳定空间的特点。例如授信审批、放款、贷后管理就可以为不同的限界上下文。当然我们也要考虑限界上下文的数量，一个上下文一般对应一个微服务，微服务的增加带来管理的复杂度也会成倍增强。通过战略设计得到了整个领域模型之后，再去做战术设计，完成代码模型，继而再根据系统现状分析领域划分得是否合理，再对子域进行微调，可以看到战略设计不是一蹴而就，是一种螺旋式的迭代演进的路径。

战术层面的微服务设计要保证与战略层面的业务模型保持一致，这样可以解决了常规产品设计过程中存在两张皮的情况。从业务需求到服务化设计，再到代码开发没有一致性的保证，中间环节出现很多的信息传递的损耗。在DDD的设计过程中，领域专家、设计专家、架构师、需求分析师、测试人员是需要在一起进行战略到战术设计的。通过统一语言的原则保证所有人对业务需求的理解高度一致，在战术层面设计同样遵从统一语言。任何复杂的业务逻辑是通过4层架构实现的。4层架构包括接口层、应用层、领域层、基础设施层。以往常用的三层架构，业务逻辑基本都写在应用层。在DDD中，我们把业务逻辑聚焦在领域层，所有对实体状态的变化，增删改等业务逻辑都写在领域层，实现高度内聚。这样的话应用层就变得很薄，只负责服务跟服务之间的串接和编排，比如授信审批通过之后，要去通知额度系统增加授信额度。这里面有两个事件，先是流程的结束，再是额度生成，事件的通知会放在应用层来处理。接口层是负责向用户显示信息和解释用户指令。这里的用户可能是：用户、程序、自动化测试和批处理脚本等等。

最底层是基础设施层，主要是贯穿所有层的，它的作用就是为其他各层提供通用的技术和基础服务，包括第三方工具、驱动、消息中间件、网关、文件、缓存以及数据库等。比较常见的功能还是提供数据库持久化。比如数据层除了通过传统的关系数据库，还会有NoSQL数据库，Redis这种内存型数据库。业务逻辑实现时，我们不用考虑这些基础服务的变化，通过基础设施层去屏蔽掉复杂性，让领域层高度地关注业务的处理。

 

五、信贷中台开发流程

我们已经把DDD的思想在软件工程实践中进行了践行，形成了一套完整的开发流程体系。其中包括从需求分析开始、提取领域事件、领域建模设计。

透过战略设计到战术设计的分解，领域驱动设计带给我们的价值非常明显了。一是可以提升软件交付的质量，因为所有的分析模型跟设计模型不割裂，大家是在围绕着统一语言的语境下进行工作。同时在四层架构下，所有的从业务需求导向到四层架构，代码的层次性和逻辑性非常清晰，整个代码的交付质量非常高。二是降低维护成本。DDD 的分层架构，有效分离了业务复杂度和技术复杂度，凸显了领域模型，使得领域层的代码和领域模型保持高度一致；DDD 在战术层面提出聚合，实体，值对象，服务，工厂，仓储等模式，对领域模型中的元素进行了分类，明确了职责和特征，从而降低了领域模型的构建成本。三是应对复杂业务。软件人员和业务人员合作来构建领域模型。四是快速响应业务及技术的变化。限界上下文保证了领域范围的隔离。例如由于产品的创新可能带来产品要素的变化就找配置模块，产品上线之后涉及流程调整就找流程中心，规则管理有优化就找规则中心，这样就可以针对业务需求快速地响应，找到对应的微服务设计的领域。

 

六、典型案例介绍

最后展示的是中电金信对公信贷业务中台的整体架构，这是我们为一个头部行通过对公信贷风险管理系统重构中总结出的整体架构。

图1  对公信贷业务中台整体架构

业务中台的建设一般有两套模式，自顶向下和自底向上。如果是建设一个全新的领域，我们会从领域的全局出发，先将全局划分成若干个问题域，再针对每个问题域进行领域事件的拆解，得出领域建模，这就是自顶向下。

对于目前普遍存在需要对现有系统进行重构设计的项目，我们建议可以采用自底向上的做法相对稳妥。首先是针对一般公司业务的信贷全流程当作一个子域进行领域建模，后续再逐步计划将小企业和交易银行业务所对应的系统纳入整体的微服务架构体系。整体架构采用的是前台、中台、后台的模式。对公信贷业务中台通过服务化拆分构建专业化的授信作业、放款作业、贷后处理、资产保全等中台能力中心，并依托产品组件化适配能力装配覆盖对公、普惠、同业等全方位的信贷领域全流程业务解决方案。前台完成统一门户的搭建，解决用户通过统一门户接入之后，无感便捷的在多系统间进行跳转。通过统一门户可以实现不同角色的用户差异化的安排工作界面。在业务中台这块划分了核心域、支撑域和通用域，共计15个能力中心，满足了信贷全流程的业务处理，可以支撑更多样性的金融业务场景。在中台设计中，充分考虑了信贷流程处理与信贷风险管控类单品系统之间强大的对接能力。通过与后台支撑系统之间进行能力对接，数据同步，最终实现信贷全业务周期内的“可见、有用、简单、领先”的先进解决方案。

演讲文稿整理：梁丹辉、庄明晗

责任编辑：傅泽天

来源：TGES2021（第十七届）中国金融风险经理年度总论坛：对公业务与企业融资风险管理（11月）