【文章內(nèi)容簡(jiǎn)介】 在賬務(wù)核算層中的功能，用于為沒有核心業(yè)務(wù)系統(tǒng)的金融機(jī)構(gòu)，提供一個(gè)Mini版的核心業(yè)務(wù)系統(tǒng)，其只含貸款功能，不含存款功能（注：與銀監(jiān)管會(huì)相關(guān)策略吻合）。其能完成貸款發(fā)放、還款扣款、罰息減免、貼息處理、減值計(jì)提、貸款形態(tài)轉(zhuǎn)移等基礎(chǔ)的賬務(wù)核算功能。由于不是所有金融機(jī)構(gòu)都沒有核算系統(tǒng)，所以將本層獨(dú)立出來(lái)，保持其與它層次間的獨(dú)立性，有利用增強(qiáng)產(chǎn)品的適應(yīng)能力。l 技術(shù)支撐層技術(shù)支撐層，用于為消費(fèi)貸系統(tǒng)提供基礎(chǔ)開發(fā)平臺(tái)與運(yùn)行容器，是所有業(yè)務(wù)功能落地的基石。其中包含的EMP容器、流程引擎、規(guī)則引擎、報(bào)表引擎與數(shù)據(jù)訪問工具等等。本層將在后繼章節(jié)進(jìn)行詳細(xì)介紹。 功能層次關(guān)系 消費(fèi)貸款系統(tǒng)中六層功能之間是一個(gè)逐層依賴的關(guān)系，如下圖所示：圖35消費(fèi)貸系統(tǒng)本質(zhì)上是一個(gè)業(yè)務(wù)操作系統(tǒng)，業(yè)務(wù)操作層自然便成為了整個(gè)系統(tǒng)的主要門戶，是所有業(yè)務(wù)的入口。業(yè)務(wù)的正常運(yùn)營(yíng)，離不開業(yè)務(wù)管理部門（風(fēng)控部門）的管控，與專業(yè)部門（例如，財(cái)務(wù)部門、產(chǎn)品部門、客服部門、IT部門等等）的大力支持。因此，業(yè)務(wù)操作層依賴與業(yè)務(wù)管理層、業(yè)務(wù)工具層、賬務(wù)核算層以及技術(shù)支撐層。業(yè)務(wù)管理部門為了能更好的對(duì)業(yè)務(wù)進(jìn)行管控，也需要專業(yè)部門（如產(chǎn)品部門、財(cái)務(wù)部門、IT部門等等）的積極配合。因此，業(yè)務(wù)管理層依賴與業(yè)務(wù)工具層、賬務(wù)核算層與技術(shù)支撐層。金融機(jī)構(gòu)財(cái)部門是一個(gè)相對(duì)獨(dú)立的部門，其完全依照財(cái)務(wù)規(guī)章制度運(yùn)行，一般而言，其運(yùn)營(yíng)主要有IT部門的支持即可；同時(shí)，由于不是所有金融機(jī)構(gòu)都需要消費(fèi)貸系統(tǒng)提供核算功能，這就需要盡量保證其獨(dú)立性，因此，賬務(wù)核算層，只需要依賴技術(shù)支撐層。決策分析主要是針對(duì)數(shù)據(jù)的統(tǒng)計(jì)分析，因此，其僅僅依賴與技術(shù)支撐層，而對(duì)于其它功能層次，也均不直接依賴于決策分析層。 系統(tǒng)技術(shù)架構(gòu) 子系統(tǒng)劃分消費(fèi)貸系統(tǒng)按功能職責(zé)劃分成四個(gè)子系統(tǒng)——消費(fèi)貸款管理系統(tǒng)、消費(fèi)貸款合作方系統(tǒng)、消費(fèi)貸款核算系統(tǒng)、消費(fèi)貸輔助系統(tǒng)，如下圖所示： 圖36l 消費(fèi)貸款管理子系統(tǒng)消費(fèi)貸款管理子系統(tǒng)，主要面向金融機(jī)構(gòu)內(nèi)部的客戶經(jīng)理以及相關(guān)管理人員，負(fù)責(zé)完成消費(fèi)貸款進(jìn)件流程與業(yè)務(wù)管理。其中包含了邏輯架構(gòu)中的業(yè)務(wù)操作層、業(yè)務(wù)管理層、業(yè)務(wù)工具層中的絕大部分功能（注：不含操作層中的合作方功能），例如，貸款申請(qǐng)、人工審批、合同管理、放款等等。消費(fèi)貸款管理子系統(tǒng)是整個(gè)系統(tǒng)業(yè)務(wù)運(yùn)營(yíng)的核心系統(tǒng)。l 消費(fèi)貸款合作方子系統(tǒng)消費(fèi)貸款合作方子系統(tǒng)，主要面向金融機(jī)構(gòu)之外的合作機(jī)構(gòu)，如賣場(chǎng)、4S店、培訓(xùn)機(jī)構(gòu)等等，其負(fù)責(zé)為合作方與金融機(jī)構(gòu)之間建立渠道與門戶。其主要功能是進(jìn)件處理與審批狀態(tài)查詢。之所以將合作方獨(dú)立成子系統(tǒng)，首先，是出于金融機(jī)構(gòu)與合作方之間合作方式存在不確因素的考慮，例如，現(xiàn)在是對(duì)賣廠、對(duì)4S店，但今后可能會(huì)對(duì)網(wǎng)店、對(duì)PAD、對(duì)外包公司等等，因此將合作方的功能獨(dú)立出核心業(yè)務(wù)系統(tǒng)，作為系統(tǒng)對(duì)外擴(kuò)展的網(wǎng)關(guān)，會(huì)有利于消費(fèi)貸的不斷發(fā)展；其次，是出于安全方面考慮，由于需要直接面對(duì)互聯(lián)網(wǎng)，所以必須將對(duì)外的功能獨(dú)立部署，屏蔽任務(wù)從互聯(lián)網(wǎng)上直接訪問至核心業(yè)務(wù)系統(tǒng)的渠道。l 消費(fèi)貸款核算子系統(tǒng)消費(fèi)貸款核算子系統(tǒng)，主要面向金融機(jī)內(nèi)部的賬務(wù)人員，負(fù)責(zé)完成所有與貸款相關(guān)的賬務(wù)處理，如貸款發(fā)放、還款扣款、罰息減免等等，其與邏輯架構(gòu)中的賬務(wù)核算層相對(duì)應(yīng)。獨(dú)立的核算子系統(tǒng)，有利于增強(qiáng)系統(tǒng)的適應(yīng)能力。l 消費(fèi)貸款輔助子系統(tǒng)消費(fèi)貸款輔助子系統(tǒng)，主要負(fù)責(zé)完成數(shù)據(jù)加工與分析、定時(shí)任務(wù)調(diào)度、報(bào)表生成與展示、歷史數(shù)據(jù)查詢等后臺(tái)任務(wù)。之所以劃分出輔助子系統(tǒng)，主要是出于對(duì)系統(tǒng)性能的考慮，通過獨(dú)立部署的子系統(tǒng)來(lái)完成后臺(tái)任務(wù)，避免后臺(tái)任務(wù)對(duì)日間業(yè)務(wù)運(yùn)行效率產(chǎn)生不良影響。l 子系統(tǒng)間依賴關(guān)系消費(fèi)貸款四子系統(tǒng)之間的依賴關(guān)系如下圖所示：圖37合作方子系統(tǒng)的運(yùn)作必須依賴與管理子系統(tǒng)的支持，合作方子系統(tǒng)負(fù)責(zé)對(duì)外渠道，其獨(dú)立運(yùn)行沒有任何意義，需要通過管理子系統(tǒng)來(lái)完成對(duì)每筆進(jìn)單的業(yè)務(wù)處理。管理子系統(tǒng)的運(yùn)作，需要有核算系統(tǒng)的配合，核算系統(tǒng)可以是消費(fèi)貸系統(tǒng)內(nèi)嵌的核算子系統(tǒng)，也可以是機(jī)構(gòu)內(nèi)的核心業(yè)務(wù)系統(tǒng)。管理子系統(tǒng)通過核算子系統(tǒng)完成所有貸款賬務(wù)相關(guān)的業(yè)務(wù)操作。輔助子系統(tǒng)的運(yùn)行，需要依賴管理子系統(tǒng)、核算子系統(tǒng)的正常運(yùn)行，輔助子系統(tǒng)用作消費(fèi)貸系統(tǒng)的后臺(tái)處理單元，其獨(dú)立運(yùn)行沒有任何意義，需求通過調(diào)用管理子系統(tǒng)與核算子系統(tǒng)中的業(yè)務(wù)功能來(lái)實(shí)現(xiàn)自身功能。 技術(shù)選型消費(fèi)貸系統(tǒng)是基于JaveEE的WEB應(yīng)用，其后臺(tái)技術(shù)框架采用公司EMP實(shí)現(xiàn)，前臺(tái)業(yè)務(wù)展現(xiàn)框架基于Jquery+EasyUi實(shí)現(xiàn)，具體如下圖所示：圖38消費(fèi)貸系統(tǒng)基礎(chǔ)支撐環(huán)境為JavaEE以及在此之上的WEB容器中間件（如WAS、Weblogic等等），（含），對(duì)Weblogic版本要求為10g以上（含）。，；業(yè)務(wù)處理邏輯實(shí)現(xiàn)，采用組件注入機(jī)制與POJO為業(yè)務(wù)數(shù)據(jù)結(jié)構(gòu)方式；業(yè)務(wù)展現(xiàn)邏輯基于Jquery實(shí)現(xiàn)，頁(yè)面部件基于EasyUI實(shí)現(xiàn)，并用Jsp Tag包裝，前后臺(tái)通訊有使用Ajax方式。業(yè)務(wù)邏輯處理沒有選用EMP提供的標(biāo)準(zhǔn)開發(fā)方式實(shí)現(xiàn)（邏輯流+KCOL），而是選擇了組件+Pojo方式實(shí)現(xiàn)，由其是在數(shù)據(jù)結(jié)構(gòu)上不再使用EMP的KCOL，而是選擇傳統(tǒng)的Pojo方式。這是因?yàn)椋Ｍㄟ^功能組件+Pojo方式來(lái)實(shí)現(xiàn)面向?qū)ο笤O(shè)計(jì)思路，不再去走面向過程+快捷開發(fā)的老路。這是因?yàn)橄M(fèi)貸系統(tǒng)是業(yè)務(wù)操作類系統(tǒng)，其中的業(yè)務(wù)運(yùn)行模式、信息結(jié)構(gòu)都是具有積累價(jià)值的，所以可以用面向?qū)ο蟮脑O(shè)計(jì)思路，將業(yè)務(wù)模式轉(zhuǎn)換成技術(shù)框架，將業(yè)務(wù)功能包裝成一個(gè)個(gè)組件，將業(yè)務(wù)要素信息映射成數(shù)據(jù)對(duì)象，最終，達(dá)到提升系統(tǒng)可復(fù)用性與產(chǎn)品形態(tài)的目地。 技術(shù)架構(gòu)分層消費(fèi)貸系統(tǒng)技術(shù)架構(gòu)上劃分為四個(gè)層次——業(yè)務(wù)展現(xiàn)層、服務(wù)提供層、業(yè)務(wù)組件層、持久層。技術(shù)架構(gòu)層次劃分如下圖所示：圖39l 業(yè)務(wù)展現(xiàn)層業(yè)務(wù)展現(xiàn)層負(fù)責(zé)消費(fèi)貸系統(tǒng)與用戶之間的交互接口，在這一層中的業(yè)務(wù)邏輯處理統(tǒng)一由JS負(fù)責(zé)實(shí)現(xiàn)，不會(huì)出現(xiàn)其它形式業(yè)務(wù)邏輯處理（如，JAVA代碼）。無(wú)論在邏輯處理時(shí)，還是加載后臺(tái)數(shù)據(jù)時(shí)，還是向后臺(tái)發(fā)送請(qǐng)求時(shí)，其數(shù)據(jù)結(jié)構(gòu)統(tǒng)一使用JSON格式。l 服務(wù)提供層服務(wù)提供層負(fù)責(zé)將系統(tǒng)內(nèi)的功能組裝成獨(dú)立事務(wù)的原子服務(wù)，并以此為單位響應(yīng)來(lái)至展現(xiàn)層（或來(lái)至其它渠道，如SOCKET、WEBSERVICE）的服務(wù)請(qǐng)求。這里提到的服務(wù)，并不是指通常概念中的服務(wù)，其主要是指系統(tǒng)內(nèi)部暴露給其用戶的功能，當(dāng)然，完全可以將其中的一部分功能，通過各種渠道發(fā)布給其它系統(tǒng)使用，此時(shí)其才是真正意義上的服務(wù)，這里只是借用并擴(kuò)展了服務(wù)這個(gè)概念，將系統(tǒng)提供給用戶的功能也認(rèn)為是一種服務(wù)，確切地說(shuō)是細(xì)粒度的原子服務(wù)。在服務(wù)提供層中，通過對(duì)組合對(duì)業(yè)務(wù)組件層中組件的調(diào)用來(lái)實(shí)現(xiàn)服務(wù)功能，服務(wù)層中的每個(gè)服務(wù)對(duì)應(yīng)著一個(gè)業(yè)務(wù)操作，其名稱都應(yīng)該是一個(gè)動(dòng)詞，表示一個(gè)業(yè)務(wù)過程的業(yè)務(wù)操作（如，發(fā)起申請(qǐng)、合同簽訂等等）。同時(shí)，在本層中還負(fù)責(zé)將從展現(xiàn)層（或渠道）過來(lái)的EMP KCOL格式的業(yè)務(wù)數(shù)據(jù)轉(zhuǎn)換成POJO格式的數(shù)據(jù)。l 業(yè)務(wù)組件層業(yè)務(wù)組件層負(fù)責(zé)對(duì)業(yè)務(wù)功能進(jìn)行劃分、封裝與實(shí)現(xiàn)，組件層為服務(wù)層提供功能實(shí)現(xiàn)層面的支撐。其中以組件為單位對(duì)業(yè)務(wù)功能進(jìn)行組織，每個(gè)組件有著明確的業(yè)務(wù)含意，其在概念上與參與業(yè)務(wù)過程的業(yè)務(wù)實(shí)體基本一致，每個(gè)組件的名稱都是一個(gè)業(yè)務(wù)名詞，表示一個(gè)業(yè)務(wù)過程中的業(yè)務(wù)實(shí)體（如，客戶、合同、耐用消費(fèi)品貸款產(chǎn)品等等）。在本層中的各個(gè)業(yè)務(wù)組件內(nèi)，一律使用POJO為業(yè)務(wù)邏輯處理時(shí)的數(shù)據(jù)結(jié)構(gòu)。l 持久層持久層負(fù)責(zé)實(shí)現(xiàn)消費(fèi)貸系統(tǒng)對(duì)數(shù)據(jù)庫(kù)的訪問與操作。在持久層中一律使用POJO為數(shù)據(jù)邏輯處理時(shí)的數(shù)據(jù)結(jié)構(gòu)。l 各層間關(guān)系四個(gè)層次之間類的關(guān)系如下圖所示：圖310展示現(xiàn)層通過HTTP請(qǐng)求方式調(diào)用后臺(tái)服務(wù)層提供的服務(wù)，此時(shí)請(qǐng)求報(bào)文為標(biāo)準(zhǔn)的HTTP報(bào)文格式，且報(bào)文中的內(nèi)容也是標(biāo)準(zhǔn)的FORM格式（示例：Key1=Val1amp。Key2=Val2amp?！笈_(tái)服務(wù)層返回至界面的數(shù)據(jù)內(nèi)容則為直接為JSON格式。后臺(tái)服務(wù)通過EMPRequestServlet接收請(qǐng)求（此處省略了對(duì)EMP框架內(nèi)部處理描述），接收后通過抽像類CMISOperation來(lái)調(diào)用對(duì)應(yīng)的具體服務(wù)實(shí)現(xiàn)功能OP；在OP中將KCOL通過特定方法轉(zhuǎn)成Domain類（POJO格式），然后根據(jù)業(yè)務(wù)邏輯處理的需要來(lái)調(diào)用具體的組件類；在組件類中將不再使用KCOL格式的數(shù)據(jù)來(lái)處理業(yè)務(wù)邏輯，在組件類中直接調(diào)用持久層CMISDao中公共類SqlClient，完成系統(tǒng)內(nèi)最基礎(chǔ)的數(shù)據(jù)操作；在持久層中也將不再處理KCOL格式的數(shù)據(jù)，而直接使用Domain格式數(shù)據(jù)來(lái)操作數(shù)據(jù)庫(kù)。 關(guān)鍵技術(shù)點(diǎn) 數(shù)據(jù)庫(kù)訪問在數(shù)據(jù)庫(kù)訪問層面，我們總結(jié)了在項(xiàng)目開發(fā)過程中使用基礎(chǔ)框架遇到的問題，并考慮客戶一些建議，對(duì)EMP中的數(shù)據(jù)訪問層進(jìn)行了設(shè)計(jì)重構(gòu)。 首先，存在的問題我們歸納為下表：序號(hào)問題描述1不支持復(fù)雜的自定義SQL的執(zhí)行, 二次開發(fā)人員只得另行編寫數(shù)據(jù)訪問層，最終導(dǎo)致系統(tǒng)數(shù)據(jù)訪問接口不統(tǒng)一、混亂，不利于問題排查和日后維護(hù)。2不支持使用普通的業(yè)務(wù)實(shí)體對(duì)象進(jìn)行數(shù)據(jù)傳輸：EMP中的TableModelDao只支持KeyedCollection和IndexedCollection這樣動(dòng)態(tài)存儲(chǔ)結(jié)構(gòu)的數(shù)據(jù)傳輸，雖然靈活，但是數(shù)據(jù)存取不明確，一旦有問題，不利于排查。3不支持批量執(zhí)行SQL，導(dǎo)致項(xiàng)目開發(fā)人員在開發(fā)過程中編寫了大量循環(huán)操作數(shù)據(jù)庫(kù)的代碼，對(duì)系統(tǒng)性能影響較大。4依賴配置文件實(shí)現(xiàn)ORM映射關(guān)系，這樣導(dǎo)致系統(tǒng)配置文件過多，使系統(tǒng)文件的維護(hù)過于繁瑣；另外，一個(gè)ORM配置文件對(duì)應(yīng)一個(gè)表的僵化映射關(guān)