對“領域模型”有“忽如一夜春風來”的感覺，太多書籍在談它。將學習心得記錄下來，與大家分享。什么是領域模型？領域模型是對領域內的概念類或現實世界中對象的可視化表示。又稱概念模型、領域對象模型、分析對象模型。那什么是概念類呢？概念類是思想、事物或對象。這樣的解釋，仍然顯得抽象。還是先看圖吧！（圖一）利用上圖，我們可以從概念類的符號、內涵和外延三個方面來考慮。符號：表示概念類的詞語或圖形。內涵：概念類的定義。外延：概念類所適用的一組示例。對應于上圖，我們使用符號Sale來表示購買交易事件的概念類；Sale的內涵可以陳述為“表示購買交易的事件，并且具有日期和時間”；Sale的外延為“世界上所有銷售實例的集合”。為什么要創建領域模型？降低與OO建模之間的表示差異。領域層軟件類的名稱要源于領域模型中的名稱，以使對象具有源于領域的信息和職責。打個比方，你可以用一長串0和1來表示“薪水冊”，可是這種軟件表示與我們腦中的薪水冊領域模型之間存在巨大的差異，這將影響我們對軟件的理解和修改。而OO建模則可以減小這一差異。那又如何創建領域模型呢？可以通過以下三個步驟：一. 尋找概念類二. 將其繪制為UML類圖中的類三. 添加關聯和屬性如何找到概念類？1）重用和修改現有的模型。這是首要、最佳且最簡單的辦法。可以從已發布的領域模型和書籍中獲得。2）使用分類列表示例：（圖二）3）確定名詞列表在對領域的文本性描述中識別名詞和名詞短語，將其作為候選的概念類或屬性。缺點：自然語言的不精確性，不同名詞短語可能表示同一概念類或屬性，此外可能還有歧義。建議與概念類分類列表一同使用。在實踐中，在發現概念類時，一般直接為其繪制UML類圖。常見錯誤：把應該是概念類的事物表示為屬性。準則：如果我們認為某概念類X不是現實世界中的數字或文本，那么X可能是概念類而不是屬性。考慮一下航空預定領域。destination應該作為Flight的屬性，還是作為單獨的概念類Airport?（圖三）在現實世界里，目的地機場不會被看作是數字或文本，而是一占據大規模空間的事物。因此，Airport應該是個概念，而不是屬性。描述類包含描述其他事物的信息。例如，ProductDescription記錄Item的價格、圖片和文字描述。為什么使用描述類？假設：雀巢咖啡，大受歡迎，銷售一空。這就意味著雀巢咖啡的所有Item實例都從計算機存儲器中被刪除。這時如果有人問：雀巢咖啡多少錢一盒？那將沒法回答。因為價格是記錄在實例上的，而這些實例都已經被刪除。由此可以看出，需要其他事物來記錄雀巢咖啡的描述（規格說明）。（圖四）何時需要？1. 需要有關商品或服務的描述，獨立于任何商品或服務的現有實例。2. 刪除其所描述事物（如Item）的實例后，導致信息丟失，而這些信息是需要維護的，但是被錯誤地與所刪除的事物關聯起來。3. 減少冗余或重復信息。關聯什么是關聯？關聯是類（類的實例）之間的關系，表示有意義和值得關注的連接。（圖五）何時表示關聯？1. 如果存在需要保持一段時間的關系，將這種語義表示為關聯（“需要記住”的關聯）。2. 從常見關聯列表中派生的關聯。準則：要避免在領域模型中加入太多的關聯。在領域建模過程中，關聯不是關于數據流、數據庫外鍵聯系、實例變量或軟件方案中的對象連接的語句；關聯聲明的是針對現實領域從純概念角度看有意義的關系。在UML中如何對關聯命名？以“類名－動詞短語－類名”的格式為關聯命名，其中的動詞短語構成了可讀的和有意義的順序。圖五對應于：VideoStore Stocks Video多重性定義了類A有多少個實例可以和類B的一個實例關聯。（見圖五）多重性的值表示在特定時刻（而不是在某個時間跨度內）有效關聯的實例數量。（圖六）多重性是和語境有關的。兩個類之間的多重關聯：（圖七）常見關聯列表：（圖八）屬性什么是屬性？屬性是對象的邏輯數據值。何時展示屬性？當需求（例如，用例）建議或暗示需要記住信息時，引入屬性。（圖九）導出屬性（derived attribute）：可以由其他信息導出的屬性。準則：大部分屬性類型應該是“簡單”數據類型，例如數字和布爾。通常，屬性的類型不應該是復雜的領域概念，例如Sale或AirPort。準則：領域模型中屬性的類型更應該是數據類型。準則：通過關聯而不是屬性來表示概念類之間的關系。（圖十）領域模型是概念透視圖，不是軟件透視圖。在設計模型中，屬性可以是任何類型。準則：任何屬性都不表示外鍵。（圖十一）結論：沒有所謂唯一正確的領域模型。所有模型都是對我們試圖要理解的領域的近似。領域模型主要是在特定群體中用于理解和溝通的工具。有效的領域模型捕獲了當前需求語境下的本質抽象和理解領域所需要的信息，并且可以幫助人們理解領域的概念、術語和關系。參考資料：1. 《UML和模式應用》（第三版）