無論銀行規(guī)模大小、類型如何，當(dāng)你真正面對銀行系統(tǒng)建設(shè)時，不可避免的需要接觸銀行后臺諸多系統(tǒng)，典型的有如：銀行主機(jī)前置、信用卡前置、積分系統(tǒng)、CIM、支付系統(tǒng)、短信平臺、郵件平臺、賬單系統(tǒng)、反洗錢、歷史庫等。各系統(tǒng)提供的功能接口從三五個到上百個不等，隨便哪個銀行都能給你翻出成百上千個后臺接口服務(wù)，他們各自提供某個局部信息和能力，這些接口文檔如果打印出來，通常夠得上幾本名著的厚度。

　　令人沮喪的是，每個后臺系統(tǒng)所使用的通訊標(biāo)準(zhǔn)和接口標(biāo)準(zhǔn)各不相同。許多銀行會建設(shè)接口服務(wù)總線，將眾多的接口在一個統(tǒng)一平臺上集中提供，但這仍然無法掩蓋這龐大的接口群帶來的業(yè)務(wù)理解上的困難和壓力，找到一個精通整個信息和業(yè)務(wù)體系的人或團(tuán)隊通常非常困難，一般項目推進(jìn)的有效手段是找一個或者若干個了解項目需求的專家，針對當(dāng)前項目所需的范圍進(jìn)行專門地解讀。

　　但更令人沮喪的是，為了實施項目，找了多位業(yè)務(wù)專家培訓(xùn)講解，好不容易對某個領(lǐng)域有了不錯的熟悉和掌握，一旦出現(xiàn)工作變動，這些成果卻很難傳承。也許您會覺得使用更好的項目管理和配置管理機(jī)制可以增強(qiáng)這一知識傳承，但是這種工作標(biāo)準(zhǔn)和投入是非常高的，通常在有限成本壓力內(nèi)很難如愿。這種困難甚至?xí)�出現(xiàn)在同一個項目內(nèi)部：因為進(jìn)度壓力，分工實施的2個開發(fā)人員，需要分別學(xué)習(xí)理解領(lǐng)域內(nèi)的信息，他們可能使用的是完全相同的過程域信息，卻同時發(fā)明了2項成果，甚至他們交付的結(jié)果都不一致。

　　總之，一個銀行的業(yè)務(wù)體系非常龐大，學(xué)習(xí)和理解這個體系，或者在項目中運用，其繁瑣和復(fù)雜程度非常高，而且容易產(chǎn)生知識的失傳。

　　對于呼叫中心而言，最典型的應(yīng)用場景是座席工作臺中大量的代客交易，以及IVR等自助系統(tǒng)的代客交易。本文針對呼叫中心的這些相關(guān)應(yīng)用，嘗試使用領(lǐng)域驅(qū)動設(shè)計的方法，為大家呈現(xiàn)如何快速高效地構(gòu)建這些應(yīng)用，以支持銀行IT系統(tǒng)的持續(xù)建設(shè)。

　　方案主要由兩部分組成：客戶視圖和工作臺實現(xiàn)

　　其中又以客戶視圖最為關(guān)鍵，它是設(shè)計的核心，領(lǐng)域驅(qū)動設(shè)計的關(guān)鍵實踐，工作臺和IVR代客交易是建立在客戶視圖之上的應(yīng)用，本文將借由工作臺闡述客戶視圖對于業(yè)務(wù)開發(fā)的增益以及工作臺的推薦設(shè)計方案。

總體方案圖

　　客戶視圖的設(shè)計基于這樣一個假設(shè)：銀行客戶的所有信息能夠基于單一主鍵（通常為客戶號）為原點，直接或者間接地挖掘（透過交易查詢）。

　　將所有的客戶信息在一個二維平面上從原點出發(fā)，以有向圖的方式將所有客戶信息組織成一顆巨大的信息樹。

　　客戶信息樹之所以定義為有向圖，是因為所有的信息最終都會來源于銀行后端各系統(tǒng)的查詢接口，查詢就需要輸入項，這些輸入項是從原點提供或者基于原點查詢得到的信息，不斷地衍生查詢繼而填充整棵信息樹。

