在資訊化時代，人們在碰到問題的時候，經常會希望通過構建一套資訊系統直接或間接的來解決問題。

比如說一家傳統企業，在企業內部最常見的請假審批、費用報銷審批這類的日常事務處理上，一開始碰到的問題是流程不夠透明、員工不知找誰怎樣處理，同時員工拿著紙質到處找各個審批人簽字也費時費力。為此，企業通常會通過構建內部辦公系統或報銷系統，將流程固化透明，同時通過 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，促進團隊合理的分工協作，同時也時刻真實的反映著我們所要解決的問題的變化，讓我們構建的系統富有價值和生命力。

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