爲何領域模型對於架構師如此重要？ https://blog.csdn.net/qq_40741855/article/details/84835212

爲何領域模型對於架構師如此重要？ https://blog.csdn.net/qq_40741855/article/details/84835212

2018年12月05日 14:30:19 絕聖棄智-零 閱讀數 966

 

 

 

在信息化時代，人們在碰到問題的時候，常常會但願經過構建一套信息系統直接或間接的來解決問題。

好比說一家傳統企業，在企業內部最多見的請假審批、費用報銷審批這類的平常事務處理上，一開始碰到的問題是流程不夠透明、員工不知找誰怎樣處理，同時員工拿着紙質處處找各個審批人簽字也費時費力。爲此，企業一般會經過構建內部辦公系統或報銷系統，將流程固化透明，同時經過 app 等友好方式讓員工和管理人員隨時隨地提交或審批請求，以此提升辦公事務效率。接着還可能經過接口直接對接 HR 系統扣減員工年假天數，對接財務系統直接把報銷款轉帳到員工銀行工資帳戶裏，以此來解決人工操做帶來的人效問題，以及經過自動化減小人工失誤問題。

再好比說，做爲一家跨境電商企業，主要爲中國消費者提供一個能夠方便快速購買海外優質商品的平臺。海外的很多商品，在品質、設計感、品牌內涵上，都勝於國內商品，消費升級的到來，國人已經適應並接受海外商品。而且多年來，國人已經養成購買全球母嬰用品、化妝品、奢侈品、家居品等多種品類。可是在海淘過程當中，國人因語言文化差別致使的對海外商品品類、價格、質量等信息的不對稱，加上漫長且不透明的跨境物流遞送等問題，都亟待解決。爲此，從信息化角度咱們會搭建 2C 電商平臺來解決進口商品的國內銷售問題，同時配套海外商家系統解決貨源問題、物流相關係統解決履單物流配送問題等等。

總之，咱們作任何一個軟件系統，都是有緣由的，都是要解決特定的問題的，不然就不必作這個系統。因此經過問題，咱們就知道了咱們須要一個什麼樣的系統，這個系統解決了什麼樣的問題。而問題能夠理解成是現狀與預期的落差，這個落差就是真正需求的來源，因而最後咱們就很天然的得出了一個目標，即知道了本身的需求是什麼，經過作哪些事情來讓將來達到預期。

接着咱們引入比較抽象的兩個概念：「問題空間（Problem Space）」和「解決方案空間（Solution Space）」，以此爲後續領域建模提供工具支撐。所謂問題空間，簡單理解就是當前環境下業務所面臨的一系列問題和背後的需求，好比上述兩個例子裏的相關問題需求，它屬於產品規劃階段，一般是業務或產品領域專家主導進行問題需求收集描述和分析；而解決方案空間則是針對問題空間的解決方案，它思考的是如何設計實現軟件系統以解決這些問題，它屬於工程設計實施階段，一般是技術專家主導的解決方案設計和實現。所以，本質上，軟件開發過程能夠看作是問題空間到解決方案空間的一個映射轉化。以下圖所示。

在問題空間裏，主要是找出某個業務面臨的挑戰及其相關需求場景用例分析，而解決方案空間裏，則經過具體的技術工具手段來進行設計實現。所以上圖還能夠進一步細分紅以下圖所示的互聯網軟件從業人員容易理解的一個映射轉化過程。

簡單理解領域和領域模型

領域（Domain）」和「領域模型（Domain Model）」概念定義網絡上能夠查到不少解釋，這裏就很少說了。它們能夠簡單的這樣理解：

• 「領域」相對於軟件系統來講，就是系統要解決的現實問題。所以也能夠簡單理解一個領域就對應一個問題空間，是一個特定範圍邊界內的業務需求的總和。

• 「領域模型」則是針對特定領域裏的關鍵事物及其關係的可視化表現。它屬於「解決方案空間」，是爲了準肯定義須要解決問題而構造的抽象模型，爲軟件系統的構建目標統一認知，是業務功能場景在軟件系統裏的映射轉化。

