領域驅動客戶關系定價系統

于少聰， 鄭山紅

(長春工業大學 計算機科學與工程學院， 吉林 長春 130102)

0 引 言

長久以來,在我國利率管控的大環境下，商業銀行在貸款中實行無差異化的統一定價模式，然而,隨著近年來利率市場化進程的不斷推進，傳統的貸款定價方法已無法適應環境變化，急需做出改變。與此同時，更為復雜的業務邏輯也對系統提出了更高要求，傳統單體架構下的老舊系統在響應速度、擴展性以及靈活性等方面遇到了諸多挑戰。

針對上述行業痛點，以及遵循利率市場化的根本要求，提出一種基于成本加成定價法，并與客戶關系理論相結合的貸款定價模型，根據客戶在銀行的歷史業務來往情況給予按比例的利率優惠，通過二者的結合,最終得出差異化的定價結果。

在系統架構方面，以領域驅動設計思想指導微服務邊界的劃分是如今軟件開發最高效的設計模式。系統采用Spring Cloud框架完成微服務的搭建，在服務內使用領域驅動四層架構模式，并將改進的定價模型應用到利率計算中。通過這樣的設計模式，系統達成了高擴展性、敏捷開發以及部署靈活的開發目標。

1 相關技術

1.1 領域驅動設計

領域驅動設計[1](Domain-Driven Design, DDD)是針對復雜性業務邏輯的最佳解決方案，其依靠敏捷開發[2]的手段及模型驅動開發的策略，是一種面向對象[3]的分析與設計思想，由Eric Evans[4]于2003提出。通過將業務邏輯融合進業務實體的形式，使業務發生變化時能以最低成本和最快速度做出響應。其中，DDD通過戰術設計對領域模型進行定義。

1.1.1 實體、值對象

以充血模型的形式，包含唯一識別ID來區分不同實例，實體即可被持久化，同時也包含業務邏輯。值對象中不包含特定標識，生命周期內不可被更改。

1.1.2 聚合、聚合根

聚合作為不同業務邏輯的實體邊界，可由多個實體或單一聚合根構成。作為數據修改的單元需要遵循“聚合內強一致性，聚合外最終一致性”。當外界對聚合進行訪問時需先通過聚合根，繼而實現對聚合內實體的訪問。

1.1.3 領域服務

當單一聚合無法完成業務需求時，可被定義為領域服務，在操作時需要調用并修改多個聚合實例的狀態。

1.1.4 限界上下文

將邊界進行定義，需最大限度保留業務完整性，以及遵循高內聚低耦合的設計原則。限界上下文劃定的業務邊界與微服務的物理邊界相對性。

1.2 微服務

隨著分布式架構的興起，人們提出了微服務[5](Micro-services， MS)的架構方案，通過以物理邊界將業務進行分割的方式，將大而雜的系統拆分為小而精的自治微服務。這樣的架構模式使得系統在搭建時更為靈活，擴展上更為簡單。每個服務都可以獨立進行開發以及部署，并通過組件進行交互，真正實現了敏捷開發與靈活部署的目的。同時微服務架構擁有以下幾大優勢：

1)可由更小的團隊進行開發，僅需少量人員即可完成對其服務模塊的開發；

2)技術異構，不同服務可通過不同的技術來實現，可以按照業務的需求自主選取技術棧對服務進行開發；

3)任意服務發生宕機故障，不會對其余服務產生影響，僅需對故障服務進行定位維護，不影響系統的正常運轉；

4)每個服務可被獨立部署于不同服務器，且配備單獨的數據庫，增強系統的可管理性。

2 基于客戶關系的貸款定價模型

傳統的成本加成定價模型中，通過由定價成本因素組成的保本利率與目標利率共同得出該筆貸款的最終利率，這種做法所帶來的弊端是顯而易見的。即在同一筆業務中，不同類型的人群所得到的利率是相同的，“一刀切”的定價策略導致了商業銀行缺乏市場競爭力，長此以往會導致客戶流失。

因此，基于上述考慮，模型在成本加成定價模型的基礎上，將客戶與銀行的關系引入定價計算模型中，由可被計算的定量優惠以及無法計算的定性優惠兩部分進行綜合考量，得出符合利率市場化要求的差異化利率模型，從而將傳統的做業務模式向“做客戶”進行轉變。

