編輯導(dǎo)語：領(lǐng)域模型是對(duì)領(lǐng)域內(nèi)的概念類或現(xiàn)實(shí)世界中對(duì)象的可視化表示，它專注于分析問題領(lǐng)域本身。本篇文章中，作者分享了自己對(duì)領(lǐng)域模型的理解，感興趣的小伙伴不妨來看看~

一、TOGAF

TOGAF對(duì)于架構(gòu)師的職責(zé)定義是了解并關(guān)注實(shí)際上關(guān)系重大但未變得過載的一些關(guān)鍵細(xì)節(jié)和界面，具體包括：理解并解析需求，創(chuàng)建有用的模型，確認(rèn)、細(xì)化并擴(kuò)展模型，管理架構(gòu)。

TOGAF 即 The Open Group Architecture Framework （開放組體系結(jié)構(gòu)框架），是由致力于技術(shù)標(biāo)準(zhǔn)制定和推廣的非盈利組織 The Open Group 制定的用于開發(fā)企業(yè)架構(gòu)（Enterprise Architecture）的一套方法和工具。

• 業(yè)務(wù)架構(gòu)師：負(fù)責(zé)客戶訴求的實(shí)現(xiàn)、專注于業(yè)務(wù)邏輯、特定業(yè)務(wù)場(chǎng)景的客戶實(shí)現(xiàn)
• 應(yīng)用架構(gòu)師：理解業(yè)務(wù)，梳理模型，設(shè)計(jì)模式，接口，數(shù)據(jù)交互等
• 系統(tǒng)架構(gòu)師：服務(wù)器負(fù)載，可靠性，伸縮，擴(kuò)展，數(shù)據(jù)庫切分，緩存應(yīng)用等

二、企業(yè)架構(gòu)的推導(dǎo)方式

一個(gè)企業(yè)級(jí)的架構(gòu)常用有兩種推導(dǎo)結(jié)構(gòu)，一種是自上而下的、另一種是自下而上的。比如一個(gè)針對(duì)企業(yè)或者是獨(dú)立 BU 的架構(gòu)大概率從頂而下的去推導(dǎo)的，如果具體業(yè)務(wù)中的某個(gè)架構(gòu)可能就是自下而上的推導(dǎo)。

從企業(yè)級(jí)關(guān)注的重點(diǎn)與 IT 解決方案角度來講，分為三個(gè)階段：

• 第一個(gè)階段：企業(yè)有了自己經(jīng)營目標(biāo)也就是戰(zhàn)略。圍繞經(jīng)營戰(zhàn)略是需要來看有什么樣系統(tǒng)來支撐
• 第二個(gè)階段規(guī)劃，針對(duì)經(jīng)營戰(zhàn)略與企業(yè)信息戰(zhàn)略需要從業(yè)務(wù)架構(gòu)角度、IT 架構(gòu)更詳細(xì)的規(guī)劃與設(shè)計(jì)，這個(gè)階段可以稱為分析的階段。在分析階段頂層架構(gòu)師角色對(duì)企業(yè)經(jīng)營戰(zhàn)略或信息戰(zhàn)略抽象了結(jié)構(gòu)化的描述，其它的架構(gòu)師角色會(huì)繼續(xù)對(duì)這些結(jié)構(gòu)化的描述做進(jìn)一步分解，其主要的是同歸對(duì)業(yè)務(wù)需求的與流程的規(guī)劃
• 第三個(gè)階段是設(shè)計(jì)交付可以稱為 IT 解決方案， 在這個(gè)過程是要對(duì)分析階段輸出的領(lǐng)域模型、企業(yè)概念架構(gòu)模型進(jìn)行系統(tǒng)化、流程化的設(shè)計(jì)

三、領(lǐng)域模型

比喻一下：汽車生產(chǎn)過程中，其生產(chǎn)工人對(duì)自己的本質(zhì)工作是非常熟悉的，這些工人通常都是只負(fù)責(zé)設(shè)計(jì)或生產(chǎn)某一個(gè)或幾個(gè)零部件 ，不管是在崗位多少年，這些工人也無法從一個(gè)宏觀角度去認(rèn)識(shí)汽車的整個(gè)流程一部好的汽車，首先是產(chǎn)生于大腦，這就是原始模型，設(shè)計(jì)者會(huì)把汽車的構(gòu)思記錄下來，接下來就是設(shè)計(jì)過程。

設(shè)計(jì)師會(huì)在設(shè)計(jì)的修改與完善上花費(fèi)大量的時(shí)間，幾個(gè)月到幾年都是有可能的，直到解決完美的狀態(tài)，這個(gè)狀態(tài)就是設(shè)計(jì)的模型能夠完全的反映人腦中所想的。