好比上面的例子裏，請假系統解決的問題是人力工時的問題，屬於人力資源領域，對口的業務 Owner 是 HR 部門；費用報銷系統解決的是員工和公司之間的財務問題，屬於財務領域，對口的業務 Owner 是財務部門；跨境電商牽涉範圍甚廣，但本質上仍是屬於電商領域。同時能夠看出，每一個軟件系統本質上都解決了特定的問題，都屬於某一個特定領域，都實現了一樣的核心業務功能來解決該領域裏最核心的業務需求。好比電商平臺、普通電商系統，這些都屬於電商領域，只要是這個領域的系統，都會有商品瀏覽、購物車、下單、減庫存、支付等核心環節。因此，同一個領域的系統都具備相同的核心業務，由於他們要解決的問題的本質是相似的。而之因此每一個電商平臺之間又有不一樣，那是因爲客戶羣體、經營策略、商品種類、訂價策略等不一樣而形成的差別。因此纔有這樣的說法：領域來自於需求，但它卻高於需求，相對於善變的需求而言，領域知識和領域模型自己是「靜止」的，是「不變」的。

領域建模分爲「戰略建模」和「戰術建模」兩個層面，建模方法論也有多種，這裏就再也不累述。要對領域進行建模獲得優秀的領域模型，必須先要對行業領域的業務有比較深刻的理解，才能從複雜環境中找出領域核心問題，而後對它展開梳理。一般來講，一個領域有且只有一個核心問題，咱們一般稱之爲該領域的「核心子域」。領域的戰略建模一般就是從找出核心子域開始的。其次，在覈心子域及通用子域和支撐子域梳理的同時，會定義出子域中的 Bounded Context（限界上下文）及其關係，用它來闡述子域之間的關係。最後，就是找出每一個子域中的關鍵領域實體進行抽象提煉，並根據業務本質找出它們之間的聯繫關係。

爲何要建模？由於建模是幫咱們提煉出事物的本質，以便能更好的指導應用系統規劃建設。看一個簡單例子。企業信息化規劃建設常常談到「人、財、物」的總體管控，對於「人」這部分，從大部分行業業務角度建模，能夠概括成經典的「三戶模型」，即客戶、用戶、帳戶三戶模型。

其中，客戶是指現實中的一個天然人或法人機構；用戶則是客戶在使用信息系統時對應的實體，咱們常稱之爲系統賬號；帳戶是客戶存放我的資產資金的實體，相較於線下銀行金融機構裏的實際帳戶，線上交易支付相關應用裏的又稱爲虛擬帳戶，存放虛擬貨幣、積分、甚至是實際貨幣。三戶的關係在百度百科裏說的比較好，它是這麼說的：這三者之間的關係應該是一個相互關聯但又是獨立的三個實體，這種關聯只是一個歸屬和映射的關係，而三個實體自己是相互獨立的，分別是體現徹底不一樣的幾個域的信息，客戶是體現了社會域的信息，用戶體現了業務域的信息，帳戶體現的是資金域的信息。三戶模型最先是在電信運營領域裏提出的，後來在銀行、金融、第三方支付、電商等各領域獲得了普遍應用。

案例：酒店管理系統 PMS

一家酒店在平常管理中的方方面面，包括客房管理、預訂處理、客人入住和退房辦理、在住客人的服務等，在行業裏一般是由 PMS 系統來一手包辦。固然大型酒店集團，還會針對每一個環節有更深刻的應用，好比中央預訂系統來處理各類渠道的預訂訂單、CRM 處理酒店會員關係管理、房價體系系統實現動態訂價、房控系統實現客房資源利用最大化等等。但迴歸到核心，全部酒店都共有的核心，能夠概括爲下面的核心業務流程：

核心業務流程具體描述以下：

1. 客戶選擇預訂渠道下訂單：客戶能夠選擇預訂渠道預訂酒店連鎖集團下的任一酒店，包括從官網、 app、中介 OTA（如攜程網等）、呼叫中心進行預訂，也能夠直接步入酒店在酒店前臺當場進行預訂。PMS 根據客戶在某時間段裏須要入住的酒店和房型，結合其可用房數量和當時的房間房價進行下預訂單操做。預訂單一旦生成，房態會發生變化，可用房數量也發生變化，最終結帳的房價爲當時下預訂單時的房價。