　　客戶信息樹的主要目的是通過一個原點信息的牽引就能夠獲得該客戶的所有相關(guān)信息，并且可獲得信息的定義是運行時可列舉（反射）的，同時業(yè)務(wù)開發(fā)團(tuán)隊完全不用關(guān)心這些數(shù)據(jù)的來源。

　　客戶視圖將銀行的業(yè)務(wù)系統(tǒng)建設(shè)從根本上分為兩層，向下表達(dá)了銀行有哪些信息，向上為業(yè)務(wù)系統(tǒng)定義了能獲得什么信息。與客戶需求形成對標(biāo)，將信息來源與客戶需求進(jìn)行對接就完成了功能需求梳理。

　　一次性將整個客戶信息樹加載完成并不現(xiàn)實，也不需要。那么懶加載的設(shè)計必不可少，因此，客戶視圖的每一個節(jié)點都包含一個額外的定義：是否已裝載，每當(dāng)應(yīng)用系統(tǒng)嘗試get視圖中的某個局部信息時，視圖模塊將自動識別加載狀態(tài)，如果已加載則直接提供，如果未加載則觸發(fā)相應(yīng)的接口請求，并在完成請求后填充信息并返回。

　　每次觸發(fā)了查詢后，并不是只填充當(dāng)前get的字段，而是將該接口所能提供的信息都映射在客戶信息樹上進(jìn)行填充。

　　懶加載的整體機(jī)制對上層業(yè)務(wù)應(yīng)用是透明的，業(yè)務(wù)系統(tǒng)并不關(guān)心加載機(jī)制。同時客戶信息樹會進(jìn)行緩存，盡可能地根據(jù)信息時效性降低重復(fù)查詢的幾率。

　　為了應(yīng)對某些時效敏感型的需求，也允許在獲取信息時強(qiáng)行指定reload，以迫使信息樹重新裝載所需信息，確保信息的時效性。比如變更類交易的許多前提查詢通常要求立即查詢，而不建議使用緩存。

　　這里說的數(shù)據(jù)字典并非枚舉類型，枚舉類型的問題在下一節(jié)有專門解釋。這里的數(shù)據(jù)字典單指業(yè)務(wù)字段的命名。

　　單純的字段命名，并沒有多大的討論意義，數(shù)據(jù)字典的實際目的是合并業(yè)務(wù)信息，典型的比如：兩個渠道返回的各自的字段，其字段名稱，相關(guān)描述均不相同，但通過業(yè)務(wù)分析后，識別得出它們是意義完全相同的字段，那么業(yè)務(wù)梳理時將它們在信息樹上映射為同一個字段。

　　數(shù)據(jù)字典的命名功能也從一定程度上規(guī)范化業(yè)務(wù)字段名及其解釋，以幫助應(yīng)用需求分析和開發(fā)人員更容易理解和使用。

　　數(shù)據(jù)字典的定義在技術(shù)上并沒有多少投入，仍然是信息樹上的內(nèi)外字段映射，并建議形成具有業(yè)務(wù)含義的命名解釋。但數(shù)據(jù)字典卻恰恰是整個業(yè)務(wù)梳理中最困難的部分，也是整個業(yè)務(wù)體系理解程度的最高要求和標(biāo)志。

　　一個令人崩潰的問題是：某些業(yè)務(wù)功能可能會跨多個銀行后臺渠道，但這些渠道之間的某些業(yè)務(wù)枚舉的定義并不一致。例如：

　　相信項目團(tuán)隊看到這個情況，心里是崩潰的，即使是前面說的業(yè)務(wù)專家，也最多只能夠幫助你梳理每個渠道之間枚舉項的映射關(guān)系，如果這種轉(zhuǎn)換只發(fā)生一次還能勉強(qiáng)接受，但可悲的是這種轉(zhuǎn)換映射發(fā)生在每兩個渠道之間，次數(shù)是N*(N-1)，一旦涉及到的渠道增多，這就完全變成一個不可能完成的任務(wù)。

