中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導語：領域模型是對領域內的概念類或現實世界中對象的可視化表示，它專注于分析問題領域本身。本篇文章中，作者分享了自己對領域模型的理解，感興趣的小伙伴不妨來看看~

一、TOGAF

TOGAF對于架構師的職責定義是了解并關注實際上關系重大但未變得過載的一些關鍵細節和界面，具體包括：理解并解析需求，創建有用的模型，確認、細化并擴展模型，管理架構。

TOGAF 即 The Open Group Architecture Framework （開放組體系結構框架），是由致力于技術標準制定和推廣的非盈利組織 The Open Group 制定的用于開發企業架構（Enterprise Architecture）的一套方法和工具。

• 業務架構師：負責客戶訴求的實現、專注于業務邏輯、特定業務場景的客戶實現
• 應用架構師：理解業務，梳理模型，設計模式，接口，數據交互等
• 系統架構師：服務器負載，可靠性，伸縮，擴展，數據庫切分，緩存應用等

二、企業架構的推導方式

一個企業級的架構常用有兩種推導結構，一種是自上而下的、另一種是自下而上的。比如一個針對企業或者是獨立 BU 的架構大概率從頂而下的去推導的，如果具體業務中的某個架構可能就是自下而上的推導。

從企業級關注的重點與 IT 解決方案角度來講，分為三個階段：

• 第一個階段：企業有了自己經營目標也就是戰略。圍繞經營戰略是需要來看有什么樣系統來支撐
• 第二個階段規劃，針對經營戰略與企業信息戰略需要從業務架構角度、IT 架構更詳細的規劃與設計，這個階段可以稱為分析的階段。在分析階段頂層架構師角色對企業經營戰略或信息戰略抽象了結構化的描述，其它的架構師角色會繼續對這些結構化的描述做進一步分解，其主要的是同歸對業務需求的與流程的規劃
• 第三個階段是設計交付可以稱為 IT 解決方案， 在這個過程是要對分析階段輸出的領域模型、企業概念架構模型進行系統化、流程化的設計

三、領域模型

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

設計師會在設計的修改與完善上花費大量的時間，幾個月到幾年都是有可能的，直到解決完美的狀態，這個狀態就是設計的模型能夠完全的反映人腦中所想的。

領域是現實中的一種事物，無法通過簡單的鍵盤輸入變成一種代碼，需要對其進行領域抽象化。

改造世界任何一個東西都是要先認知與學習。沒有對其深入的準確、全面的認知，就無法提供一個正確的并能夠解決問題的解決方法。

Eric Evans（領域驅動設計的創始人 Eric Evans） 告訴大家， 軟件系統的復雜性來源于其所對應的領域， 領域知識的抽象和建模是構建復雜軟件系統的基礎步驟 ，這一段與國內的許多”面向數據庫建模的設計方法“ 顯得格格不入。

這里并不是挑起這兩種方法的做對誰錯， 但從實際的情況來看， 面向數據庫建模的設計方法，隱藏了面向對象分析與設計的許多細節。

不管是在企業應用架構、中臺架構中，都提到了領域模型，抽象業務并在領域內做復用。

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

• 幫助分析理解復雜業務領域問題，描述業務中涉及的實體及其相互之間的關系，是需求分析的產物，與問題域相關
• 是需求分析人員與用戶交流的有力工具，是彼此交流的語言
• 分析如何滿足系統功能性需求，指導項目后續的系統設計

所以 DDD 設計方法綜合考慮了業務領域、IT 領域。DDD 鼓勵我們接觸到需求后第一步就是考慮領域模型，而不是將其切割成數據和行為，然后用數據庫實現數據，用服務實現行為，最后造成需求的首尾分離。

四、一個交易支付清算業務領域建模

1. 交易業務模型

先來看一個普遍的在網上購買旅行產品的交易業務模型：

（1）流程

1. 用戶向業務線發起交易請求；
2. 業務線向支付中心發起支付請求
3. 支付中心接收到業務線請求后，向第三方支付公司或銀行發起支付請求
4. 用戶根據提示完成支付
5. 第三方支付公司或銀行通過接口通知支付中心用戶支付成功
6. 支付中心通知業務線支付成功結果
7. 業務線通知商戶支付成功，商戶進行出票

備注：在上面描述的這個過程中就暫時叫在線機票的支付領域模型

（2）業務用戶

• 在線旅行的業務用戶，在一次的購買機票的交易過程中涉及到的兩個用戶、一個平臺，一個是機票的買方、一個是機票的賣方。

業務場景（非登錄狀態）：

1. 用戶在機票搜索頁或選擇頁面通過會選擇單程、往返、特價、日期、航班信息，頁面會向機票搜索發起搜索請求服務，服務會返回機票的近七天價格信息。
2. 用戶選擇自己需要的預定信息，并填寫乘機人信息、聯系人信息、報銷信息行程訂單并發送給業務線的訂單系統
3. 訂單系統會檢索商戶提供的機票信息的數量信息是否完善并返回給訂單系統
4. 訂單系統會把確認信息前臺返回給用戶
5. 用戶根據訂單返回的狀態選擇借貸卡、支付平臺方式進行支付
6. 用戶得到支付返回結果

