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

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

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

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

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

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

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

總體方案圖

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　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（某個(gè)方言：test）：

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

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

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

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

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

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

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

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

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

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

　　</enum>

　　</dict>

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

　　@Enum("sex")

　　private String sex；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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