　　從客戶視圖的角度來看，客戶信息樹是業(yè)務(wù)需求和信息供給側(cè)的中間切面，參考這一格局，則枚舉的相關(guān)問題也應(yīng)該是在視圖層決定所有枚舉的標(biāo)準(zhǔn)定義，并與所有銀行后端的枚舉進(jìn)行映射，上層應(yīng)用只使用標(biāo)準(zhǔn)枚舉定義進(jìn)行溝通和開發(fā)。這個設(shè)計產(chǎn)生的枚舉轉(zhuǎn)換次數(shù)始終小于等于N（如果渠道的枚舉定義與標(biāo)準(zhǔn)枚舉相同則不需要執(zhí)行轉(zhuǎn)換），并且所有的轉(zhuǎn)換只發(fā)生在與后端接口通訊過程中。

　　這里給出一種通過xml配置加Java注解的方式實現(xiàn)枚舉的自動翻譯，僅供參考：

　　dict-std.xml（標(biāo)準(zhǔn)枚舉定義，全局唯一）：

　　<？xmlversion="1.0"encoding="UTF-8"？>

　　<dicttitle="標(biāo)準(zhǔn)字典"desc=""stdInstead="true">

　　<enumname="sex"title="性別"desc=""stdInstead="true">

　　<itemstd="0"locale="0"title="未知的性別"desc=""/>

　　<itemstd="1"locale="1"title="男性"desc=""/>

　　<itemstd="2"locale="2"title="女性"desc=""/>

　　<itemstd="9"locale="9"title="未說明性別"desc=""/>

　　</enum>

　　</dict>

　　dict-dialect-test.xml（某個方言：test）：

　　<？xmlversion="1.0"encoding="UTF-8"？>

　　<！-- 以下配置在標(biāo)準(zhǔn)字典中無效 (就給懶人復(fù)制的時候方便) -->

　　<！-- /dict/enum/item/locale 方言值，標(biāo)準(zhǔn)字典不適用該配置，只會使用std配置 -->

　　<！-- /dict/@stdInstead 默認(rèn)：false 繼承機(jī)制定義，當(dāng)方言中未配置該枚舉類型時，是否使用標(biāo)準(zhǔn)字典的定義(繼承配置時，方言值和標(biāo)準(zhǔn)值相同)，配置為不替代時未命中的項目會拋出異常 -->

　　<！-- /dict/enum/@stdInstead 默認(rèn)：false 繼承機(jī)制定義，當(dāng)方言中未配置該枚舉項目時，是否使用標(biāo)準(zhǔn)字典的定義(繼承配置時，方言值和標(biāo)準(zhǔn)值相同)，配置為不替代時未命中的項目會拋出異常 -->

　　<dicttitle="標(biāo)準(zhǔn)字典"desc=""stdInstead="true">

　　<！-- 順序敏感性聲明：item配置std，locale單方面或都重復(fù)時，順序靠前的生效 -->

　　<enumname="sex"title="性別"desc=""stdInstead="false">

　　<itemstd="1"locale="M"title="男"desc=""/>

　　<itemstd="2"locale="F"title="女"desc=""/>

　　</enum>

　　</dict>

　　Customer.java（實體字段使用注解綁定）：

　　@Enum("sex")

　　private String sex；

　　該方案允許需求分析人員以非開發(fā)的方式，直接定義標(biāo)準(zhǔn)枚舉字典，以及各渠道的方言定義，方言中的每一選項都必須與標(biāo)準(zhǔn)枚舉字典的一項映射，允許多對一映射，但某個方向上的翻譯出現(xiàn)多個選項時，優(yōu)先使用靠前的項目。

　　開發(fā)中，只需要在渠道接口的實體定義相應(yīng)字段上使用注解進(jìn)行標(biāo)注，那么向后發(fā)送交易時，交易模塊將自動執(zhí)行注解處理器完成相應(yīng)方向上的轉(zhuǎn)換動作。

　　既然客戶信息被繪制為一棵完整的表達(dá)樹，那么很明顯，它非常適用于提供EL表達(dá)式進(jìn)行檢索，EL表達(dá)式能夠為業(yè)務(wù)邏輯的規(guī)則判定等場景提供低代碼開發(fā)的規(guī)則處理，為業(yè)務(wù)的擴(kuò)展性提供無限的想象空間。