領(lǐng)域是現(xiàn)實(shí)中的一種事物，無法通過簡(jiǎn)單的鍵盤輸入變成一種代碼，需要對(duì)其進(jìn)行領(lǐng)域抽象化。

改造世界任何一個(gè)東西都是要先認(rèn)知與學(xué)習(xí)。沒有對(duì)其深入的準(zhǔn)確、全面的認(rèn)知，就無法提供一個(gè)正確的并能夠解決問題的解決方法。

Eric Evans（領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的創(chuàng)始人 Eric Evans） 告訴大家， 軟件系統(tǒng)的復(fù)雜性來源于其所對(duì)應(yīng)的領(lǐng)域， 領(lǐng)域知識(shí)的抽象和建模是構(gòu)建復(fù)雜軟件系統(tǒng)的基礎(chǔ)步驟 ，這一段與國內(nèi)的許多”面向數(shù)據(jù)庫建模的設(shè)計(jì)方法“ 顯得格格不入。

這里并不是挑起這兩種方法的做對(duì)誰錯(cuò)， 但從實(shí)際的情況來看， 面向數(shù)據(jù)庫建模的設(shè)計(jì)方法，隱藏了面向?qū)ο蠓治雠c設(shè)計(jì)的許多細(xì)節(jié)。

不管是在企業(yè)應(yīng)用架構(gòu)、中臺(tái)架構(gòu)中，都提到了領(lǐng)域模型，抽象業(yè)務(wù)并在領(lǐng)域內(nèi)做復(fù)用。

這些年一般的領(lǐng)域模型設(shè)計(jì)方法偏向 Eric Evans 的“Domain-Driven Design”又稱為 DDD 設(shè)計(jì)方法。這種設(shè)計(jì)方法兼顧綜合分析與設(shè)計(jì)的模型，需要考慮系統(tǒng)的邊界：

• 幫助分析理解復(fù)雜業(yè)務(wù)領(lǐng)域問題，描述業(yè)務(wù)中涉及的實(shí)體及其相互之間的關(guān)系，是需求分析的產(chǎn)物，與問題域相關(guān)
• 是需求分析人員與用戶交流的有力工具，是彼此交流的語言
• 分析如何滿足系統(tǒng)功能性需求，指導(dǎo)項(xiàng)目后續(xù)的系統(tǒng)設(shè)計(jì)

所以 DDD 設(shè)計(jì)方法綜合考慮了業(yè)務(wù)領(lǐng)域、IT 領(lǐng)域。DDD 鼓勵(lì)我們接觸到需求后第一步就是考慮領(lǐng)域模型，而不是將其切割成數(shù)據(jù)和行為，然后用數(shù)據(jù)庫實(shí)現(xiàn)數(shù)據(jù)，用服務(wù)實(shí)現(xiàn)行為，最后造成需求的首尾分離。

四、一個(gè)交易支付清算業(yè)務(wù)領(lǐng)域建模

1. 交易業(yè)務(wù)模型

先來看一個(gè)普遍的在網(wǎng)上購買旅行產(chǎn)品的交易業(yè)務(wù)模型：

（1）流程

1. 用戶向業(yè)務(wù)線發(fā)起交易請(qǐng)求；
2. 業(yè)務(wù)線向支付中心發(fā)起支付請(qǐng)求
3. 支付中心接收到業(yè)務(wù)線請(qǐng)求后，向第三方支付公司或銀行發(fā)起支付請(qǐng)求
4. 用戶根據(jù)提示完成支付
5. 第三方支付公司或銀行通過接口通知支付中心用戶支付成功
6. 支付中心通知業(yè)務(wù)線支付成功結(jié)果
7. 業(yè)務(wù)線通知商戶支付成功，商戶進(jìn)行出票

備注：在上面描述的這個(gè)過程中就暫時(shí)叫在線機(jī)票的支付領(lǐng)域模型

（2）業(yè)務(wù)用戶

• 在線旅行的業(yè)務(wù)用戶，在一次的購買機(jī)票的交易過程中涉及到的兩個(gè)用戶、一個(gè)平臺(tái)，一個(gè)是機(jī)票的買方、一個(gè)是機(jī)票的賣方。

業(yè)務(wù)場(chǎng)景（非登錄狀態(tài)）：

1. 用戶在機(jī)票搜索頁或選擇頁面通過會(huì)選擇單程、往返、特價(jià)、日期、航班信息，頁面會(huì)向機(jī)票搜索發(fā)起搜索請(qǐng)求服務(wù)，服務(wù)會(huì)返回機(jī)票的近七天價(jià)格信息。
2. 用戶選擇自己需要的預(yù)定信息，并填寫乘機(jī)人信息、聯(lián)系人信息、報(bào)銷信息行程訂單并發(fā)送給業(yè)務(wù)線的訂單系統(tǒng)
3. 訂單系統(tǒng)會(huì)檢索商戶提供的機(jī)票信息的數(shù)量信息是否完善并返回給訂單系統(tǒng)
4. 訂單系統(tǒng)會(huì)把確認(rèn)信息前臺(tái)返回給用戶
5. 用戶根據(jù)訂單返回的狀態(tài)選擇借貸卡、支付平臺(tái)方式進(jìn)行支付
6. 用戶得到支付返回結(jié)果

