世界熱訊:好的領域模型應該是什么樣子？

好的領域模型應該長什么樣子？

DDD說，領域模型應該是可以準確表達業務需求的模型。

(相關資料圖)

模型和領域模型是兩個概念，模型可以是數據模型或服務模型，領域模型是以領域為核心的模型，是對領域知識嚴格組織和抽象得來的。

那，應該如何描述領域模型呢？

是UML圖？還是編程代碼？還是一個完整的書面文檔？

這些僅僅是表達領域模型的一種載體，如果UML圖、編程代碼、書面文檔不能傳遞出領域知識，那就不是領域模型。

一個好的領域模型應該包含如下特征：

用統一語言來表達領域中的概念；

涵蓋了業務活動和規則等領域知識；

對領域內的知識做了適當的提煉和抽象；

建立了一個迭代演進的過程；

有助于業務人員和技術人員的交流；

所以，我們忘記載體，關注于他如何傳遞領域知識，并且有助于技術人員和業務人員的交流，那他就可以稱為領域模型。

模型設計和模型實現其實是兩件事情，就像在公司里面老板做戰略取舍，基層做戰術落地，在領域模型的設計和實現上應該也分開。

模型是作基本職責的分配，程序是模型的具體表達。

Eric Evans說：將分析、建模、設計、編程工作過度分離對模型驅動設計會產生不良影響。

所以要將分析、設計、實現統一到模型設計中考量。

在分析階段，業務人員和技術人員在一起工作，建立準確和簡潔的分析模型，直觀傳遞不同角色對業務知識的理解。

在設計階段，基于分析模型對模型中的設計進行改進，考慮職責的合理分配和協作，建立有指導意義的設計模型。

在實現階段，代碼忠實反映模型的設計，反映出模型中的領域和知識。

戰略設計環節，識別出業務場景下，系統的限界上下文。

在限界上下文中，提取語義相關和功能相關的用例，作為分析建模的重要輸入。

戰術設計環節，通過用戶故事迭代，逐步對比模型進行細化，引入設計模式，結合TDD開發等進行編碼實現。

領域服務應該是一系列活動集合，是領域服務下的關鍵環節。

在每個關鍵環節，對于不同用戶身份，應該有規則映射處理細節，這部分規則可以有機的、結構化的可視化出來，便于溝通。

領域服務應該和領域掛鉤，指導每個關鍵領域下應該有的活動有哪些。

要想實現這些活動集的復用，就需要明確輸入和輸出，看得清輸入、輸出、關鍵流程才敢去復用。

總結來說，領域、領域服務、領域節點、業務身份的關鍵規則、為領域服務復用的輸入和輸出，都是可以被可視化和配置化起來的。

關鍵詞： 領域模型 領域知識 技術人員