首先在模型中引入經濟附加值[6](Economic Value Added， EVA)的概念，即稅后凈營業利潤中減去股權資本成本和債務資本成本的剩余收益，將客戶的預先存款額所產生的經濟附加值進行計算，作為模型中定量優惠部分。EVA的計算公式為:

EVA存款=(FTP價格-存款利率-運營成本率)*(1-所得稅)*存款金額,

(1)

EVA貸款=(目標利率-FTP價格-運營成本率-風險成本率-資本成本率)*

(1-所得稅)*貸款金額。

(2)

其次，將客戶使用銀行產品的情況以及在CRM客戶關系管理系統中得出的信用等級作為定性優惠部分，對高端客戶給予5BP的利率優惠減免，見表1。

表1 定性優惠表

綜上所述，得出一種基于客戶關系[7]的定價模型，如圖1所示。

圖1 定價模型

其中，運營成本率由銀行內部成本分攤系統計算得出，針對未建成分攤系統的將由手工進行分攤并錄入，公式為：

(3)

風險成本率=違約概率(PD)*違約損失率(LGD)。

(4)

3 系統設計

3.1 領域模型設計

貸款定價模塊是系統的核心模塊，在服務內部采用領域驅動思想指導設計。其中對領域模型的設計尤為關鍵，實施步驟為：

1)根據具體的業務邏輯展開需求分析；

2)對領域模型中的實體、值對象、領域服務等概念進行識別定位；

3)將識別出來的實體和值對象進行關聯匹配；

4)劃分出聚合的具體范圍,以及確定聚合中的聚合根。

本節將以定價服務為例，通過四步走的方式對領域模型[9]進行設計。

聚合的劃分遵循Vaugh Vernon的聚合劃分原則如下：

1)將真正不變的條件封裝進聚合;

2)設計小的聚合;

3)聚合間通過唯一識別ID進行關聯、引用;

4)根據業務邏輯，將聚合進行組裝,繼而劃定限界上下文范圍，構成微服務的物理邊界。

3.1.1 需求分析

定價模塊負責貸款利率的計算。主要包括客戶經理對貸款基本信息以及抵押品的錄入，對貸款實施定價，計算優惠利率及RAROC值等，輸入執行利率反算NI、EVA、RAROC等，如圖2所示。

圖2 定價模塊用例圖

3.1.2 領域模型設計

通過需求分析，可以得到貸款信息、抵押品、定價結果、定價單四個實體。根據Vaugh Vernon的聚合劃分原則，貸款信息與抵押品實體分別負責貸款信息以及抵押品的錄入，且具有唯一識別ID，因此分別作為聚合根獨立構成聚合。由于定價單需要在定價結果實體中獲取部分數據，沒有定價結果也就無法生成定價單，且定價結果中含有定價單號作為唯一識別ID，因此定價結果作為聚合根與定價單實體屬于同一聚合。領域模型如圖3所示。

將聚合定義完成后，通過限界上下文的劃分規則與業務獨立性的根本要求，貸款信息聚合、抵押品聚合與定價聚合共同完成了貸款定價功能，構成了貸款定價子域，同屬一個限界上下文。

3.2 系統架構

3.2.1 整體架構

微服務下的客戶關系定價系統中，整體架構[8]如圖4所示。

圖4 系統架構

系統選用Alibaba開源組件Nacos作為服務的注冊與配置中心，負責系統的環境配置，以及服務的發現與注冊。選用Zuul組件作為API網關，負責接受用戶請求，并聯合負載均衡向服務端發送用戶請求。使用Spring Cloud框架中集成的Ribbon組件，實現請求轉發的負載均衡。使用Apache的slf4j+log4j組件對微服務日志進行管理，使用Spring Boot Admin組件實現服務的實時監控。

微服務集群中由管理員方的授權服務以及機構管理服務構成，用戶方由客戶管理服務、定價服務、參數管理服務、審批服務組成。使用Feign組件完成服務的遠程調用。選用MySQL數據庫，通過Mybatis-plus框架對數據進行持久化。

3.2.2 技術架構

為了達到隔離業務邏輯的目的，以及遵循高內聚低耦合的設計原則，系統選用領域驅動的四層架構模型作為客戶關系定價系統的技術架構，如圖5所示。