　　交易視圖，實踐中可隸屬于客戶視圖，但通常建議分離實現(xiàn)。主要原因是客戶視圖是冪等的，而交易視圖都是功能型的動作，會對系統(tǒng)產(chǎn)生變更。一般在最下層分離實現(xiàn)，并向上統(tǒng)一聚合為一個視圖。

　　交易視圖分離實現(xiàn)還有另一個重要的因素，每個操作類交易完成后，通�？深A(yù)見地影響了客戶信息樹中的部分?jǐn)?shù)據(jù)，因此交易視圖中綁定的操作類交易完成后，需要觸發(fā)某些信息的過期（按需加載），或者直接由該交易完成信息樹緩存的局部修改。

　　既然客戶視圖完整地定義了底層信息和能力，很明顯多數(shù)業(yè)務(wù)系統(tǒng)都希望能夠享受到其帶來的便利。因此，這一設(shè)計的升華便是將其劃分為獨立的服務(wù)模塊，以遠(yuǎn)程調(diào)用的方式向各業(yè)務(wù)系統(tǒng)提供能力。

　　作為分布式的一員，客戶中心的規(guī)劃就需要額外考慮集中緩存、哈希負(fù)載等設(shè)計問題，從單機(jī)模式切換到分布式是另一個大話題，此處不再展開，留待日后繼續(xù)分享！

　　上下文是相對于業(yè)務(wù)終端操作環(huán)境而言的，用于記錄：

　　會話信息主要是針對呼叫中心一次溝通的相關(guān)信息，包括用戶本次會話的標(biāo)識號，用戶進(jìn)線時使用的線索信息（卡號、證件號、用戶ID、手機(jī)號等），以及用戶的聯(lián)絡(luò)歷史信息。

　　大量的項目經(jīng)驗表明，工作臺功能的絕大部分是代客查詢或者代客交易功能，并且絕大多數(shù)的代客查詢和代客交易功能，都是面向銀行后臺系統(tǒng)接口的存儲轉(zhuǎn)發(fā)，也就是接口調(diào)用。

　　同時，通過對大量項目中的海量交付過程進(jìn)行總結(jié)，絕大部分的功能從需求描述上，只有3個部分：

　　工作臺的整體布局，比如菜單的規(guī)劃和層級的規(guī)劃通常是項目初期一次性商定并實現(xiàn)的。每個功能的布局和樣式也是在項目初期一次性商定并實現(xiàn)的。因此這里的每一個功能需求描述只需要包括這三要素。

　　這一業(yè)務(wù)共性給了系統(tǒng)設(shè)計空間，通過配置方式、低代碼完成絕大部分的功能開發(fā)，只需預(yù)留好擴(kuò)展口以完成剩余的少量特殊定制即可。

　　業(yè)務(wù)上確定了三要素，基于技術(shù)上的框架就已經(jīng)明確了該功能的開發(fā)方向，那么通過良好設(shè)計提供的配置可以由前端自動渲染UI。

　　以上即為嘗試使用領(lǐng)域驅(qū)動設(shè)計方法，快速構(gòu)建呼叫中心相關(guān)應(yīng)用的整體設(shè)計思路。

　　整體的設(shè)計能夠在較大的層面集成銀行的業(yè)務(wù)體系，并向業(yè)務(wù)系統(tǒng)快速交付，為銀行業(yè)務(wù)快速發(fā)展奠定IT實施基礎(chǔ)。但如果你只是實施一個中小型項目則需要謹(jǐn)慎嘗試，這是一個投資回報周期很長的工作，對于一錘子買賣，壓根沒有意義做這方面的考慮。但如果你作為銀行體系內(nèi)部IT成員或者與該銀行具有長期合作，那么該設(shè)計能夠為后期的IT建設(shè)提供巨大的競爭優(yōu)勢。

　　文章來源：中電金信軟件有限公司遠(yuǎn)程銀行事業(yè)部