2. 住客入住接待：住客根據預訂的時間來到預訂的酒店辦理入住。前臺根據住客提供的身份證等信息辦理入住，PMS 根據入住信息生成接待單，並將房卡制好發給住客。住客根據制好的房卡入住指定的房間。

3. 住客服務接待：住客在入住期間，能夠享受酒店提供的一系列禮賓服務和餐娛樂服務，好比叫醒服務、早餐服務等。每次服務接待都應在接待單裏產生相應的接待服務信息；若是接待服務爲收費項目時，好比餐飲服務，則須要同時進行帳務處理，加入帳單流水帳中。

4. 夜審：夜審主要是作入帳對帳及其核查。每次夜審都應該將住客房費和餐娛樂等費用進行覈查，最終算入當日營業日業績。只有夜審完成後，系統才能進行下一營業日的酒店營業操做。

5. 住客退房：住客退房時，系統須要對住客在入住期間的全部服務及其費用進行覈查結算，在知足退房條件的狀況下，回收房卡，並更改房間房態。

6. 客歷歸檔：住客從入住到退房整個過程，默認將收集到的住客在期間的喜愛和反饋存入住客檔案中，供後續進行客戶分析和客戶個性化服務使用。

酒店的核心業務是穩定可擴展的，不隨市場活動等外部平常運營業務而不斷變化。所以 PMS 中，平常運營業務的變化，如市場活動對房價形成的影響，或餐娛樂服務對住客帳單的影響等，都是與核心業務剝離弱化關聯的，以此保證核心業務穩定沉澱的同時，系統仍然能夠多變適應平常運營業務靈活多變的須要。

在理解酒店核心業務後，瓜熟蒂落能夠獲得酒店管理領域的核心子域——客房管理子域。這是由於酒店的全部核心業務都圍繞着客房管理進行的。好比，預訂房間時，最重要的是瞭解這家酒店的可用房信息及其相關房價、客人入住時須要關聯房間並變動房態、酒店服務的收銀帳務是按房間來進行掛帳買單的等等。以此爲核心，經過 Bounded Context 關聯各個相關子域。以下圖所示：

領域中的界限上下文能夠簡單理解成一個子系統或組件模塊，它放在哪一個子域裏最爲合理是受到場景制約的。有時候，一樣一個業務甚至同一個實體，會出如今不一樣的子域裏，結合該子域的上下文來進行不一樣的描述。領域和界限上下文的劃分並無標準，它是依據每一個人對特定業務不一樣程度的理解和抽象程度而不一樣的。評判一個領域模型是否合理，只能放到特定的業務背景和場景下才會相對客觀。

最後根據上述戰略建模的結果，進行領域模型上的戰術建模。根據核心子域裏的界限上下文及核心場景，抽象出領域實體及其關係，並用概念類圖的方式呈現出來。這張領域模型圖也有不少的畫法，但最重要的是要讓業務和技術等各方干係人都能理解這張圖表達的涵義，以此造成統一的共識。領域模型圖怎麼畫並非關鍵，最關鍵的是明白領域模型要解決什麼問題， 而後才能把這個問題毫無歧義的表述成一張圖來凝結各方共識。戰術建模獲得的領域模型圖，其關鍵就是識別出各種關鍵實體，以及它們之間的關係；而最終領域模型的驗證反過來也是經過戰略模型和核心業務場景流程來驗證的。下圖是酒店管理領域模型圖示例。

思考總結

領域建模不是面向技術的一種純軟件設計方法，它是一種思惟方式，咱們採用它來搭建領域模型，以此彌補業務和代碼之間的 Gap，促進團隊合理的分工協做，同時也時刻真實的反映着咱們所要解決的問題的變化，讓咱們構建的系統富有價值和生命力。

因此，領域模型的價值不在於它的設計優美﹐而在於它體現了系統的核心價值。那麼什麼是系統的核心價值？一個企業內部經常使用的費用報銷系統和一個互聯網的大型支付系統，它們本質的區別不是用了什麼編程語言，也不是用了什麼數據庫，而是其提供的服務及其服務質量，也就是咱們最開始所說的，它能解決的問題及解決的程度。