這個在線旅行的支付領域模型可以分為三部分：

1. 客戶域：主要有用戶、商戶、航司
2. 業務域：有虛擬商品、訂單、給用戶提供服務的產品
3. 支付域：交易、支付、交易反作弊、余額、支付帳戶、收銀臺、網關、清算、結算、賬務等域

對于支付這個域還可以進一步劃分二級域，例如：

從支付二級領域模型來說分為五個部分的內容：

1. 用戶域：主要有 支付的個人帳戶、支付商戶帳戶
2. 產品域：交易反作弊、余額支付、收銀臺、快捷支付、信用付、擔保交易、代購、預授權、卡、退款
3. 支付過程域：交易、支付
4. 資金域 ：清算、結算、對賬
5. 網關域 ：銀行、第三方支付、路由

這個二級的領域模型可以看的出來， 完整的支付域還是有非常復雜的，接下使用清算這個三級小領域模型進一步展開。

2. 清算領域模型與簡單拆解

先來看一個業務的案例可以了解一下什么是清算。

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

從銀行的業務來看：

1. 建行 ATM 讀卡讀到了一個招商銀行的卡，并且還有筆取 1000 元現金業務。此時建行的系統通過網絡告訴招商，xxxx 卡的用戶要取現 1000 元，判斷下能給他
2. 招商的反饋說，帳戶夠了可以扣 1000 元，建行你先墊上吧
3. 建行 ATM 吐出 1000 元

此時取款者拿到現金，取卡結束并為當地貢獻 GDP 去。此時在銀行這個跨行取款因為從建行獲取的現金，此時在銀行之間會有一個債務關系，建行欠招行 1000 元，在一個周期內兩個銀行這筆業務的資金清算后，這筆取款的銀行之間的業務才真正的結束。

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

（1）業務用戶

1. 用戶、商戶在發起一筆支付、退款業務活動，可以無感知的完成資金支付
2. 資金對賬結算組可以更關注自己的部分業務，而不用關注更多的清算層面的東西，同時可以減少工作量
3. 對于接入新的清算渠道、可以為借貸分離打下很好的基礎、同時減輕支付中心的成本
4. 可以順利的完成資金的支付，此時清算在資金

（2）業務場景

1. 清結算操作人員通過手動觸發或定時功能獲取充值回導的文件
2. 清算前置機通過接口握手銀行通訊前置，請求文件
3. 銀行返回文件，清算前置機把文件保存到本地，并將數據導入對應的表中
4. 執行對賬，系統將表中的數據與清算指令表的數據進行比對，并返回對賬結果

一個清算的生命周期：

這里先給出清算這塊的領域模型，這個模型屬于三級領域模型：

（3）實體模型

如上圖所示，清算命令的與清算文件是多對一的關系、核對處理過的清算命令與清算文件處理結果是多對一的關系。

卡類型與清算結構產品是多對一的關系、卡賬戶類型與清算機構的產品是多對一的關系，除此之外的其它的都是一對一的關系。

（4）統一語言

統一語言是業務域中間比較重要的一個環節，常用的是 UML （統一建模語言）來進行描述。

比如清算這塊的從功能來看有五六個功能，清算文件管理、清算命令管理、內部服務管理（卡管理、協議管理、機構管理）、通訊前置、其它等。因為涉及到功能蠻多，作者只選擇清算文件處理這個模塊來做 UML 描述（為了保持書中的圖的效果，我還是用 keynote 中的圖示來模擬）。

關于清算文件處理可以有五個功能，分別是回導文件的獲取、回導文件的解析、回導文件導入、回導文件對賬、回導文件對賬結果查看。

作者給出這個業務的時序圖，在對賬需要在導入后進行觸發，觸發方式有兩種分別是人工方式、系統自動方式，下圖給出的時序圖是自動方式。

系統觸發可以配置成一個定時執行任務，這樣可以把實時要做的事情變成異步確保會做的事情，將使用到定時預約的系統功能

有了用例圖后在完成一個時序圖：

1. 維護人員或定時任務發起到會任務請求。
2. 清算文件處理會通過標準的接口通過前置機發出我要什么。
3. 前置機會向金融機構發起請求文件。
4. 金融機構會返回請求文件。
5. 前置機會保存文件。
6. 前置機給清算文件處理模塊返回文件保存的路徑與參數。
7. 清算文件處理模塊會調用響應解析格式把數據文件導入到數據庫中。
8. 維護員或定時任務返回導入結果是否有異常。
9. 當就緒后發起對賬請求。
10. 執行對賬、把導入的數據與清算命令數據對對賬。
11. 返回對賬結果信息，并進一步提升后續處理。

（5）數據模型

選擇清算命令的一個接口依賴模型， 作為案例只放了幾個字段或屬性。

然后細化的就是接口（細節省略）。

五、小結

作者一個搞數據的人為什么要了解這些內容，因為在大數據建設階段的主題域抽象設計，公共主題抽象設計，以及大數據建設的萬能靈丹不停的螺旋重構中，掌握一些方法產出效果會更好。

作者：松子（李博源）

本文由 @松子 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議