這個(gè)在線旅行的支付領(lǐng)域模型可以分為三部分：

1. 客戶域：主要有用戶、商戶、航司
2. 業(yè)務(wù)域：有虛擬商品、訂單、給用戶提供服務(wù)的產(chǎn)品
3. 支付域：交易、支付、交易反作弊、余額、支付帳戶、收銀臺(tái)、網(wǎng)關(guān)、清算、結(jié)算、賬務(wù)等域

對(duì)于支付這個(gè)域還可以進(jìn)一步劃分二級(jí)域，例如：

從支付二級(jí)領(lǐng)域模型來說分為五個(gè)部分的內(nèi)容：

1. 用戶域：主要有 支付的個(gè)人帳戶、支付商戶帳戶
2. 產(chǎn)品域：交易反作弊、余額支付、收銀臺(tái)、快捷支付、信用付、擔(dān)保交易、代購、預(yù)授權(quán)、卡、退款
3. 支付過程域：交易、支付
4. 資金域 ：清算、結(jié)算、對(duì)賬
5. 網(wǎng)關(guān)域 ：銀行、第三方支付、路由

這個(gè)二級(jí)的領(lǐng)域模型可以看的出來， 完整的支付域還是有非常復(fù)雜的，接下使用清算這個(gè)三級(jí)小領(lǐng)域模型進(jìn)一步展開。

2. 清算領(lǐng)域模型與簡(jiǎn)單拆解

先來看一個(gè)業(yè)務(wù)的案例可以了解一下什么是清算。

大家常用的是招商銀行的卡(ps 此處不是做廣告)，假設(shè)某個(gè)時(shí)間去了西部的個(gè)城市 ，剛好身上的現(xiàn)金用光了需要取現(xiàn)金， 在這個(gè)城市沒有招商銀行的網(wǎng)點(diǎn)，但是有建設(shè)銀行的，所以只能在建行的 ATM 機(jī)插入招商銀行的卡取了 1000 元。這個(gè)對(duì)取款者來說跨行取了 1000 元，被收取了 2 塊錢的手續(xù)費(fèi)。

從銀行的業(yè)務(wù)來看：

1. 建行 ATM 讀卡讀到了一個(gè)招商銀行的卡，并且還有筆取 1000 元現(xiàn)金業(yè)務(wù)。此時(shí)建行的系統(tǒng)通過網(wǎng)絡(luò)告訴招商，xxxx 卡的用戶要取現(xiàn) 1000 元，判斷下能給他
2. 招商的反饋說，帳戶夠了可以扣 1000 元，建行你先墊上吧
3. 建行 ATM 吐出 1000 元

此時(shí)取款者拿到現(xiàn)金，取卡結(jié)束并為當(dāng)?shù)刎暙I(xiàn) GDP 去。此時(shí)在銀行這個(gè)跨行取款因?yàn)閺慕ㄐ蝎@取的現(xiàn)金，此時(shí)在銀行之間會(huì)有一個(gè)債務(wù)關(guān)系，建行欠招行 1000 元，在一個(gè)周期內(nèi)兩個(gè)銀行這筆業(yè)務(wù)的資金清算后，這筆取款的銀行之間的業(yè)務(wù)才真正的結(jié)束。

同理，在購買機(jī)票的時(shí)用戶從選擇支付到最后銀行扣款返回支付成功，這個(gè)過程的清算流程如下

（1）業(yè)務(wù)用戶

1. 用戶、商戶在發(fā)起一筆支付、退款業(yè)務(wù)活動(dòng)，可以無感知的完成資金支付
2. 資金對(duì)賬結(jié)算組可以更關(guān)注自己的部分業(yè)務(wù)，而不用關(guān)注更多的清算層面的東西，同時(shí)可以減少工作量
3. 對(duì)于接入新的清算渠道、可以為借貸分離打下很好的基礎(chǔ)、同時(shí)減輕支付中心的成本
4. 可以順利的完成資金的支付，此時(shí)清算在資金

（2）業(yè)務(wù)場(chǎng)景

