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

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

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

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

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

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

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

總體方案圖

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　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="未說明性別"desc=""/>

　　</enum>

　　</dict>

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

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

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

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

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

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

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

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

　　<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ā)的方式，直接定義標準枚舉字典，以及各渠道的方言定義，方言中的每一選項都必須與標準枚舉字典的一項映射，允許多對一映射，但某個方向上的翻譯出現多個選項時，優(yōu)先使用靠前的項目。

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

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

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

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

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

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

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

　　會話信息主要是針對呼叫中心一次溝通的相關信息，包括用戶本次會話的標識號，用戶進線時使用的線索信息（卡號、證件號、用戶ID、手機號等），以及用戶的聯絡歷史信息。

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

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

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

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

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

　　以上即為嘗試使用領域驅動設計方法，快速構建呼叫中心相關應用的整體設計思路。

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

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