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

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

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

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

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

　　方案主要由兩部分組成：客戶(hù)視圖和工作臺實(shí)現

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

總體方案圖

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

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

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

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

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

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

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

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

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

　　這里說(shuō)的數據字典并非枚舉類(lèi)型，枚舉類(lèi)型的問(wèn)題在下一節有專(zhuān)門(mén)解釋。這里的數據字典單指業(yè)務(wù)字段的命名。

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

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

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

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

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

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

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

　　dict-std.xml（標準枚舉定義，全局唯一）：

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

　　<dicttitle="標準字典"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="未說(shuō)明性別"desc=""/>

　　</enum>

　　</dict>

　　dict-dialect-test.xml（某個(gè)方言：test）：

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

　　<！-- 以下配置在標準字典中無(wú)效 (就給懶人復制的時(shí)候方便) -->

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

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

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

　　<dicttitle="標準字典"desc=""stdInstead="true">

　　<！-- 順序敏感性聲明：item配置std，locale單方面或都重復時(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；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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