1. 清結(jié)算操作人員通過手動(dòng)觸發(fā)或定時(shí)功能獲取充值回導(dǎo)的文件
2. 清算前置機(jī)通過接口握手銀行通訊前置，請(qǐng)求文件
3. 銀行返回文件，清算前置機(jī)把文件保存到本地，并將數(shù)據(jù)導(dǎo)入對(duì)應(yīng)的表中
4. 執(zhí)行對(duì)賬，系統(tǒng)將表中的數(shù)據(jù)與清算指令表的數(shù)據(jù)進(jìn)行比對(duì)，并返回對(duì)賬結(jié)果

一個(gè)清算的生命周期：

這里先給出清算這塊的領(lǐng)域模型，這個(gè)模型屬于三級(jí)領(lǐng)域模型：

（3）實(shí)體模型

如上圖所示，清算命令的與清算文件是多對(duì)一的關(guān)系、核對(duì)處理過的清算命令與清算文件處理結(jié)果是多對(duì)一的關(guān)系。

卡類型與清算結(jié)構(gòu)產(chǎn)品是多對(duì)一的關(guān)系、卡賬戶類型與清算機(jī)構(gòu)的產(chǎn)品是多對(duì)一的關(guān)系，除此之外的其它的都是一對(duì)一的關(guān)系。

（4）統(tǒng)一語言

統(tǒng)一語言是業(yè)務(wù)域中間比較重要的一個(gè)環(huán)節(jié)，常用的是 UML （統(tǒng)一建模語言）來進(jìn)行描述。

比如清算這塊的從功能來看有五六個(gè)功能，清算文件管理、清算命令管理、內(nèi)部服務(wù)管理（卡管理、協(xié)議管理、機(jī)構(gòu)管理）、通訊前置、其它等。因?yàn)樯婕暗焦δ苄U多，作者只選擇清算文件處理這個(gè)模塊來做 UML 描述（為了保持書中的圖的效果，我還是用 keynote 中的圖示來模擬）。

關(guān)于清算文件處理可以有五個(gè)功能，分別是回導(dǎo)文件的獲取、回導(dǎo)文件的解析、回導(dǎo)文件導(dǎo)入、回導(dǎo)文件對(duì)賬、回導(dǎo)文件對(duì)賬結(jié)果查看。

作者給出這個(gè)業(yè)務(wù)的時(shí)序圖，在對(duì)賬需要在導(dǎo)入后進(jìn)行觸發(fā)，觸發(fā)方式有兩種分別是人工方式、系統(tǒng)自動(dòng)方式，下圖給出的時(shí)序圖是自動(dòng)方式。

系統(tǒng)觸發(fā)可以配置成一個(gè)定時(shí)執(zhí)行任務(wù)，這樣可以把實(shí)時(shí)要做的事情變成異步確保會(huì)做的事情，將使用到定時(shí)預(yù)約的系統(tǒng)功能

有了用例圖后在完成一個(gè)時(shí)序圖：

1. 維護(hù)人員或定時(shí)任務(wù)發(fā)起到會(huì)任務(wù)請(qǐng)求。
2. 清算文件處理會(huì)通過標(biāo)準(zhǔn)的接口通過前置機(jī)發(fā)出我要什么。
3. 前置機(jī)會(huì)向金融機(jī)構(gòu)發(fā)起請(qǐng)求文件。
4. 金融機(jī)構(gòu)會(huì)返回請(qǐng)求文件。
5. 前置機(jī)會(huì)保存文件。
6. 前置機(jī)給清算文件處理模塊返回文件保存的路徑與參數(shù)。
7. 清算文件處理模塊會(huì)調(diào)用響應(yīng)解析格式把數(shù)據(jù)文件導(dǎo)入到數(shù)據(jù)庫中。
8. 維護(hù)員或定時(shí)任務(wù)返回導(dǎo)入結(jié)果是否有異常。
9. 當(dāng)就緒后發(fā)起對(duì)賬請(qǐng)求。
10. 執(zhí)行對(duì)賬、把導(dǎo)入的數(shù)據(jù)與清算命令數(shù)據(jù)對(duì)對(duì)賬。
11. 返回對(duì)賬結(jié)果信息，并進(jìn)一步提升后續(xù)處理。

（5）數(shù)據(jù)模型

選擇清算命令的一個(gè)接口依賴模型， 作為案例只放了幾個(gè)字段或?qū)傩浴?/p>

然后細(xì)化的就是接口（細(xì)節(jié)省略）。

五、小結(jié)

作者一個(gè)搞數(shù)據(jù)的人為什么要了解這些內(nèi)容，因?yàn)樵诖髷?shù)據(jù)建設(shè)階段的主題域抽象設(shè)計(jì)，公共主題抽象設(shè)計(jì)，以及大數(shù)據(jù)建設(shè)的萬能靈丹不停的螺旋重構(gòu)中，掌握一些方法產(chǎn)出效果會(huì)更好。

作者：松子（李博源）

本文由 @松子 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash，基于 CC0 協(xié)議