圖5 技術架構

3.2.2.1 接口層

接口層是架構設計中最頂端的一層，作為用戶與系統間溝通的門戶，負責對外展示后端處理的數據，以及接受用戶請求進行對內的轉發。使用Vue框架負責前端界面的編寫以及界面邏輯處理工作。

3.2.2.2 應用層

應用層在四層中是最簡單且直接的一層，體量最薄，起到協調接口層與領域層的作用。其中包含應用服務，領域層中的業務邏輯通過應用服務向外暴露，負責對不同業務用例之間執行順序的編排與組裝。

3.2.2.3 領域層

領域層處于架構的最核心位置，領域驅動設計要求設計富領域模型，定義了聚合,包括聚合根、實體以及值對象，并對領域服務進行封裝，通過對聚合的調用完成具體業務邏輯的實現。該層還對倉儲接口進行了定義，用來對基礎設置層的倉儲進行調用。

3.2.2.4 基礎設施層

在基礎實施層中包含Zuul網關以及Ribbon負載均衡組件，通過二者可以實現消息傳遞、動態路由轉發以及負載均衡。同時倉儲服務的實現類與領域層倉儲接口對應，負責對持久化對象增刪改查功能的實現。另外，該層還含有MySQL數據庫用于數據的存儲工作。

3.2.3 業務架構

通過領域驅動設計與微服務結合的相關理論，以及對系統服務職責單一性的設計原則兩方面的共同考慮，對微服務進行了業務劃分，系統的業務架構如圖6所示。

圖6 業務架構

4 系統實現

4.1 開發環境

隨著技術更新以及定價業務模型的迭代改進，傳統老舊系統的開發環境已經無法適應新一代系統對于性能與架構方面的需求，以及滿足貸款業務的支撐，因此，針對原有的開發環境做出一定的改變，具體環境配置見表2。

表2 系統開發環境

4.2 功能實現

在定價服務中實現了貸款信息以及抵押品的錄入、客戶目標利率、利率優惠等的計算、輸入執行利率進行反算NI、EVA、RAROC等功能。在基礎結構層中使用倉儲服務，將數據進行持久化操作。領域層中通過領域服務將業務邏輯進行封裝，通過應用層的應用服務將領域層提供的接口進行編排組合，實現系統功能。最終在接口層為前端界面提供相關接口。

用戶進行貸款定價操作，進入定價流程后。第一步，調用addLnInfoAppService完成該名客戶貸款信息的填寫；第二步，調用addMortgageAppService完成對該筆貸款所需要的質押品信息進行輸入；第三步，通過調用參數管理服務數據庫表中的參數數據，完成保本利率、目標利率、目標EVA與RAROC的計算。公式為：

目標利率=資金成本率+運營成本率+違約概率×違約損失率+資本成本率+

增值稅+附加稅+所得稅+目標收益率,

(5)

目標EVA=(目標利率-貸款FTP價格-運營成本率-風險成本率-資本成本率)×

(1-所得稅)×規模,

(6)

(7)

利率優惠=[(存款FTP價格-存款利率-運營成本率)×(1-所得稅)×存款金額+

(目標利率-FTP價格-運營成本率-風險成本率-資本成本率)×

(1-所得稅)×貸款金額]×α-定性優惠減免。

(8)

當貸款利率計算完畢后，輸入LPR基準利率與執行利率，分別計算該利率下的NI、EVA、RAROC[6]值以及利率浮動比例，如圖7所示。

圖7 定價計算

計算公式為：

(9)

執行NI=(執行利率-貸款FTP價格)×

金額×期限。

(10)

5 結 語

以利率市場化作為研究背景，抓住商業銀行貸款定價業務的痛點，提出一種基于客戶關系的貸款利率計算模型，在一定程度上實現了貸款利率差異化區分的目標。

在系統的搭建上，以業務需求為核心，以領域驅動設計思想為方法論，對業務進行領域模型設計。架構上通過引入微服務框架，渾然天成的將領域驅動設計出的邏輯邊界與微服務的物理邊界相對應，此外通過服務注冊、服務網關、負載均衡等組件，對系統的運行提供支持。綜上所述，通過對定價模型的再設計，以及系統架構重構，緩解了單體架構下系統擴張難、維護難的實際問題，基本上做到了可用性及合理性。